Subject: Draft name (was RE: [lemonade] COMPRESS Thoughts)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 13 Jun 2006 05:00:54 -0400

There is a purely procedural reason for reusing the old draft name.  It
buys us a week.  Blame the chair :From [email-masked] Tue Jun 13 04:59:44 2006
Content-class: urn:content-classes:message
Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt
Date: Tue, 13 Jun 2006 05:00:52 -0400
From: "Burger, Eric" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>,
	<[email-masked]>
Cc: [email-masked]

Also don't forget that under any circumstance, the server could decide
'later' that it cannot honor a request.  This is independent of whether
we have the server say, "I might have so many sessions available for
you" when asked or if the server doesn't say anything about how many
sessions are (could be) available.  Once you have to write the code for
the client to handle that situation, it turns out there is no value to
the server giving an indication as to how many sessions are available
for you.  Thus we took out reporting on the number of available server
sessions from the specification.

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Sunday, June 11, 2006 3:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt

[email-masked] wrote:

>Thank You for the update Alexey,
>I have a few comments:
> - "   state is deleted.  While there is no required minimum expiration
>   timeout, server implementations are encouraged to support as long a
>   time as possible, subject to denial-of-service and related
concerns." This is something I have commented before. I do not know if
the idea has been discussed. It would be very beneficial for the client
to know how long the server keeps the sessions, even better if the
client could negotiate this setting. Has this been discussed during the
interim?
No it hasn't.
I've read both your message and Randy's reply to it. I think Randy 
argued against the need for the server to advertise/be able to change 
any limit. If you disagree, can you please reply to Randy's message and 
we will continue the discussion.

>Was there any conclusion?
> - "   previous, active resumable session is available.  If an active
>   session is already available and a new one can be created, the" What
happens when a new session cannot be created?
The server would reply NO and the current active session remains active.

I guess this can be spelled out in the document.

>Who says it cannot be created and why?
>
Server can have a policy limiting num)

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]] 
Sent: Wednesday, May 31, 2006 6:36 PM
To: Enhancements to Internet email to support diverse service
enivronments
Subject: Re: [lemonade] COMPRESS Thoughts

On Wed May 31 20:29:26 2006, Burger, Eric wrote:
[snip]
> (3) Basis for COMPRESS document is Arnt's imap-deflate-02
> [compress=deflate].  We will call the new document
> draft-ietf-lemonade-compress-04 (delete existing compress text)
> 
> 
Why? It's obviously not a revision of that document. Is there a 
procedural reason for this?
[snip]

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