On Wed Mar 15 04:46:06 2006, Tony Finch wrote:
http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-replay.html
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>
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw