APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists rescert 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed Up/Down protocol description



>> did i not hear a pretty sensible suggestion that it be called parent
>> and child or something?
> or "server" and "client" as per your note a little further down?

i can live with anything along these lines

> "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."
> "7. The value of the version number of the message is 1." ?

sticking to fortran, eh? :)

>> "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?

> 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?

randy