[Top] [All Lists]

Re: [lemonade] update to RFC 1845 checkpoint/restart

2006-03-15 08:31:02

On Wed Mar 15 04:46:06 2006, Tony Finch wrote:

Comments, in no particular order:

1) Why have a distinct response 255 instead of 355 <length of complete message>? A client's behaviour is likely to be the same, and semantically, there is no difference.

2) This specification is needlessly not compatible with RFC1845 on a number of points. I can't see why this needs to be so.

3) The DATA offset restriction (beginning of a line) is problematic because it forces a server to store the message one entire line in arrears, because of the multi-line termination of the data transmission with DATA. This is probably required, in order to gain compatibility with RFC1845, but it needs to be pointed out.

4) Section 9, first para, is an example of (2).

5) The syntax of REPLAY means that the syntax of txn-id is not accurate as given in section 6. A txn-id MUST NOT be "CLEAR", in particular. The syntax of REPLAY is, in my opinion, quite ugly as a result.

6) There's no mention here of BURL.

a) An octet-offset provided by the server MUST NOT point into a BURL chunk. BURL chunks MUST be appended atomically.

b) For BURL and BDAT commands, an additional parameter could be defined, which could then be send in lieu of, or in addition to, the octet-count by the server, thus providing for the (rare) case where a client cannot know the octet count of a BURL chunk without downloading it.

7) Your description of how to send no data with DATA is incorrect, it's actually DATA<CRLF><wait for 354><CRLF>.<CRLF>

          You see things; and you say "Why?"
  But I dream things that never were; and I say "Why not?"
   - George Bernard Shaw