In my experience, it works best if the person sitting is performing the planning aspects, while the person standing is critiquing or looking for bugs/typos.
If there's too much of a difference in experience level between the two people doing pair programming, I don't see the point -- it's not very effective as a didiactic tool, compared to throwing a junior engineer at a problem way over their head and waiting until they figure it out themselves.
That said, I sometimes get a lot out of performing the 'coaching' role for someone who has a lot more experience than I do, if they generally aren't good at explaining their logic, because it provides me the opportunity to ask very specific questions with very clear context about how and why they are making particular decisions. Sometimes, such questions reveal the logic behind behaviors that were learned through experience and never consciously considered yet have big ramifications on performance, code structure, or engineer effort.