Personally, I felt the conversation at the microphone about client/server capability was a huge misunderstanding. You did not seem to "get" part of what was being said, about the need for a client to be able to know what a server can do (in the future) beyond what a server has done (now, or in the past).
If we admit two forms of pagination/presentation/truncation, and we do not require all clients to implement both, then we can wind up in a world where a client cannot handle what a server can do. A capabilities query is a mechanism to inform server and client mutually what they can do. Telnet "options" negotiation for example, or the SMTP HELO exchange is not one-sided. How a client and server "dance" around this, informs what they both know about each other. There is a proffer and a response. Yes, the actual underlying protocol here is atomic and there is no implied state because we didn't implement session. But that doesn't mean both client and server cannot "know" about each other, because implicit state they hold or construct forms the session information, or the client holds all information, and varies its future behaviour to the atomic server, irrespective. (one sided, is simpler for servers, but puts more work on the client) If we admit two forms of pagination a client should be entitled to discover in advance which model to expect: this determines future actions. You appeared to say you wanted all clients to be ready to handle EITHER case. If I misunderstood or mis-characterise what you said, I welcome clarification. -George
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
