Some comments ...Â
I thought that we covered in our discussion at the face to face to separate out the mechanism for changing direction (i.e. the Change Flow operation in this proposal) from what would happen in terms of communication after the direction changed.
i.e. we should not be talking about any queue messages - as we don't have such a concept within the specification (that's a server specific thing) - so if a server is queuing things up and after a change-of-direction happens it then starts sending things it has queued then that is entirely okay - but we don't need to place that detail in the specification or mandate such a mechanism exists - the client simply sees messages.
If we did want to add a message queue mechanism in place then we would want some way to get a sense as to the size of the queue perhaps and even be able to filter which messages came down (things like order of retrieval in the queue, etc come to mind).Â
I think we should rename this somewhat to be perhaps Set Direction and allow setting either Client-to-Server or Server-to-Client reflecting how we name the operations in the protocol in the two groups - which is what the enumeration allows for.
I'm not sure the purpose of Unspecified in that context - we know which direction things are flowing when we are using a link.Â
I don't see why we would add anything in the response header - it isn't required - not really seeing the purpose. One side of the communication needs to change the direction - and that has to be done by the current sender (i.e. the client for client-to-server operations and the server for server-to-client operations).Â
Essentially we are changing the roles of the two end points and the locus of control as well.
So in summary I suggest:
- reword 6.1.6 to talk entirely in terms of changing roles c-s to s-c etc.
- remove 8.2 change
- remove Unspecified from 11.17