I apologize for being cryptic. I think you understand my point of view.
Here's my take: XML-RPC is implemented as a HTTP POST. So at first glance, it appears client/server oriented, much as most of the HTTP we've come to love is browser/server oriented.
But RPC stands for remote procedure call, and in that sense, it's a technology implemented by something smarter than your average browser. Not always though, the blog module I just wrote implements an XML-RPC call from *your* ACS to ping weblogs.com by just using a variant of util_httppost. In this case the XML-RPC was overkill for weblogs.com, as the return value is ignorable.
With a second look through the eyes of AOLserver, which implements both client and server sides of HTTP, one can see that any entity that needs to implement a sophisticated XML-RPC service can implement both XML-RPC client and server. Think of it as a socket connection which if I recall, is made of a bundle of two pipes, connected in opposite directions.
In the case of the scrolling cash register, XML-RPC is probably not the protocol I would choose, but it could be done. The cash register user agent could implement both sides of the XML-RPC protocol and use that to communicate back and forth with the cash register server. And yes, the session would be embedded within the protocol.