From lemonade-bounces@ietf.org Thu Oct 04 18:33:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZFh-0001pW-Q4; Thu, 04 Oct 2007 18:33:05 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IdZFf-0001p3-77 for lemonade-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 18:33:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZFe-0001ed-TD; Thu, 04 Oct 2007 18:33:02 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdZFP-0004fO-SB; Thu, 04 Oct 2007 18:32:54 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7BE7933C21; Thu, 4 Oct 2007 15:28:12 -0700 (PDT) Date: Thu, 04 Oct 2007 15:28:11 -0700 From: Eric Rescorla To: secdir@ietf.org, ietf@ietf.org, lemonade@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071004222812.7BE7933C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Subject: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org $Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ OVERALL This document describes an extension to IMAP to provide faster synchronization between client and server. As far as I can tell, the optimizations are: - Removing one round trip needed to discover which messages have been expunged. - A more compact representation of the list of expunged messages I have some skepticism about the importance of these optimizations. The document does not come with any performance measurements, and 1 RTT really isn't that much. In particular, I wonder if VANISHED really saves that much bandwidth over EXPUNGED if compression is in use. I don't know what standard is being used to decide whether optimizations of this type are worthwhile. I found this document fairly hard to read. I understand that it's a delta to IMAP and requires quite a bit of knowledge of IMAP to understand, but I think it could have been written to be more clear about how it changes IMAP's behavior in each case. In particular, the examples would be improved by always having New and Old and having some sort of indicator of exactly which PDUs have changed and why. DETAILED COMMENTS S 2. This would be improved by some overall diagram of the new and old behavior and some measurement, even an ad hoc one, of the performance improvement. S 3.1. Conceptually, the client provides a small sample of sequence numbers for which it knows the corresponding UIDs. The server then compares each sequence number and UID pair the client provides with the current state of the mailbox. If a pair matches, then the client knows of any expunges up to, and including, the message, and thus will not include that range in the VANISHED response, even if the "mod-sequence-value" provided by the client is too old for the server to have data of when those messages were expunged. This is probably my ignorance of IMAP, but how can this happen? Why doesn't the client have a mod-sequence-value corresponds to these UIDs? S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...] 29998:29999,30001:30002,30004:30005,30007:30008 This [...] hides the data you're optimizing away, right? This would help if it were called out more clearly. S 3.3, 3.4, 3.5. These would all benefit from a statement of how they differ from 3501, rather than just stating new rules. If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the EXPUNGE command. For each permanently removed message the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response. So, this is repeated in all three sections. That seems less than optimal. Rather than refing 3501, it would probably be good to point out why the message #s are as they are in these examples, due to auto-decrement. S 3.6. The VANISHED response has two forms. The first form contains the EARLIER tag, which signifies that the response was caused by a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This response is sent if the UID set parameter to the UID FETCH (VANISHED) command includes UIDs of messages that are no longer in the mailbox. When the client sees a VANISHED EARLIER response it MUST NOT decrement message sequence numbers for each successive message in the mailbox. The second form doesn't contain the EARLIER tag and is described below. Once a client has used "(VANISHED)" with a UID FETCH or "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the VANISHED response without the EARLIER tag instead of the EXPUNGE response. The server SHOULD continue using VANISHED in lieu of EXPUNGE for the duration of the connection. In particular this affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as well as messages expunged in other connections. Such VANISHED response MUST NOT contain the EARLIER tag. This is pretty unclear to the non-IMAP expert. Could you explain in english what this is trying to accomplish in the document, not just specify the protocol mechanics. In the example, swap before and after. Also, it would be good to show an example of (EARLIER). S 4.1. Strictly speaking, a server implementation that doesn't remember modsequences associated with expunged messages can be considered compliant with this specification. Such implementations return all expunged messages specified in the UID set of the UID FETCH (VANISHED) command every time, without paying attention to the specified CHANGEDSINCE modsequence. Such implementations are discouraged, as they can end up returning VANISHED responses bigger than the result of a UID SEARCH command for the same UID set. Isn't this inconsistent with: If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the EXPUNGE command. For each permanently removed message the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response. If not, why not? S 5. The client MUST also take note of any MODSEQ FETCH data items received from the server. Whenever the client receives a tagged response to a command, it calculates the highest value among all MODSEQ FETCH data items received since the last tagged response. If this value is bigger than the client's copy of the HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ value. So, I probably misunderstand something, but my read of 4551 made it seem like you could do a MODSEQ FETCH that would not return all the metadata for every message. In that case, wouldn't this procedure risk you having a modseq that is higher than some messages you haven't examined yet? What am I missing. I don't see any new security issues in this document. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Oct 05 07:20:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdlDC-0007g1-IH; Fri, 05 Oct 2007 07:19:18 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IdlDB-0007eg-JE for lemonade-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 07:19:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdlDA-0007XF-NA; Fri, 05 Oct 2007 07:19:16 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdlD9-0000EA-5x; Fri, 05 Oct 2007 07:19:16 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Oct 2007 12:19:12 +0100 Message-ID: <47061D7C.5080808@isode.com> Date: Fri, 05 Oct 2007 12:18:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Rescorla References: <20071004222812.7BE7933C21@delta.rtfm.com> In-Reply-To: <20071004222812.7BE7933C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: lemonade@ietf.org, iesg@ietf.org, Dave Cridland , ietf@ietf.org, secdir@ietf.org Subject: [lemonade] Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Eric, Thank you for your comments. (Today is about the worst time for me to reply to your comments, as I am going on holidays tomorrow.) Eric Rescorla wrote: >$Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ > > >OVERALL >This document describes an extension to IMAP to provide faster >synchronization between client and server. As far as I can >tell, the optimizations are: > >- Removing one round trip needed to discover which messages > have been expunged. > > Yes, if compared to the case when the client/server also implement the CONDSTORE extension (RFC 4551). (Actually it removed 2 round trips per mailbox synchronization.) When compared to RFC 3501, this extension can potentially provides huge bandwidth saving. If a client wants to synchronize flag changes in a mailbox, the client needs to fetch flags for *all* mailboxes. For a 30,000 message mailbox that I currently have is quite painful over a slow link. >- A more compact representation of the list of expunged > messages > > Correct. >I have some skepticism about the importance of these optimizations. > > See above. >The document does not come with any performance measurements, >and 1 RTT really isn't that much. In particular, I wonder if >VANISHED really saves that much bandwidth over EXPUNGED if >compression is in use. I don't know what standard is being >used to decide whether optimizations of this type are worthwhile. > > I will let Dave comment on this. Just a couple of extra comments: 1). As I mentioned above, this extension saves 2 round trips per mailbox synchronization. A user might have multiple mailboxes. 2). This is mostly useful for mobile clients which can experience frequent connection loss. >I found this document fairly hard to read. I understand that it's >a delta to IMAP and requires quite a bit of knowledge of IMAP >to understand, but I think it could have been written to be >more clear about how it changes IMAP's behavior in each case. >In particular, the examples would be improved by always >having New and Old and having some sort of indicator of exactly >which PDUs have changed and why. > > Right. >DETAILED COMMENTS >S 2. >This would be improved by some overall diagram of the new and >old behavior and some measurement, even an ad hoc one, of >the performance improvement. > > Ok. An older version of this document had some numbers, but people complained about "irrelevant text". See section 2.1 of (Note that the protocol has changed substantially since, but the basic observation is still correct.) >S 3.1. > > Conceptually, the client provides a small sample of sequence numbers > for which it knows the corresponding UIDs. The server then compares > each sequence number and UID pair the client provides with the > current state of the mailbox. If a pair matches, then the client > knows of any expunges up to, and including, the message, and thus > will not include that range in the VANISHED response, even if the > "mod-sequence-value" provided by the client is too old for the server > to have data of when those messages were expunged. > >This is probably my ignorance of IMAP, but how can this happen? Why >doesn't the client have a mod-sequence-value corresponds to these >UIDs? > > I will let Dave explain this. > S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...] > 29998:29999,30001:30002,30004:30005,30007:30008 > >This [...] hides the data you're optimizing away, right? This >would help if it were called out more clearly. > > Yes. I will add a sentence on this. >S 3.3, 3.4, 3.5. >These would all benefit from a statement of how they differ from >3501, rather than just stating new rules. > > (Actually, 3.5 updates UID EXPUNGE which was defined in RFC 4315.) Right. I believe some people wanted to see sections replacing the old definitions, as opposed to just pointing out the difference from RFC 3501. The following text in section 2 summarizes the difference: This document puts additional requirements on a server implementing the [CONDSTORE] extension. Each mailbox that supports persistent storage of mod-sequences, i.e., for which the server has sent a HIGHESTMODSEQ untagged OK response code on a successful SELECT/ EXAMINE, MUST increment the per-mailbox mod-sequence when one or more messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the server MUST associate the incremented mod-sequence with the UIDs of the expunged messages. I can try to add a sentence to each one of 3.3, 3.4 and 3.5 to clarify that. > If the server is capable of storing modification sequences for the > selected mailbox, it MUST increment the per-mailbox mod-sequence if > at least one message was permanently removed due to the execution of > the EXPUNGE command. For each permanently removed message the server > MUST remember the incremented mod-sequence and corresponding UID. If > at least one message got expunged, the server MUST send the updated > per-mailbox modification sequence using the HIGHESTMODSEQ response > code (defined in [CONDSTORE]) in the tagged OK response. > >So, this is repeated in all three sections. That seems less than >optimal. > >Rather than refing 3501, it would probably be good to point out >why the message #s are as they are in these examples, due to >auto-decrement. > > I've added a clarifying sentence to sections 3.3 and 3.5. I don't think section 3.4 needs to change. >S 3.6. > The VANISHED response has two forms. The first form contains the > EARLIER tag, which signifies that the response was caused by a UID > FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This > response is sent if the UID set parameter to the UID FETCH (VANISHED) > command includes UIDs of messages that are no longer in the mailbox. > When the client sees a VANISHED EARLIER response it MUST NOT > decrement message sequence numbers for each successive message in the > mailbox. > > The second form doesn't contain the EARLIER tag and is described > below. Once a client has used "(VANISHED)" with a UID FETCH or > "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the > VANISHED response without the EARLIER tag instead of the EXPUNGE > response. The server SHOULD continue using VANISHED in lieu of > EXPUNGE for the duration of the connection. In particular this > affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as > well as messages expunged in other connections. Such VANISHED > response MUST NOT contain the EARLIER tag. > >This is pretty unclear to the non-IMAP expert. Could you explain >in english what this is trying to accomplish in the document, >not just specify the protocol mechanics. > > Basically the VANISHED response is used for 2 purposes: to report UIDs of messages expunged earlier and to report UIDs of messages expunged now. The difference between the two is that in the former case the client doesn't need to decrement the number of messages in the mailbox, while in the latter case it must. The former can be distinguished from the latter by presence of the "(EARLIER)" label. >In the example, swap before and after. Also, it would be good >to show an example of (EARLIER). > > Ok. >S 4.1. > Strictly speaking, a server implementation that doesn't remember > modsequences associated with expunged messages can be considered > compliant with this specification. Such implementations return all > expunged messages specified in the UID set of the UID FETCH > (VANISHED) command every time, without paying attention to the > specified CHANGEDSINCE modsequence. Such implementations are > discouraged, as they can end up returning VANISHED responses bigger > than the result of a UID SEARCH command for the same UID set. > >Isn't this inconsistent with: > > If the server is capable of storing modification sequences for the > selected mailbox, it MUST increment the per-mailbox mod-sequence if > at least one message was permanently removed due to the execution of > the EXPUNGE command. For each permanently removed message the server > MUST remember the incremented mod-sequence and corresponding UID. If > at least one message got expunged, the server MUST send the updated > per-mailbox modification sequence using the HIGHESTMODSEQ response > code (defined in [CONDSTORE]) in the tagged OK response. > >If not, why not? > > No, there is no inconsistency: "a server implementation that doesn't remember modsequences" == "a server is incapable of storing modsequences". The second paragraph you quoted is conditional on server's ability to store modsequences. This behaviour is optional for servers. >S 5. > The client MUST also take note of any MODSEQ FETCH data items > received from the server. Whenever the client receives a tagged > response to a command, it calculates the highest value among all > MODSEQ FETCH data items received since the last tagged response. If > this value is bigger than the client's copy of the HIGHESTMODSEQ > value, then the client MUST use this value as its new HIGHESTMODSEQ > value. > >So, I probably misunderstand something, but my read of 4551 made >it seem like you could do a MODSEQ FETCH that would not return >all the metadata for every message. > Yes, if the client issues a FETCH MODSEQ for a subset of messages. However the previous paragraph in the same section requires the client to perform a full synchronization. >In that case, wouldn't this >procedure risk you having a modseq that is higher than some >messages you haven't examined yet? What am I missing. > > The intent of this paragraph is to talk about unsolicited FETCH MODSEQ returned by the server *after* a full synchronization is complete (the previous paragraph in the same section). So the situation you describe can't happen, because the server is required to send all unsolicited FETCH MODSEQ responses. The beginning of this paragraph is ambiguous, so I suggest that it should be clarified by changing the first quoted sentence to read: After completing full synchronization, the client MUST also take note of any MODSEQ FETCH data items received from the server. >I don't see any new security issues in this document. > > Regards, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Oct 05 10:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdocM-0004FR-JY; Fri, 05 Oct 2007 10:57:30 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IdocL-0004Dw-CR for lemonade-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 10:57:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdocL-0004Ay-1b; Fri, 05 Oct 2007 10:57:29 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdocE-0007rS-Ux; Fri, 05 Oct 2007 10:57:23 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id F200933C21; Fri, 5 Oct 2007 07:53:21 -0700 (PDT) Date: Fri, 05 Oct 2007 07:53:21 -0700 From: Eric Rescorla To: Alexey Melnikov In-Reply-To: <47061D7C.5080808@isode.com> References: <20071004222812.7BE7933C21@delta.rtfm.com> <47061D7C.5080808@isode.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071005145321.F200933C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: ietf@ietf.org, secdir@ietf.org, lemonade@ietf.org, iesg@ietf.org, Dave Cridland , Eric Rescorla Subject: [lemonade] Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At Fri, 05 Oct 2007 12:18:20 +0100, Alexey Melnikov wrote: > > Hi Eric, > Thank you for your comments. > > (Today is about the worst time for me to reply to your comments, as I am > going on holidays tomorrow.) > > Eric Rescorla wrote: > > >$Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ > > > > > >OVERALL > >This document describes an extension to IMAP to provide faster > >synchronization between client and server. As far as I can > >tell, the optimizations are: > > > >- Removing one round trip needed to discover which messages > > have been expunged. > > > > > Yes, if compared to the case when the client/server also implement the > CONDSTORE extension (RFC 4551). > (Actually it removed 2 round trips per mailbox synchronization.) > > When compared to RFC 3501, this extension can potentially provides huge > bandwidth saving. If a client wants to synchronize flag changes in a > mailbox, the client needs to fetch flags for *all* mailboxes. For a > 30,000 message mailbox that I currently have is quite painful over a > slow link. I don't think it makes sense to compare this to 3501 without 4551, since 4551 is already an RFC. The question is whether this document should be advanced. What's the optimization compared to 4551? Also, you say it's "quite painful" now. How much less painful is it with this document. How about if compression is used. This seems like something where measurements would be nice. > >DETAILED COMMENTS > >S 2. > >This would be improved by some overall diagram of the new and > >old behavior and some measurement, even an ad hoc one, of > >the performance improvement. > > > > > Ok. An older version of this document had some numbers, but people > complained about "irrelevant text". Maybe I'm missing something, but those comparisons are to 3501, not CONDSTORE, right? > >S 3.3, 3.4, 3.5. > >These would all benefit from a statement of how they differ from > >3501, rather than just stating new rules. > > > > > (Actually, 3.5 updates UID EXPUNGE which was defined in RFC 4315.) > > Right. I believe some people wanted to see sections replacing the old > definitions, as opposed to just pointing out the difference from RFC 3501. As a wordsmithing issue, I would recommend adding a single clarificatory master section with these replacement definitions as subsections. > >S 3.6. > > The VANISHED response has two forms. The first form contains the > > EARLIER tag, which signifies that the response was caused by a UID > > FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This > > response is sent if the UID set parameter to the UID FETCH (VANISHED) > > command includes UIDs of messages that are no longer in the mailbox. > > When the client sees a VANISHED EARLIER response it MUST NOT > > decrement message sequence numbers for each successive message in the > > mailbox. > > > > The second form doesn't contain the EARLIER tag and is described > > below. Once a client has used "(VANISHED)" with a UID FETCH or > > "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the > > VANISHED response without the EARLIER tag instead of the EXPUNGE > > response. The server SHOULD continue using VANISHED in lieu of > > EXPUNGE for the duration of the connection. In particular this > > affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as > > well as messages expunged in other connections. Such VANISHED > > response MUST NOT contain the EARLIER tag. > > > >This is pretty unclear to the non-IMAP expert. Could you explain > >in english what this is trying to accomplish in the document, > >not just specify the protocol mechanics. > > > > > Basically the VANISHED response is used for 2 purposes: to report UIDs > of messages expunged earlier and to report UIDs of messages expunged now. > The difference between the two is that in the former case the client > doesn't need to decrement the number of messages in the mailbox, while > in the latter case it must. > The former can be distinguished from the latter by presence of the > "(EARLIER)" label. OK. That could be clearer in the main text. > >S 4.1. > > Strictly speaking, a server implementation that doesn't remember > > modsequences associated with expunged messages can be considered > > compliant with this specification. Such implementations return all > > expunged messages specified in the UID set of the UID FETCH > > (VANISHED) command every time, without paying attention to the > > specified CHANGEDSINCE modsequence. Such implementations are > > discouraged, as they can end up returning VANISHED responses bigger > > than the result of a UID SEARCH command for the same UID set. > > > >Isn't this inconsistent with: > > > > If the server is capable of storing modification sequences for the > > selected mailbox, it MUST increment the per-mailbox mod-sequence if > > at least one message was permanently removed due to the execution of > > the EXPUNGE command. For each permanently removed message the server > > MUST remember the incremented mod-sequence and corresponding UID. If > > at least one message got expunged, the server MUST send the updated > > per-mailbox modification sequence using the HIGHESTMODSEQ response > > code (defined in [CONDSTORE]) in the tagged OK response. > > > >If not, why not? > > > > > No, there is no inconsistency: > > "a server implementation that doesn't remember modsequences" == "a > server is incapable of storing modsequences". > The second paragraph you quoted is conditional on server's ability to > store modsequences. This behaviour is optional for servers. OK. I misread this. Thanks. > >S 5. > > The client MUST also take note of any MODSEQ FETCH data items > > received from the server. Whenever the client receives a tagged > > response to a command, it calculates the highest value among all > > MODSEQ FETCH data items received since the last tagged response. If > > this value is bigger than the client's copy of the HIGHESTMODSEQ > > value, then the client MUST use this value as its new HIGHESTMODSEQ > > value. > > > >So, I probably misunderstand something, but my read of 4551 made > >it seem like you could do a MODSEQ FETCH that would not return > >all the metadata for every message. > > > Yes, if the client issues a FETCH MODSEQ for a subset of messages. > However the previous paragraph in the same section requires the client > to perform a full synchronization. OK. > >In that case, wouldn't this > >procedure risk you having a modseq that is higher than some > >messages you haven't examined yet? What am I missing. > > > > > The intent of this paragraph is to talk about unsolicited FETCH MODSEQ > returned by the server *after* a full synchronization is complete (the > previous paragraph in the same section). So the situation you describe > can't happen, because the server is required to send all unsolicited > FETCH MODSEQ responses. > The beginning of this paragraph is ambiguous, so I suggest that it > should be clarified by changing the first quoted sentence to read: > > After completing full synchronization, the client MUST also take note of > any MODSEQ FETCH data items received from the server. WFM. -Ekr _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Oct 05 11:11:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdopC-0005Hc-Tx; Fri, 05 Oct 2007 11:10:46 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IdopB-0005G5-4w for lemonade-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 11:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdopA-0005FF-GD; Fri, 05 Oct 2007 11:10:44 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idop3-0000Ur-2r; Fri, 05 Oct 2007 11:10:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l95FAR6Z004709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2007 08:10:27 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l95FAP4S013851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 08:10:26 -0700 Date: Fri, 5 Oct 2007 08:10:23 -0700 (PDT) From: Mark Crispin To: Eric Rescorla Subject: Re: [lemonade] Re: Comments on draft-ietf-lemonade-reconnect-client-06 In-Reply-To: <20071005145321.F200933C21@delta.rtfm.com> Message-ID: References: <20071004222812.7BE7933C21@delta.rtfm.com> <47061D7C.5080808@isode.com> <20071005145321.F200933C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.10.5.74657 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P2 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf@ietf.org, secdir@ietf.org, lemonade@ietf.org, iesg@ietf.org, Dave Cridland , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 5 Oct 2007, Eric Rescorla wrote: >> When compared to RFC 3501, this extension can potentially provides huge >> bandwidth saving. If a client wants to synchronize flag changes in a >> mailbox, the client needs to fetch flags for *all* mailboxes. For a >> 30,000 message mailbox that I currently have is quite painful over a >> slow link. > I don't think it makes sense to compare this to 3501 without 4551, > since 4551 is already an RFC. The question is whether this document > should be advanced. What's the optimization compared > to 4551? Also, you say it's "quite painful" now. How much less > painful is it with this document. How about if compression is > used. This seems like something > where measurements would be nice. +1. Assuming that a typical FLAGS response is about 40 octets, then fetching all flags is 1,200,000 octets. This may be a bit slow over a 2.5G wireless network, but "quite painful" overstates the case somewhat. Also, this is only an issue for "disconnected" clients that insist upon synchronizing a local copy with the server. True "online" clients don't have this issue, and don't care about flags in messages that the user isn't viewing. Being an online client kind of guy, I see the problem as a flaw in the disconnected client model, especially as the whole idea of reconnect seems to be to make disconnected have similar real-time characteristics as online. I sympathize, but only to a limited degree. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Oct 05 13:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqlJ-0002ZD-Ub; Fri, 05 Oct 2007 13:14:53 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IdqlI-0002X4-MA for lemonade-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 13:14:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqlH-0002TB-VG; Fri, 05 Oct 2007 13:14:51 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdqlB-0004lu-2Z; Fri, 05 Oct 2007 13:14:51 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Oct 2007 18:14:32 +0100 Message-ID: <470670B0.3000603@isode.com> Date: Fri, 05 Oct 2007 18:13:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Rescorla References: <20071004222812.7BE7933C21@delta.rtfm.com> <47061D7C.5080808@isode.com> <20071005145321.F200933C21@delta.rtfm.com> In-Reply-To: <20071005145321.F200933C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: lemonade@ietf.org, iesg@ietf.org, Dave Cridland , ietf@ietf.org, secdir@ietf.org Subject: [lemonade] Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Rescorla wrote: >At Fri, 05 Oct 2007 12:18:20 +0100, >Alexey Melnikov wrote: > > >>Hi Eric, >>Thank you for your comments. >> >>(Today is about the worst time for me to reply to your comments, as I am >>going on holidays tomorrow.) >> >>Eric Rescorla wrote: >> >>>$Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ >>> >>> >>>OVERALL >>>This document describes an extension to IMAP to provide faster >>>synchronization between client and server. As far as I can >>>tell, the optimizations are: >>> >>>- Removing one round trip needed to discover which messages >>> have been expunged. >>> >>> >>Yes, if compared to the case when the client/server also implement the >>CONDSTORE extension (RFC 4551). >>(Actually it removed 2 round trips per mailbox synchronization.) >> >>When compared to RFC 3501, this extension can potentially provides huge >>bandwidth saving. If a client wants to synchronize flag changes in a >>mailbox, the client needs to fetch flags for *all* mailboxes. For a >>30,000 message mailbox that I currently have is quite painful over a >>slow link. >> >I don't think it makes sense to compare this to 3501 without 4551, >since 4551 is already an RFC. The question is whether this document >should be advanced. What's the optimization compared >to 4551? > CONDSTORE can significantly reduce bandwidth in some cases. It doesn't reduce the number of roundtrips. QRESYNC reduces number of roundtrips when compared to CONDSTORE or base IMAP. It can also reduce bandwidth in some cases (on top of the bandwidth reduction given by CONDSTORE). >Also, you say it's "quite painful" now. How much less >painful is it with this document. How about if compression is >used. This seems like something where measurements would be nice. > Yes. Dave will answer this ;-). >>>DETAILED COMMENTS >>>S 2. >>>This would be improved by some overall diagram of the new and >>>old behavior and some measurement, even an ad hoc one, of >>>the performance improvement. >>> >>> >>Ok. An older version of this document had some numbers, but people >>complained about "irrelevant text". >> >Maybe I'm missing something, but those comparisons are to 3501, >not CONDSTORE, right? > > Yes. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Oct 08 12:15:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevGK-0005Bo-V9; Mon, 08 Oct 2007 12:15:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IevGI-00059E-65 for lemonade-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 12:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevGH-00058s-PL; Mon, 08 Oct 2007 12:15:17 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IevGG-0003g5-MV; Mon, 08 Oct 2007 12:15:17 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 812BB26EB1; Mon, 8 Oct 2007 16:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IevG1-0001he-Dr; Mon, 08 Oct 2007 12:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Oct 2007 12:15:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-12.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP CONVERT extension Author(s) : A. Melnikov, P. Coates Filename : draft-ietf-lemonade-convert-12.txt Pages : 0 Date : 2007-10-8 CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. This document also extends IMAP URL schema defined in draft-ietf-lemonade-rfc2192bis-XX.txt with a specifier for a converted body part. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-convert-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-convert-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-8111541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-8111541.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Oct 11 20:09:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85a-0006YK-Sy; Thu, 11 Oct 2007 20:09:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ig85a-0006YD-5q for lemonade-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 20:09:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85Z-0006WS-Qz for lemonade@ietf.org; Thu, 11 Oct 2007 20:09:13 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig85Z-0003gI-BZ for lemonade@ietf.org; Thu, 11 Oct 2007 20:09:13 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C09BTa008150 for ; Thu, 11 Oct 2007 17:09:11 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08uV6030757 for ; Thu, 11 Oct 2007 17:09:10 -0700 Received: from 172.24.28.199 ([172.24.28.199]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Oct 2007 00:09:00 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 11 Oct 2007 18:22:23 -0400 From: Eric Burger To: Message-ID: Thread-Topic: Administrative Stuff Thread-Index: AcgMVTH1cMZpIHhIEdymOwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [lemonade] Administrative Stuff X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Our session at IETF 70 in Vancouver is tentatively set for Thursday, 6 December 2007, 1300 - 1500, Cypress Room Of course, that is subject to random changes. Check https://datatracker.ietf.org/meeting/70/agenda.html often for updates. I updated the supplemental web site to reflect the IETF 70 information, as well as some information on the Interop Event. Please check out the site, as I wrote up a brief introduction to lemonade. If you do not like it, or I missed you, please send me a note OFF LIST (directly to me). http://www.standardstrack.org/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Oct 11 20:09:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85d-0006Z9-1F; Thu, 11 Oct 2007 20:09:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ig85c-0006Z2-0I for lemonade-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 20:09From lemonade-bounces@ietf.org Thu Oct 11 20:09:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85a-0006YK-Sy; Thu, 11 Oct 2007 20:09:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ig85a-0006YD-5q for lemonade-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 20:09:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85Z-0006WS-Qz for lemonade@ietf.org; Thu, 11 Oct 2007 20:09:13 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig85Z-0003gI-BZ for lemonade@ietf.org; Thu, 11 Oct 2007 20:09:13 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C09BTa008150 for ; Thu, 11 Oct 2007 17:09:11 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08uV6030757 for ; Thu, 11 Oct 2007 17:09:10 -0700 Received: from 172.24.28.199 ([172.24.28.199]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Oct 2007 00:09:00 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 11 Oct 2007 18:22:23 -0400 From: Eric Burger To: Message-ID: Thread-Topic: Administrative Stuff Thread-Index: AcgMVTH1cMZpIHhIEdymOwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [lemonade] Administrative Stuff X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Our session at IETF 70 in Vancouver is tentatively set for Thursday, 6 December 2007, 1300 - 1500, Cypress Room Of course, that is subject to random changes. Check https://datatracker.ietf.org/meeting/70/agenda.html often for updates. I updated the supplemental web site to reflect the IETF 70 information, as well as some information on the Interop Event. Please check out the site, as I wrote up a brief introduction to lemonade. If you do not like it, or I missed you, please send me a note OFF LIST (directly to me). http://www.standardstrack.org/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Oct 11 20:09:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85d-0006Z9-1F; Thu, 11 Oct 2007 20:09:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ig85c-0006Z2-0I for lemonade-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 20:09:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85b-0006Yt-Mx for lemonade@ietf.org; Thu, 11 Oct 2007 20:09:15 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig85V-0003Y2-EF for lemonade@ietf.org; Thu, 11 Oct 2007 20:09:15 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08vda007908; Thu, 11 Oct 2007 17:08:57 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08uUk030757; Thu, 11 Oct 2007 17:08:56 -0700 Received: from 172.24.28.199 ([172.24.28.199]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Oct 2007 00:08:55 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 11 Oct 2007 17:29:38 -0400 Subject: Re: [lemonade] Re: profile-bis and ipv6 From: Eric Burger To: Arnt Gulbrandsen , Message-ID: Thread-Topic: [lemonade] Re: profile-bis and ipv6 Thread-Index: AcgMTdN5EdDehHhBEdymOwAWy4mm/w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Yes, we should mandate IPv6 In deference to Mark "Don't add anything" Crispin, I would offer we should be silent (because DUH, everything in the IETF *has* to work with IPv6). The finesse is to make sure at least ONE example uses IPv6 addressing :-) On 9/25/07 10:02 AM, "Arnt Gulbrandsen" wrote: > Dave Cridland writes: >> Speaking as an editor, I'd feel more comfortable adding this if there >> were visible consensus. >=20 > Noone has replied so far, either in the positive or negative. Zolt=E1n > replied with a followup question, to which I seemed to have the right > answer: "mandate only implementation, not deployment". >=20 > I interpret this as mildish agreement, not strong enough to be called > support. Perhaps Eric or Glenn could ask for a hum in the room at the > next meeting. >=20 > Arnt >=20 >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade :16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85b-0006Yt-Mx for lemonade@ietf.org; Thu, 11 Oct 2007 20:09:15 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig85V-0003Y2-EF for lemonade@ietf.org; Thu, 11 Oct 2007 20:09:15 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08vda007908; Thu, 11 Oct 2007 17:08:57 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08uUk030757; Thu, 11 Oct 2007 17:08:56 -0700 Received: from 172.24.28.199 ([172.24.28.199]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Oct 2007 00:08:55 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 11 Oct 2007 17:29:38 -0400 Subject: Re: [lemonade] Re: profile-bis and ipv6 From: Eric Burger To: Arnt Gulbrandsen , Message-ID: Thread-Topic: [lemonade] Re: profile-bis and ipv6 Thread-Index: AcgMTdN5EdDehHhBEdymOwAWy4mm/w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Yes, we should mandate IPv6 In deference to Mark "Don't add anything" Crispin, I would offer we should be silent (because DUH, everything in the IETF *has* to work with IPv6). The finesse is to make sure at least ONE example uses IPv6 addressing :-) On 9/25/07 10:02 AM, "Arnt Gulbrandsen" wrote: > Dave Cridland writes: >> Speaking as an editor, I'd feel more comfortable adding this if there >> were visible consensus. >=20 > Noone has replied so far, either in the positive or negative. Zolt=E1n > replied with a followup question, to which I seemed to have the right > answer: "mandate only implementation, not deployment". >=20 > I interpret this as mildish agreement, not strong enough to be called > support. Perhaps Eric or Glenn could ask for a hum in the room at the > next meeting. >=20 > Arnt >=20 >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Oct 15 10:03:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQXT-0005PM-Ai; Mon, 15 Oct 2007 10:03:23 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IhQXR-0005Oh-Qf for lemonade-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 10:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQXQ-0005OP-M4 for lemonade@ietf.org; Mon, 15 Oct 2007 10:03:20 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhQXJ-0001XH-Oe for lemonade@ietf.org; Mon, 15 Oct 2007 10:03:20 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9FE393Y010442 for ; Mon, 15 Oct 2007 07:03:09 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9FE30nK021694 for ; Mon, 15 Oct 2007 07:03:08 -0700 Received: from 172.24.29.123 ([172.24.29.123]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Oct 2007 14:03:07 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 15 Oct 2007 07:54:25 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Multiple Scripts for IMAP-Sieve Thread-Index: AcgPKoOKwe+CT3sdEdykBwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [lemonade] Multiple Scripts for IMAP-Sieve X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org While on the subject of "Don't Add Anything," we seemed to have had rough consensus on Randy's text for supporting multiple scripts for IMAP Sieve. However, it appears that consensus is eroding. Normally, the Chairs would offer to drop the text supporting per-client sieve scripts. However, we would like to visit Zoltan's request: My worry here is that we might release a genie from the bottle. I mean if Lemonade bis was released/deployed as is (with a single script setup), we might not be able to change that in the future - well, at least not easily and quickly because we are going to have to provide backwards compatibility until the old services are phase out. Would it be possible to build in some sort of safeguard so that we can change this later on without making it incompatible with existing Lemonade deployment? Some sort of future-proof-ish solution? We would like to hear people's observations on this ASAP, preferably before 19 October. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Oct 15 21:39:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbOV-0006gF-UT; Mon, 15 Oct 2007 21:38:51 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IhbOU-0006e0-D6 for lemonade-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 21:38:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbOT-0006da-8I for lemonade@ietf.org; Mon, 15 Oct 2007 21:38:49 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhbOS-0001ZD-Pg for lemonade@ietf.org; Mon, 15 Oct 2007 21:38:49 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9G1clxH023506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 15 Oct 2007 18:38:48 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-114.qualcomm.com [10.50.16.114]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9G1cjdL021715 for ; Mon, 15 Oct 2007 18:38:46 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <18269.1188373437.581860@peirce.dave.cridland.net> <18269.1188377299.947528@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 15 Oct 2007 18:36:12 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Re: profile-bis and ipv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 4:02 PM +0200 9/25/07, Arnt Gulbrandsen wrote: > Noone has replied so far, either in the positive or negative. I'm concerned with adding burdens for clients. I don't want to encourage IPv4-only implementations, but also don't want a client to be non-compliant just because it is running on an IPv4-ony device. Perhaps profile-bis can have a SHOULD for servers to support IPv6 for IMAP and submission, and a non-normative strong recommendation for clients to do the same? For example, "Both IMAP and message submission servers SHOULD support both IPv4 and IPv6. Clients are strongly encouraged to support IPv6. IPv6 support includes numerous aspects, such as using AAAA records returned in DNS query results, permitting and using IPv6 addresses in configuration information, the ability to connect to IPv6 addresses, and for servers, listening on IPv6 addresses." I won't object if people want to make client support also a SHOULD, but I want to be sure we've discussed it and it won't be a problem. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Arguments are to be avoided; they are always vulgar and often convincing. --Oscar Wilde _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Oct 16 11:36:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhoSL-0004EV-MD; Tue, 16 Oct 2007 11:35:41 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IhoSK-0004E0-2s for lemonade-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 11:35:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhoSI-0004Dc-9d; Tue, 16 Oct 2007 11:35:38 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhoSH-00084n-R2; Tue, 16 Oct 2007 11:35:38 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1192548935!17664812!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.149] Received: (qmail 31435 invoked from network); 16 Oct 2007 15:35:35 -0000 Received: from sbcsmtp9.sbc.com (HELO flph024.enaf.ffdc.sbc.com) (144.160.128.149) by server-2.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 16 Oct 2007 15:35:35 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l9GFZXJW004184; Tue, 16 Oct 2007 08:35:34 -0700 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l9GFZUPU004153; Tue, 16 Oct 2007 08:35:30 -0700 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l9GFZUK2010970; Tue, 16 Oct 2007 08:35:30 -0700 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l9GFZQHk010894; Tue, 16 Oct 2007 08:35:26 -0700 Received: from [135.210.128.98] (unknown[135.210.128.98](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20071016153524gw10010gsme> (Authid: tony); Tue, 16 Oct 2007 15:35:25 +0000 Message-ID: <4714DA04.5010308@att.com> Date: Tue, 16 Oct 2007 11:34:28 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: SMTP Interest Group References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ietf-822 mailing list , LEMONADE WG mailing list , POP3 extensions mailing list , USEFOR WG , EAI WG mailing list , IMAP extensions mailing list Subject: [lemonade] Mailing List Last Call now open for draft-klensin-rfc2821bis-05.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This is a "formal" Mailing List Last Call on draft-klensin-rfc2821bis-05.txt. The last call will last for two weeks time, ending on October 30, 2007. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Simple Mail Transfer Protocol > Filename : draft-klensin-rfc2821bis-05.txt >... > http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-05.txt If you go to http://tools.ietf.org/html/draft-klensin-rfc2821bis and click on [Diff1], you'll see a highlighted list of changes between this and the previous version. Major changes for this release are indicated in Appendix G.7. G.7. Changes from version -04 to -05 1. Added registry pointers to Section 8 (issue 36). 2. "for" clause in Received header reduced to a single mailbox, since this seems to reflect list consensus (issue 37). An "additional registered clauses" entry was made to allow for future extension (also issue 37). 3. Corrected some I-D references to point to now-published RFCs. At this point, all extant issues are considered closed. The Mailing List Last Call is now declared open. Depending on the outcome of the Mailing List Last Call, the next step will be to submit the document (or its revision) to the IESG for IETF-wide Last Call. Thanks! Tony Hansen tony@att.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Oct 16 18:09:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihuah-0003JZ-AL; Tue, 16 Oct 2007 18:08:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ihuaf-0003JC-CQ for lemonade-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 18:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihuae-0003HZ-If for lemonade@ietf.org; Tue, 16 Oct 2007 18:08:40 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhuaW-00006A-4I for lemonade@ietf.org; Tue, 16 Oct 2007 18:08:38 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9GM8Fdx001958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Oct 2007 15:08:16 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-82.qualcomm.com [10.50.0.82]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9GM8D9I004201; Tue, 16 Oct 2007 15:08:14 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.com> <1245869244.74581188915973031.JavaMail.root@dogfood.zimbra.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157010A8B32@esebe199.NOE.Nokia.com> <01ML02AX0B3Y00005F@mauve.mrochek.com> <301726258D35308A27110E08@caldav.corp.apple.com> References: <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com><4C38 DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.com> <1245869244.74581188915973031.JavaMail.root@dogfood.zimbra.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <01ML02AX0B3Y00005F@mauve.mrochek.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157010A8B32@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <01ML02AX0B3Y00005F@mauve.mrochek.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47E8@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157FE47FB@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15701030B31@esebe199.NOE.Nokia.com> <11D923A4EB7367A2ACC1138F@caldav.corp.apple.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1570107425A@esebe199.NOE.Nokia.com> <301726258D35308A27110E08@caldav.corp.apple.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 16 Oct 2007 15:06:11 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: -4.0 (----) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: leiba@watson.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Sorry for the delay in responding. At 11:27 AM +0300 9/3/07, wrote: > But I see no text saying that the message MUST NOT be expunged until all > scripts have finished. If the text goes forward, a statement to this effect can be added, just to make it very clear. > Ok, so let' take this a step further. > There is a new mail arriving, and we have scripts A, B and C from > clients A, B and C respectively. The new mail triggers both A and B > scripts. > The result of script A is to delete the email. The result of script B is > to move (copy+delete, right?) the email to a different mailbox. The > result of script C is to notify about new mail. So, A copy of the email > is placed into another mailbox and finally the mail is deleted and C is > notified. The deposit of the new mail to the other mailbox (the copy > action of script B) triggers at least script A (since it was script B > making the change, I assume that it will not trigger itself to avoid > loops) and C. The result of script C is to notify about new mail. The > result of script A is to delete the email (same result as before). > Script A triggers script B and C. B does nothing, C is notified again. > Problems: > - the email that B wanted to move somewhere else is deleted > - C receives four notifications when "nothing" really happened (a new > mail arrived, copied, but deleted both). This can be optimized though. > - If C wanted a copy of the mail (justl like B), script A would have > deleted it. > - What if scripts A and B moved (copy+delete) the email between two > different mailboxes continuously (infinite loop)? The existing language in the draft (for a single script) makes it clear that actions that are the result of a script do not cause the script to execute. In proposing text to permit multiple scripts, I attempted to carry this forward. I think this is one way to simplify multiple script handling: actions taken by any script are applied after the scripts execute and do not trigger scripts. > There is nothing wrong with the text - I just got the feeling that > something is missing. I can't tell what, but something does not feel > right. Perhaps after we went through a few use cases, we can come up > with a solid proposal. The text I proposed was very minimal, I admit. I wanted to show that it was possible to extend the draft to cover multiple scripts, and that doing so could be constrained to minimize the complexity. If the concept has acceptance in the group, further restrictions and details can be added to remove ambiguity. > >thinking that any identifier for the device could be used, but even a >>random number with a reasonable range would suffice. > > I guess a client could figure out the allocated random IDs by doing a > simple query to the server - so it could figure out a unique random ID > for itself if needed. The per-client component is up to the client, and I suggested that any identifier for the device could be used, or that a random value could also be used. I didn't mean that a random value must be used, only that a client could choose to use a random value or incorporate a random value. I think an identifier for the device, if available, is better. An example of a device identifier might be an ESN, if available. Maybe even a MIN? > Could we add then (with a requirement saying that it must be > unique within the scope of the client-id; could be any number of hexa > digits, case insensitive? 0-9, a-f, A-F)? > So the whole ID would look like: .. > > A requirement might be also needed to store the in a safe > place. Some clients overwrite/delete user data when the > OS/client/firmware is updated. If the random id is lost, there will be > no way to identify which client owned the script and it wil be hanging > there for an eternity. I'm not sure a random component is needed. I was only suggesting that, in the absence of a better identifier, one could be used. > > Could this ID be re-used? Well, at least the . > part of it - for example, to store client-specific preferences on the > server? We should explore this when we do client-specific preferences that are stored on the server. At 10:03 AM -0400 9/4/07, Cyrus Daboo wrote: > I think as Zoltan's examples show this is getting way too > complicated. Having multiple "competing" scripts being executed > like this is a recipe for disaster. Lets drop this aspect of the > spec and see whether the rest will actually get implemented and be > interoperable first. Then, if there really is demand, we can > consider per-client scripts as an extension. I think this can be done without allowing it to get too complicated, and I would agree that we shouldn't do this if it can't be done fairly simply. The key is to enough constraints to keep it simple, while still useful. But if we choose not to do so, and if we think that we might want to revisit this, then we need to look carefully at the draft to make sure that it isn't doing anything that would get in the way of such an extension. At 9:35 AM -0400 9/5/07, Cyrus Daboo wrote: > I question whether there is a need to do it this way at all. I > think an adequate solution for most cases is to allow manual > triggering of scripts by clients. That way clients can apply their > own scripts when they actually interact with the server. I'm not sure manual execution of a script really addresses the usefulness or solves a problem. > The whole business of allowing clients to upload their own scripts > which get automatically handled and considered "private" to each > client is awkward. For example, what happens if a user stops using > a client? How does the script for that client get disabled? Does > there have to be some sort of script management UI in every client > so users can manage other client's scripts use etc? What I proposed is that old script age out and get reaped by the server. (This was in the proposed new section called "Automatic Deletion of Old Scripts".) That way there is no need for a script management UI. At 1:22 PM -0700 9/5/07, Ned Freed wrote: > However, delivery time processing is a better defined problem (it is, after > all, the place Sieve was deisned to operate) and there are some simplifying > assumptions having to do with ranking of multiple sieves that I > don't think are > possible in the context of IMAP. I therefore support dropping this for now. Per-client (and per-device) scripts might be better at delivery time rather than as part of IMAP. I'm not sure. At 12:01 PM +0300 9/6/07, wrote: > My worry here is that we might release a genie from the bottle. > I mean if Lemonade bis was released/deployed as is (with a single > script setup), we might not be able to change that in the future - > well, at least not easily and quickly because we are going to have > to provide backwards compatibility until the old services are phase > out. > Would it be possible to build in some sort of safeguard so that we > can change this later on without making it incompatible with > existing Lemonade deployment? Some sort of future-proof-ish > solution? That's a matter of carefully reading the draft to see if a future extension along these lines would cause problems. If we miss something, then we'll have to deal with it when we try and extend it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- In politics stupididty is not a handicap. --Napoleon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Oct 17 18:09:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiH42-0007u5-IG; Wed, 17 Oct 2007 18:08:30 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IiH40-0007mc-Dr for lemonade-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 18:08:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiH3z-0007jm-ER for lemonade@ietf.org; Wed, 17 Oct 2007 18:08:27 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiH3y-0005L6-PC for lemonade@ietf.org; Wed, 17 Oct 2007 18:08:27 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9HM8NQo025228; Thu, 18 Oct 2007 01:08:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 01:08:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 01:08:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Re: profile-bis and ipv6 Date: Thu, 18 Oct 2007 01:08:29 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Re: profile-bis and ipv6 Thread-Index: AcgPliLWE5S/g5pBQfmwrcGi5V/PxQBQSnIg References: <18269.1188373437.581860@peirce.dave.cridland.net><18269.1188377299.947528@peirce.dave.cridland.net> From: To: , X-OriginalArrivalTime: 17 Oct 2007 22:08:22.0607 (UTC) FILETIME=[3B866DF0:01C8110A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, email is an application-level protocol, it should work regardless = whether IPv4 or IPv6 packets are carrying the data. Therefore, I am not convinced that Lemonade is the right place to = promote IPv6. Could we just leave all IP version discussions out? The best we can do is SHOULD for both IPv4 and IPv6 for both clients = and servers anyway - we can't mandate IPv4 for the next 30 years, and we = can't mandate IPv6 today either. A SHOULD is not really useful, = therefore I suggest we leave IP version discussions out. Any thoughts? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 >Sent: 16 October, 2007 04:36 >To: lemonade@ietf.org >Subject: Re: [lemonade] Re: profile-bis and ipv6 > >At 4:02 PM +0200 9/25/07, Arnt Gulbrandsen wrote: > >> Noone has replied so far, either in the positive or negative. > >I'm concerned with adding burdens for clients. I don't want=20 >to encourage IPv4-only implementations, but also don't want a=20 >client to be non-compliant just because it is running on an=20 >IPv4-ony device. > >Perhaps profile-bis can have a SHOULD for servers to support=20 >IPv6 for IMAP and submission, and a non-normative strong=20 >recommendation for clients to do the same? For example, "Both=20 >IMAP and message submission servers SHOULD support both IPv4=20 >and IPv6. Clients are strongly encouraged to support IPv6. =20 >IPv6 support includes numerous aspects, such as using AAAA=20 >records returned in DNS query results, permitting and using=20 >IPv6 addresses in configuration information, the ability to=20 >connect to IPv6 addresses, and for servers, listening on >IPv6 addresses." > >I won't object if people want to make client support also a=20 >SHOULD, but I want to be sure we've discussed it and it won't=20 >be a problem. >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly-selected tag: --------------- >Arguments are to be avoided; they are always vulgar and often=20 >convincing. --Oscar Wilde > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Oct 17 19:15:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiI6a-0003gh-Mj; Wed, 17 Oct 2007 19:15:12 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IiI6Y-0003ap-K0 for lemonade-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 19:15:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiI6X-0003P8-Ii for lemonade@ietf.org; Wed, 17 Oct 2007 19:15:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiI6U-0007lP-RQ for lemonade@ietf.org; Wed, 17 Oct 2007 19:15:07 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9HNF5hG016550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Oct 2007 16:15:05 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-82.qualcomm.com [10.50.0.82]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9HNF1h8011199; Wed, 17 Oct 2007 16:15:04 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <18269.1188373437.5818 60@peirce.dave.cridland.net><18269.1188377299.947528@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Oct 2007 16:11:19 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] Re: profile-bis and ipv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Zoltan, At 1:08 AM +0300 10/18/07, wrote: > email is an application-level protocol, it should work regardless > whether IPv4 or IPv6 packets are carrying the data. It should work either way, but won't work with IPv6 unless both the client and the server have taken active steps to support IPv6. This includes the specific items that Arnt mentioned which I used in my suggested text. > Therefore, I am not convinced that Lemonade is the right place to > promote IPv6. It isn't a question of promoting or evangelizing IPv6 (I agree lemonade is not the place to do that). It's a matter of interoperability in IPv6 deployments. > Could we just leave all IP version discussions out? > The best we can do is SHOULD for both IPv4 and IPv6 for both > clients and servers anyway - we can't mandate IPv4 for the next 30 > years, and we can't mandate IPv6 today either. Remember that we are only discussing what needs to be implemented in the code, we are not mentioning what is deployed. In reality, any implementation that doesn't support IPv4 won't interoperate with the vast majority of implementations. Likewise, any implementation that doesn't support IPv6 is limited to only working with IPv4 implementations. This is regardless of what the carriers, ISPs, and email providers choose to deploy. Perhaps this would be better in an update of the deployments draft, but I'm a but leery of reopening that document right now. > A SHOULD is not really useful, therefore I suggest we leave IP > version discussions out. > Any thoughts? Why is a SHOULD not really useful? > >-----Original Message----- >>From: ext Randall Gellens [mailto:randy@qualcomm.com] >>Sent: 16 October, 2007 04:36 >>To: lemonade@ietf.org >>Subject: Re: [lemonade] Re: profile-bis and ipv6 >> >>At 4:02 PM +0200 9/25/07, Arnt Gulbrandsen wrote: >> >>> Noone has replied so far, either in the positive or negative. >> >>I'm concerned with adding burdens for clients. I don't want >>to encourage IPv4-only implementations, but also don't want a >>client to be non-compliant just because it is running on an >>IPv4-ony device. >> >>Perhaps profile-bis can have a SHOULD for servers to support >>IPv6 for IMAP and submission, and a non-normative strong >>recommendation for clients to do the same? For example, "Both >>IMAP and message submission servers SHOULD support both IPv4 >>and IPv6. Clients are strongly encouraged to support IPv6. >>IPv6 support includes numerous aspects, such as using AAAA >>records returned in DNS query results, permitting and using >>IPv6 addresses in configuration information, the ability to >>connect to IPv6 addresses, and for servers, listening on >>IPv6 addresses." >> >>I won't object if people want to make client support also a >>SHOULD, but I want to be sure we've discussed it and it won't >>be a problem. >>-- >>Randall Gellens >>Opinions are personal; facts are suspect; I speak for myself only >>-------------- Randomly-selected tag: --------------- >>Arguments are to be avoided; they are always vulgar and often >>convincing. --Oscar Wilde >> >> >>_______________________________________________ >>lemonade mailing list >>lemonade@ietf.org >>https://www1.ietf.org/mailman/listinfo/lemonade >>Supplemental Web Site: >>http://www.standardstrack.com/ietf/lemonade >> > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The whole dream of democracy is to raise the proletarian to the level of stupidity attained by the bourgeois. --Gustave Flaubert _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Oct 18 04:31:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiQm1-0007zj-Hf; Thu, 18 Oct 2007 04:30:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IiQlz-0007xj-37 for lemonade-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 04:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiQlx-0007rL-DA for lemonade@ietf.org; Thu, 18 Oct 2007 04:30:29 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiQln-0006zY-E1 for lemonade@ietf.org; Thu, 18 Oct 2007 04:30:25 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 56B444AC5A; Thu, 18 Oct 2007 10:30:25 +0200 (CEST) Message-Id: Date: Thu, 18 Oct 2007 10:30:15 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: profile-bis and ipv6 References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: randy@qualcomm.com, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com writes: > email is an application-level protocol, it should work regardless > whether IPv4 or IPv6 packets are carrying the data. > Therefore, I am not convinced that Lemonade is the right place to > promote IPv6. > Could we just leave all IP version discussions out? > The best we can do is SHOULD for both IPv4 and IPv6 for both clients > and servers anyway - we can't mandate IPv4 for the next 30 years, and > we can't mandate IPv6 today either. A SHOULD is not really useful, > therefore I suggest we leave IP version discussions out. > Any thoughts? Several. 1. Lemonade isn't IMAP or SMTP, which just use a byte stream. For example Lemonade profile uses URLs for forward without download. URL parsers typically have to know the format of IP addresses. URL retrievers typically have to do a DNS lookup and connect the the IP address(es) returned. (The latter may not be necessary if there's a 4468bis, I think it was required more by mistake than by intention). 2. I am not concerned with promoting IPv6 (which is something one shouldn't do anyway, IMO), but rather with avoiding hidden little snags that would make it harder for sites to transition. 3. Last but not least, when I made the proposal I didn't know that OMA already has some sort of IPv6 requirement (in a general document, not the mail document). I don't think I would have bothered if I'd known that. Maybe I would have suggested an informative sentence in profile-bis pointing out the OMA mandate. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Oct 22 13:31:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik16t-0004MO-VF; Mon, 22 Oct 2007 13:30:39 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ik16q-0004G0-RA for lemonade-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 13:30:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik16p-0004DM-Kf; Mon, 22 Oct 2007 13:30:35 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik16p-0002i0-AF; Mon, 22 Oct 2007 13:30:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3AE142AC88; Mon, 22 Oct 2007 17:30:05 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ik16L-0007V0-02; Mon, 22 Oct 2007 13:30:05 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 22 Oct 2007 13:30:05 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: lemonade mailing list , lemonade chair , Internet Architecture Board , RFC Editor Subject: [lemonade] Protocol Action: 'IMAP4 Extensions for Quick Mailbox Resynchronization' to Proposed Standard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The IESG has approved the following document: - 'IMAP4 Extensions for Quick Mailbox Resynchronization ' as a Proposed Standard This document is the product of the Enhancements to Internet email to Support Diverse Service Environments Working Group. The IESG contact persons are Chris Newman and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-06.txt Technical Summary This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response with a more compact representation for a list of expunged messages. Working Group Summary There is consensus in the WG to publish this document. There are three client implementations and four server implementations by work group members. Protocol Quality Virtually all members of the Lemonade WG have reviewed the document. The document has been checked manually and using idnits 2.04.01, and passed both checks. Eric Burger shepherds this document, has reviewed this document, and believes that this version is ready for publication. This document has been reviewed for the IESG by Chris Newman. Gen-ART review was performed by Brian E Carpenter. Note to RFC Editor OLD: This document defines the X-DRAFT-W05-QRESYNC [[anchor22: The final ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ capability name will be chosen during AUTH48]] IMAP capability. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NEW: This document defines the QRESYNC IMAP capability. ^^^^^^^ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Oct 23 05:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFjV-0007yO-NC; Tue, 23 Oct 2007 05:07:29 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IkFjV-0007yH-4E for lemonade-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 05:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFjT-0007xr-Ms for lemonade@ietf.org; Tue, 23 Oct 2007 05:07:27 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkFjN-0005Ej-9z for lemonade@ietf.org; Tue, 23 Oct 2007 05:07:27 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9N96vfC006207; Tue, 23 Oct 2007 12:07:09 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 12:06:55 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 12:06:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Re: profile-bis and ipv6 Date: Tue, 23 Oct 2007 12:07:00 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Re: profile-bis and ipv6 Thread-Index: AcgRE5HxipgAEG0BRnOF2nM/aLhsiAEQByXQ References: <18269.1188373437.5818 60@peirce.dave.cridland.net><18269.1188377299.947528@peirce.dave.cridland.net> From: To: , X-OriginalArrivalTime: 23 Oct 2007 09:06:54.0180 (UTC) FILETIME=[0E52C240:01C81554] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randall, >Perhaps this would be better in an update of the deployments=20 >draft, but I'm a but leery of reopening that document right now. I was going to suggest the deployments draft myself - the reason I did = not because it is well on its way to become an RFC. So, I proposed = leaving out these discussions instead. >Why is a SHOULD not really useful? Because people will always find a very good reason not to do it. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Oct 23 05:21:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFwY-0003UY-26; Tue, 23 Oct 2007 05:20:58 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IkFwW-0003NY-Cu for lemonade-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 05:20:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFwV-0003ML-Dl for lemonade@ietf.org; Tue, 23 Oct 2007 05:20:55 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkFwU-0006J6-NL for lemonade@ietf.org; Tue, 23 Oct 2007 05:20:55 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9N9KZ7C017472; Tue, 23 Oct 2007 12:20:48 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 12:20:03 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 12:16:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Re: profile-bis and ipv6 Date: Tue, 23 Oct 2007 12:16:42 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Re: profile-bis and ipv6 Thread-Index: AcgRYRb0gbWWcQbZS7Gs+a1CrVLoLAD8wuRA References: From: To: , X-OriginalArrivalTime: 23 Oct 2007 09:16:36.0531 (UTC) FILETIME=[696E7830:01C81555] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: randy@qualcomm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Arnt, >1. Lemonade isn't IMAP or SMTP, which just use a byte stream.=20 >For example Lemonade profile uses URLs for forward without=20 >download. URL parsers typically have to know the format of IP=20 >addresses. URL retrievers typically have to do a DNS lookup=20 >and connect the the IP >address(es) returned. (The latter may not be necessary if=20 >there's a 4468bis, I think it was required more by mistake=20 >than by intention). Hmmm. I do not think that we have specified whether IPv4 or IPv6 should be used in URLs to be used with forward without download. Or, are You proposing to open up the draft and mandate IPv6? >2. I am not concerned with promoting IPv6 (which is something=20 >one shouldn't do anyway, IMO), but rather with avoiding hidden=20 >little snags that would make it harder for sites to transition. I agree. >3. Last but not least, when I made the proposal I didn't know=20 >that OMA already has some sort of IPv6 requirement (in a=20 >general document, not the mail document). I don't think I=20 >would have bothered if I'd known that. Maybe I would have=20 >suggested an informative sentence in profile-bis pointing out=20 >the OMA mandate. I did not have the time to look up the OMA reference. But the question is: where would we include it? The deployments draft is pretty much a done deal. Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Oct 23 14:26:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkORY-0001ac-Bf; Tue, 23 Oct 2007 14:25:32 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1IkORX-0001aD-DE for lemonade-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 14:25:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkORX-0001a2-2v for lemonade@ietf.org; Tue, 23 Oct 2007 14:25:31 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkORW-0003Hg-J6 for lemonade@ietf.org; Tue, 23 Oct 2007 14:25:30 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 23 Oct 2007 19:25:28 +0100 Message-ID: <471E3C86.6030208@isode.com> Date: Tue, 23 Oct 2007 19:25:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [lemonade] Second Lemonade interop event X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi everybody, I would like to announce the Second Lemonade Interop event to be held in Munich, Germany on November 19th and 20th. The event will be kindly hosted by Oryx this time. Unless you already told me, please email me directly whether you will attend in person or if you want to participate remotely. The following information was provided by Arnt Gulbrandsen from Oryx: The event will be held in the Amalienstrasse in Schwabing, the=20 university area teeming with caf=E9s and so on. Two inexpensive, decent=20 hotels (as Germans consider such things) are at carlton-garni.de and=20 hotel-lettl.de, both in the immediate vicinity. Getting there from the=20 airport involves taking the S1/S8 train to Marienplatz (both lines take=20 you there, only the route varies) and from there either U3 or U6 two=20 hops northwards to Universit=E4t. Regards, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade