Subject: [lemonade] Recommended timeouts for BDAT/BURL?

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Jul 2006 21:18:14 +0100

Hi,
I was looking at RFC 3030 and RFC 4468 and couldn't find any recommended 
timeouts for server response to BDAT/BURL commands.
RFC 2821 has the following recommendations about the DATA command:

   DATA Initiation: 2 minutes
      This is while awaiting the "354 Start Input" reply to a DATA
      command.

   Data Block: 3 minutes
      This is while awaiting the completion of each TCP SEND call
      transmitting a chunk of data.

   DATA Termination: 10 minutes.
      This is while awaiting the "250 OK" reply.  When the receiver gets
      the final period terminating the message data, it typically
      performs processing to deliver the message to a user mailbox.  A
      spurious timeout at this point would be very wasteful and would
      typically result in delivery of multiple copies of the message,
      since it has been successfully sent and the server has accepted
      responsibility for delivery.  See section 6.1 for additional
      discussion.
=========
So I guess the timeout for BDAT/BURL "LAST"  should be 10 minutes as 
well. What about non-last BDAT/BURL?

Alexey

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Sat, 8 Jul 2006 12:37:18 -0700

At 9:18 PM +0100 7/6/06, Alexey Melnikov wrote:

>  So I guess the timeout for BDAT/BURL "LAST"  should be 10 minutes 
> as well. What about non-last BDAT/BURL?

We had some discussion of this a while back (maybe a year or two?). 
As I recall, there seemed to be some agreement that the current SMTP 
timeouts were too large for mobile clients and could be reduced for 
lemonade.  Also, there was some discussion of adding intermediate 
"command in progress" responses to let the client know that the 
server hadn't vanished.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Some days you feel like Schrodinger's cat.   --M. S. Hutchenreuther

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 09 Jul 2006 16:22:03 +0100

Randall Gellens wrote:

> We had some discussion of this a while back (maybe a year or two?). As 
> I recall, there seemed to be some agreement that the current SMTP 
> lemonade.

Ok. Is this something we want to cover in Lemonade Profile bis?

> Also, there was some discussion of adding intermediate "command in 
> progress" responses to let the client know that the server hadn't 
> vanished.

You reminded me that I actually volunteered to co-edit it :-).

---

From: Randall Gellens <[email-masked]>
Date: Sun, 9 Jul 2006 09:11:20 -0700

At 4:22 PM +0100 7/9/06, Alexey Melnikov wrote:

>>>   So I guess the timeout for BDAT/BURL "LAST"  should be 10 
>>> minutes as well. What about non-last BDAT/BURL?
>>
>>  We had some discussion of this a while back (maybe a year or 
>> two?). As I recall, there seemed to be some agreement that the 
>> current SMTP timeouts were too large for mobile clients and could 
>> be reduced for lemonade.
>

I think we need to, yes.

>  You reminded me that I actually volunteered to co-edit it :-).

I'm happy to help with that.

We should probably try and get rough consensus in the group that it 
is something we still want to do.

-------------- Randomly-selected tag: ---------------
Lottery: A tax on people who are bad at math.

---

From: Dave Cridland <[email-masked]>
Date: Sun, 09 Jul 2006 22:23:10 +0100

> Ok. Is this something we want to cover in Lemonade Profile bis?
I think that's the best place for it, but I disagree with the 
principle - that is, I don't think timeouts should be reduced, I 
think another approach is needed - but if the consensus of the group 
is that we should simply change timeouts, I'd have thought it'd be 
simpler to put that in Profile Bis rather than a new draft.

> You reminded me that I actually volunteered to co-edit it :-).

Personally I'm more interested in Tony Finch's reworking of 
CHECKPOINT - I think making RFC1845 work with BDAT and BURL, and 
making it more pipelinable, is of considerably more generic utility. 
It allows the issue of timeouts to be rather moot, since a client 
which decides not to wait, or is cut off before the response comes 
back, can later establish not only whether the message send succeeded 
as a whole, but which data needs to be resent.

Maybe there's another aspect to timeouts I've missed, though.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade