On Wed, 15 Mar 2006, Dave Cridland wrote:
Thanks for your comments.
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.
I vacillated a bit here - at one point the spec also had a 555 response
instead of 355 0. You are probably right that 255 is also redundant.
2) This specification is needlessly not compatible with RFC1845 on a
number of points. I can't see why this needs to be so.
4) Section 9, first para, is an example of (2).
Hmm, yes, I suppose it might be possible (and desirable) to be backwards
compatible.
The REPLAY spec is currently weak in descibing the line between a retry
and a replay. For example, the 555 response to MAIL would be better as a
455 that would cause the client to retry with a new transaction (i.e. a
fresh <txn-id>). The corresponding situation with an improved CHUNKING
would be an unexpected 355 response. The problem here is what happens if
the client has pipelined some data after the erroneous command?
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.
I'm not sure it's necessary to be a line in arrears. You can store each
line as you receive it, until you get a line containing just a dot. You
only need a one-line window.
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.
Perhaps it should be a separate command. I also considered making the
transaction log clearing implicit, when the server sees a QUIT from the
client. But what commend to use when the client wants to leave the
connection idle waiting for new messages? EHLO?
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.
Yes, that's a sound suggestion.
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.
Perhaps a chunk count as well as an octet count? There would have to be an
octet offset within the chunk, so that the chunk count and chunk offset
together mean the same thing as the octet offset. I'll see if I can think
of a good way of specifying it. I'm wary because its in danger of getting
a bit complicated.
7) Your description of how to send no data with DATA is incorrect, it's
actually DATA<CRLF><wait for 354><CRLF>.<CRLF>
That's two octets of data (a blank line), not zero :-) but I should
mention the wait for 354. cf. the text about a "single dot" in RFC2920.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
NITON: A DEPRESSION MOVING EAST INTO TRAFALGAR WILL GENERATE STRONG EASTERLY
WINDS IN ALL AREAS DURING FRIDAY, PERHAPS GALE FORCE IN NORTH FITZROY, SOLE
AND SHANNON.