[Top] [All Lists]

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

2006-03-15 10:04:11

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 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