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
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?
I don't follow all of this.
> 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?
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.
> 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.
It's by far the simplest.
> 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.
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
contrived use-case.
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
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.
(This is "below") Ah, I sit corrected. I'd previously somehow misread
RFC2821 section 4.1.1.4 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.
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw