On Wed Mar 15 15:37:25 2006, Tony Finch wrote:
On Wed, 15 Mar 2006, Dave Cridland wrote:
Thanks for your comments.
Pleasure. RFC1845 has a lot to offer, I think.
The REPLAY spec is currently weak in descibing the line between a
and a replay. For example, the 555 response to MAIL would be better
455 that would cause the client to retry with a new transaction
fresh <txn-id>). The corresponding situation with an improved
would be an unexpected 355 response. The problem here is what
the client has pipelined some data after the erroneous command?
I don't follow all of this.
> 5) The syntax of REPLAY means that the syntax of txn-id is not
> given in section 6. A txn-id MUST NOT be "CLEAR", in particular.
The syntax of
No, because EHLO is already mandated as being a noisier RSET. I think
a new command, or else changing the syntax of REPLAY. I have no
preference as to which.
> REPLAY is, in my opinion, quite ugly as a result.
Perhaps it should be a separate command. I also considered making
transaction log clearing implicit, when the server sees a QUIT from
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 chunks MUST be appended atomically.
Yes, that's a sound suggestion.
It's by far the simplest.
> b) For BURL and BDAT commands, an additional parameter could be
> could then be send in lieu of, or in addition to, the octet-count
> server, thus providing for the (rare) case where a client cannot
> 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
together mean the same thing as the octet offset. I'll see if I can
of a good way of specifying it. I'm wary because its in danger of
a bit complicated.
Yes, that would be complicated.
FWIW, I can only think of one case where the length of a resource is
likely to be unknown, and that's the case where the client only has
the URLAUTH URL. That said, the only case I can think of for that
involves Alice granting Bob read access to a message via URLAUTH, and
Bob using an ESMTP send with BURL in order to copy the message to his
IMAP server in order to read it efficiently. That is a somewhat
I'd be happy to see the entire problem noted and subsequently ignored.
> 7) Your description of how to send no data with DATA is
> 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
(This is "below") Ah, I sit corrected. I'd previously somehow misread
RFC2821 section 18.104.22.168 para 2 as saying the exact opposite of what
it does say. I have no idea how I misread that. This makes things
much easier, and of course eliminates my point 3.
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw