[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Up/Down protocol description
At 09:29 PM 23/05/2007, Randy Bush wrote:
> "Conforming parsers MUST reject any document with a version number they
> do not understand, or with any elements or attributes they do not
> understand. Servers must generate an error response when receiving such
> a request. Clients should generate an operator alert error when
> receiving such a response."
sure. seems a lot of words, though. how about
"it is an erroe for the client or server to receive a message with a
version number other than the one they understand or with elements they
do not understand."
What I was attempting to do was to clarify what happens when this
error is detected - servers can simply tell the client that the
request will not be performed, while clients need to do something
else (i.e. "operator alert")
> "7. The value of the version number of the message is 1." ?
sticking to fortran, eh? :)
and oldie and I was going to type "a goodie", but on reflection
Fortran was a rather broken language wasn't it!
>> "Messages are checked using the following sequence of tests:"
>> is followed by the looser (at least in american) condition
>> "The checks should generally be applied in the order specified."
>> s/sequence of// if you really want to loosen it
> agreed, although the only logical wriggle room is test 3 and 4.
sorry. i was not advocating loosening; just being explicit and clear.
> I had thought that the TCP sesssion could be in a minimalist fashion
> limited to a POST and a response. The sequencing is all about making
> saure that the POSTed messages are processed by the server in the same
> order as specified by the child.
agreed. but tcp is reputed to be a reliable transport, at least in ipv4.
> i.e. if the child does issue, issue, revoke, and issues the 2nd and 3rd
> requests without waiting for a response from the previous requests, and
> the server side uses multiple http servers
uh, one tcp connection, yes?
not necessarily. I was of the inclination that the spec should allow
for both persistent TCP and per-request-response transactions.
> yes, this is indeed the case, although in the request / response model
> each transaction could be seen as <connect> request, wait for response
> <disconnect>,
not in the universe of your sequence numbers. new connections start at
0, yes?
no! - new connections should start at old connection + 1.
i.e. the client's record of the msg_ref number should be outside the
tcp transport state.
Geoff
