From lemonade-bounces@ietf.org Sun Apr 01 09:01: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 1HXzge-0002Qu-BY; Sun, 01 Apr 2007 09:01:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXzgd-0002Qj-Eo for lemonade@ietf.org; Sun, 01 Apr 2007 09:01:35 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXzga-0001kR-Tx for lemonade@ietf.org; Sun, 01 Apr 2007 09:01:35 -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 ; Sun, 1 Apr 2007 14:01:19 +0100 Message-ID: <460E9CCB.4020109@isode.com> Date: Sat, 31 Mar 2007 18:39:23 +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: Neil Cook Subject: Re: [lemonade] WGLC streaming References: <4608EF81.5050401@isode.com> <19EF7922-B37F-41DB-98AF-3F8F22FD06CE@noware.co.uk> In-Reply-To: <19EF7922-B37F-41DB-98AF-3F8F22FD06CE@noware.co.uk> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: lemonade@ietf.org 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 Neil Cook wrote: >> 3). In section 2.3 >> >>> Clients SHOULD parse the value of mediaServers, (using either the >>> value.priv or value.shared: whichever is available and/or >>> appropriate), and contact a media server using one of the supplied >>> values. No particular preference order is implied by the ordering, >> >> I would prefer is the order specified by the server is the preferred >> order. > > As Dave mentioned, the client may know better. Perhaps I should that > that the server lists the preferred order, but the client may choose > to ignore the order if it knows better. Yes, this is what I want. I would rather not encourage clients to do stupid things, like random selection, when the server has preferences and the client doesn't care. [...] >>> Similarly, the message may well be encoded with a content transfer >>> encoding such as base 64. However, RFC 4240 does not include a >>> method for communicating content transfer encoding to the media >>> server as part of the announcement service, nor does the URLFETCH >>> command include a mechanism for retrieving message parts without >>> encoding (c.f. the BINARY [17] extension to IMAP). >> >> Would it be better if IMAP URL is extended to allow for binary content >> fetching? > > Well this is a tricky one. I would actually prefer it if it was, > because it means I wouldn't have to extend both netann and mscml with > c-t-e parameters. What is the likelihood of getting IMAP URL modified > to allow binary fetches? IMAP URL would be easy, potentially no change at all. However URLFETCH doesn't currently allow fetching of a bodypart as binary. >> 5). In section 2.6 >> >> C: INVITE sip:annc@ms2.example.net; \ >> play=imap://joe@example.com/INBOX/;uid=24356/;section=1.2;\ >> expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\ >> internal:238234982398239898a9898998798b987s87920; \ >> content-type=video/mpeg; \ >> content-transfer-encoding=base64 SIP/2.0 >> >> A curiosity question: does the content of the play parameter has to be >> surrounded by '"'? > > RFC 4240 says not. Ok. [...] >>> However, in this case, if >>> >>> the URL supplied in the 'play' parameter of the SIP INVITE specifies >>> an authorization of 'authuser', then the media server SHOULD NOT >>> attempt to contact the IMAP server, but SHOULD instead immediately >>> return a response code of 404 to the client with a reason phrase of >>> 'Not authorized to access resource' reason. >> >> 7). Flow diagrams in section 2.9 don't show IMAP responses. This might >> be Ok. > > I tried to leave out non-essential responses in the flow diagrams. If > anyone has any strong objection that that, please let me know. They > are really just to show overall flow, not show every protocol exchange. Both Dave and myself are in favor of adding main IMAP responses to the diagram. >> 9). In section 5: >> >>> media-servers = ms-tuple *(";" ms-tuple) >>> >>> host = astring >> >> If you mean the RFC 3501 "astring" here, then I don't think this is >> what >> you actually want, as it allows for IMAP literals and quoted strings. >> I suggest you use "host" non-terminal from RFC 3986. But if you follow >> this suggestion, be aware that "host" requires that IP addresses be >> enclosed in '[]'. >> If you don't want that, you need to find more suitable productions in >> RFC 3986. > > Yes, host from RFC 3986 looks good. However, looks like only IPv6 > addresses need to be enclosed in []. > > BTW, what is the form for including ABNF definitions from other RFCs? > Do I just copy the whole set of definitions out, or can I reference > them in a standard way? You reference productions from other RFCs by reference. At the top of the ABNF section you mention RFCs that define ABNF productions not defined in your document. >> 10). There is no "IANA Considerations" section. One should be added and >> contain text about a METADATA annotation registration, as well as the >> registration of new SIP, etc. parameters. > > Yes, I'll move the METADATA annotation stuff into a separate IANA > Considerations section. You don't need to move all METADATA related text to the IANA section, only the registration. Just try to preserve readability of the 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 Sun Apr 01 09:01: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 1HXzge-0002Qp-7I; Sun, 01 Apr 2007 09:01:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXzgc-0002QQ-C9 for lemonade@ietf.org; Sun, 01 Apr 2007 09:01:34 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXzga-0001jq-Tx for lemonade@ietf.org; Sun, 01 Apr 2007 09:01:34 -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 ; Sun, 1 Apr 2007 14:01:17 +0100 Message-ID: <460E99FA.6030307@isode.com> Date: Sat, 31 Mar 2007 18:27:22 +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: Neil Cook Subject: Re: [lemonade] WGLC streaming References: <4608EF81.5050401@isode.com> <6000.1175008017.686117@peirce.dave.cridland.net> <35A5A4A1-D3ED-41EE-A521-1C3C95AA885A@noware.co.uk> In-Reply-To: <35A5A4A1-D3ED-41EE-A521-1C3C95AA885A@noware.co.uk> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: support diverse service enivronments , Enhancements 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 Neil Cook wrote: >>> 3). In section 2.3 >>> >>>> Clients SHOULD parse the value of mediaServers, (using either the >>>> value.priv or value.shared: whichever is available and/or >>>> appropriate), and contact a media server using one of the supplied >>>> values. No particular preference order is implied by the >>>> ordering, >>> >>> I would prefer is the order specified by the server is the >>> preferred order. >> >> I'm not sure it matters overmuch. It might be that the client can >> identify which server is closest better than the server. It really >> depends upon what we mean by "preferred". >> >>>> Similarly, the message may well be encoded with a content transfer >>>> encoding such as base 64. However, RFC 4240 does not include a >>>> method for communicating content transfer encoding to the media >>>> server as part of the announcement service, nor does the URLFETCH >>>> command include a mechanism for retrieving message parts without >>>> encoding (c.f. the BINARY [17] extension to IMAP). >>> >>> Would it be better if IMAP URL is extended to allow for binary content >>> fetching? >> >> I think that might well be neater, although it depends on which >> extension requires more work. >> >>> 7). Flow diagrams in section 2.9 don't show IMAP responses. This might >>> be Ok. >> >> I think it'd be clearer if they were there. (Again, this is FETCH >> BODY[MIME], rather than FETCH BODYSTRUCTURE). > > I'd be okay with adding the IMAP responses if folks think it would > make it clearer. Again, the FETCH BODY[MIME] is just to match with > the previous example. Maybe show both, e.g. in 2 different examples? > I don't think this document is going to be used as a guide to writing > IMAP clients, or how to retrieve body structure. You might be surprised :-). IMHO, implementors usually use examples from RFCs to write their clients. (Except for Dave, of course ;-)) [...] >>> 10). There is no "IANA Considerations" section. One should be added >>> and >>> contain text about a METADATA annotation registration, as well as the >>> registration of new SIP, etc. parameters. >> >> The Metadata annotation registration is in 2.3, but yes, it needs to >> be moved. >> >> Further comments - and please note that the majority of the SIP >> stuff goes shooting over my head: >> >> In the Security Considerations section, there seems to be a sudden >> lack of references. In particular, sips, SIP, RFC4240, RFC4722, and >> S/MIME all lack references (although they're in the Normative >> References section). > > I have been in somewhat of a quandry about that. Do I reference > *everytime* I mention another standard? Yes, usually you do. At least you do the first time you reference a standard. Note that references that are not essential for implementing an RFC are put into the Informative References section. > I got the feeling that by the end of the doc, if various protocols > have been referenced enough, they probably don't need any more, but > I'd be happy to be corrected on that. Obviously any in that section > which haven't been referenced before should be referenced. _______________________________________________ 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 Apr 02 09:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMuD-00039Z-Jt; Mon, 02 Apr 2007 09:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMuC-00039U-GU for lemonade@ietf.org; Mon, 02 Apr 2007 09:49:08 -0400 Received: from stiedprtick1-ext.va.neustar.com ([156.154.16.147] helo=ticket.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMuB-00007X-Bm for lemonade@ietf.org; Mon, 02 Apr 2007 09:49:08 -0400 Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1HYMuB-0008Sz-8z for lemonade@ietf.org; Mon, 02 Apr 2007 09:49:07 -0400 From: " via RT" In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #94503 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: Rebecca.Bunch@Neustar.biz To: lemonade@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Mon, 02 Apr 2007 09:49:07 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [lemonade] [Inquiry #94503] Resolved: Updated Liaison Statement, "Update on LEMONADE activity" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Reply-To: statements@ietf.org 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 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. _______________________________________________ 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 Apr 03 00:31:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYag3-0001n9-0p; Tue, 03 Apr 2007 00:31:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYag1-0001n1-UK for lemonade@ietf.org; Tue, 03 Apr 2007 00:31:25 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYafz-0001vg-7W for lemonade@ietf.org; Tue, 03 Apr 2007 00:31:25 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id EB791810397; Mon, 2 Apr 2007 21:24:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id C47CF47943; Mon, 2 Apr 2007 21:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtH-7sZdNMoF; Mon, 2 Apr 2007 21:31:15 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 0ADF347942; Mon, 2 Apr 2007 21:31:15 -0700 (PDT) Date: Mon, 2 Apr 2007 21:31:14 -0700 (PDT) From: Dan Karp To: Eric Burger Message-ID: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.193.195] X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG 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 > http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt Comments interspersed btween snippets of the draft: Changes from -10 to -11: 7. Added match type and collation identifier to the LIST-EXTENDED selection option. 8. Made support for IMAP-I18N a requirement. Text comparisons may be done as part of the GETMETADATA or LIST- EXTENDED commands. As a result, support for the COMPARATOR [I-D.ietf-imapext-i18n] extension is REQUIRED. GETMETADATA doesn't actually do text comparisons, right? The BNF doesn't seem to tie in the "matchtype" or "collation" productions. But more to the point, I believe that the intention was that METADATA should be a simple, baseline extenstion that will be required by a wide range of other extensions. If that's the case, *PLEASE* reconsider the wisdom of adding the LT, LE, GT, and GE matchers (and thus the COMPARATOR requirement) to this draft. It doesn't apear to be core functionality for METADATA, and since COMPARATOR appears nontrivial to implement this may not only prevent server authors from implementing METADATA but also keep us from impelenting any future extension that requires METADATA. A user can only set and retrieve private or shared annotations on a mailbox which exists and is returned to them via a LIST or LSUB command, irrespective of whether they have read or write access to the actual message content of the mailbox. If the client attempts to set or retrieve annotations on other mailboxes, the server MUST respond with a NO response. I can understand the logic behind requiring LIST/LSUB access for reading public mailbox annotations and for setting private annotations. But that seems to be a very low bar for setting public mailbox annotations. Adding a new ACL permission for setting annotations would make this extension more complex and would also introduce a dependency on the ACL extension, but perhaps requiring [READ-WRITE] access to the mailbox might be reasonable? The new SETMETADATA command and the METADATA response each have a mailbox name argument, indicating that the annotations being referred to are attached to the specified mailbox. An empty string can be used for the mailbox name to signify server annotations. What rights are required to set public and private annotations on the server? This command sets the specified list of entries by adding or replacing the specified attributes with the values provided, on the specified existing mailboxes. Clients can use NIL for values of attributes it wants to remove from entries. The server MAY return a METADATA response containing the updated annotation data. In this case, the server may return a METADATA response that doesn't contain the updated annotation data or a LIST response that does, correct? This extension adds the GETMETADATA command. This allows clients to retrieve server annotations. Mailbox annotations are retrieved via the extended LIST command described in the next section. This extension adds the SETMETADATA command. This allows clients to set annotations. It's a little incongruous that GETMETADATA is used only to retrieve server annotations, but SETMETADATA can be used to set both server and mailbox annotations. I understand that the mailbox-level function of GETMETADATA has been passed to the LIST-EXTENDED feature, but generally it's clearer when a GETFOO and SETFOO pair cover the same target space. If the METADATA extension is present, support for shared annotations is REQUIRED, whilst support for private annotations is OPTIONAL. This recognizes the fact that support for private annotations may introduce significantly more complexity to a server in terms of tracking ownership of the annotations, how quota is determined for users based on their own annotations etc. Clients that support the METADATA extension MUST handle both shared and private annotations. Is there a mechanism for informing clients that a server does not support private annotations? Or is a client expected to determine this from METADATA NOPRIVATE response codes on a SETMETADATA NO response? If the latter is the case, won't client implementations end up allowing users one attempt to set private annotations and only then inform them that the functionality is not supported by the server? (This would probably occur once per IMAP session...) If the server is unable to set an annotation because the size of its value is too large, the server MUST return a tagged NO response with a "[METADATA TOOBIG]" response code. Likewise, is there a mechanism for a server to tell its clients the maximum annotation length it supports? Or is it up to the client to determine this from METADATA TOOBIG error code responses? Entry and attribute names are case-sensitive. Entry and attribute names MUST NOT contain asterisk ("*") or percent ("%") characters and MUST NOT contain non-ASCII characters or the NUL octet. Invalid entry or attribute names result in a BAD response in any IMAP commands where they are used. Use of control or punctuation characters in entry and attribute names is strongly discouraged. It's probably cleaner in the long run to use the BNF to explicitly specify a limited set of permitted characters for entry and attribute names. Constraining them to something like "atom" plus the delimiters is probably not a bad idea. Given that these names are already constrained to ASCII, I'd favor eliminating the case-sensitivity requirement. It differs from other IMAP commands and extensions' general consistent overall case- insensitivity (e.g. RFC 3501 keywords). value A string or binary data representing the value of the annotation. To delete an annotation, the client can store "NIL" into the value. The content represented by the string is determined by the Content-Type used to register the entry (see Section 6.1 for entry registration templates). Where applicable, the registered Content-Type MUST include a charset parameter. Text values SHOULD use the utf-8 [RFC3629] character set. Is there any reason not to mandate UTF-8 for text values? We seem to be moving towards standardizing on UTF-8 in IMAP, and this seems a good opportunity to draw a line. /sort Defines the default sort criteria [I-D.ietf-imapext-sort] to use when first displaying the mailbox contents to the user, or NIL if sorting is not required. Note that the presence of this attribute does not imply that the server supports the IMAP SORT [I-D.ietf-imapext-sort] extension - servers can choose to support or not support SORT independently of this extension. In the absence of the SORT extension, clients can choose to interpret this entry as suggesting a client-side sort ordering of the corresponding mailbox. /thread Defines the default thread criteria [I-D.ietf-imapext-sort] to use when first displaying the mailbox contents to the user, or NIL if threading is not required. If both sort and thread are not NIL, then threading should take precedence over sorting. Note that the presence of this attribute does not imply that the server supports the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can choose to support or not support THREAD independently of this extension. In the absence of the THREAD extension, clients can choose to interpret this entry as a client-side thread ordering of the corresponding mailbox. These registered annotations are odd ducks. They seem most appropriate as private annotations on a mailbox, but in practice they may be confusing to the end user because sorting and threading preferences are often client-specific, not user-specific. For instance, a user may prefer to read their mail nonthreaded on the desktop, but on a mobile device they may want to make use of the reduced visual footprint of a threaded display. Likewise, more likely than not a user won't expect their sort preferences to automatically be transferred between their devices and clients. Mailboxes or the server as a whole may have zero or more annotations associated with them. An annotation contains a uniquely named entry with a set of uniquely named attributes, each of which has a value. Annotations can be added to mailboxes when a mailbox name is provided as the first argument to the new command, or to the server as a whole when the empty string is provided as the first argument to the new command. Just a nitpick here, but you should probably refer to SETMETADATA command by name since (a) it hasn't been introduced at this point in the document and (b) there is more than one new command added by the draft. Each annotation is an entry that has a hierarchical name, with each component of the name separated by a slash ("/"). An entry name MUST NOT contain two consecutive "/" characters and MUST NOT end with a "/" character. Each entry is made up of a set of attributes. Each attribute has a hierarchical name, with each component of the name separated by a period ("."). An attribute name MUST NOT contain two consecutive "." characters and MUST NOT end with a "." character. My last comment is personal preference: I fear that this may be a bit of overkill for folder annotation. I understand the need for this type of flexible syntax for ACAP's purposes, but the use cases for IMAP appear significantly more limited in scope. In accordance with the KISS philosophy, is there any chance I might be able to convince everyone to consider shedding a layer of hierarchy here? _______________________________________________ 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 Apr 03 07:05:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgpC-0001vP-1D; Tue, 03 Apr 2007 07:05:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgpB-0001vK-4y for lemonade@ietf.org; Tue, 03 Apr 2007 07:05:17 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgp6-0000lb-By for lemonade@ietf.org; Tue, 03 Apr 2007 07:05:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 9001449800E for ; Tue, 3 Apr 2007 12:05:11 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01345-07 for ; Tue, 3 Apr 2007 12:05:09 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 58A0E49800D for ; Tue, 3 Apr 2007 12:05:09 +0100 (BST) MIME-Version: 1.0 Message-Id: <5933.1175598309.377419@peirce.dave.cridland.net> Date: Tue, 03 Apr 2007 12:05:09 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [lemonade] Profile Bis updated 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 I've just submitted a fairly major update to the Profile document. This update is quite intensive, and in particular, I've: - Changed the references, so we now use named symbolic references. Hopefully this makes it easier to read the document. I've chosen to prepend the protocol name for the extension, which has the neat effect that all the SMTP extensions are listed together in the references. - I've cleaned up the references, and ended up writing some support tools to help me minimize the number of Normative references. - I've reorganized the document quite heavily. We now have the summary tables coming first, and the detailed normative sections next, and finally the informative sections. - I've done some quick editing work too, to try and make the detailed normative sections read a little more fluidly, and try to get some consistency in our naming. In particular, the document now talks about "Lemonade Message Stores" and "Lemonade Submission Servers", the intention being that, for example, Cyrus IMAP can call itself a "Lemonade Message Store" (whereas it's not a Lemonade Mail Server, which has to provide both components). This all means that looking at a diff is not going to help reviewers, and people are advised to simply read through the entire document again. Things I've not done yet: 1) I have "Allow Partial URLs in CATENATE and URLAUTH" - are we going to require a capability tag to indicate this? 2) ENABLE - I've got ENABLE listed as something we'll need to be requiring, because it's needed for something else - but I cannot see what that something else is. 3) Section 8, the OMA MEM detail, is bothering me. In some private discussions, the opinion seemed to be to drop it entirely - I'm happy to keep it, but I'd rather trim it to it merely provides sufficient background that an OMA MEM member could use it to "bootstrap" themselves into understanding the Lemonade architecture. I'm not clear on what's required, so please advise, OMA-people. 4) I've probably not addressed all comments - if you find I have not, please send them to the list again. I'd greatly appreciate some detailed reviews at this point, I'm intending to produce another revision as soon as I have a couple of reviews back. Until it appears in the repository, you can find it at: http://dave.cridland.net/draft-ietf-lemonade-profile-bis-05.txt (For those working on other drafts in xml2rfc format, I now have a set of tools written in XSLT for preprocessing, reference checking, etc, if anyone is interested.) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Tue Apr 03 07:18:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYh27-00053w-Sd; Tue, 03 Apr 2007 07:18:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYh26-000539-KQ for lemonade@ietf.org; Tue, 03 Apr 2007 07:18:38 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYh25-0007BC-63 for lemonade@ietf.org; Tue, 03 Apr 2007 07:18:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id A575349800E; Tue, 3 Apr 2007 12:18:33 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01655-03; Tue, 3 Apr 2007 12:18:32 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 0B54149800D; Tue, 3 Apr 2007 12:18:32 +0100 (BST) Subject: Re: [lemonade] WGLC streaming References: <4608EF81.5050401@isode.com> <6000.1175008017.686117@peirce.dave.cridland.net> <35A5A4A1-D3ED-41EE-A521-1C3C95AA885A@noware.co.uk> <460E99FA.6030307@isode.com> In-Reply-To: <460E99FA.6030307@isode.com> MIME-Version: 1.0 Message-Id: <5933.1175599112.024523@peirce.dave.cridland.net> Date: Tue, 03 Apr 2007 12:18:32 +0100 From: Dave Cridland To: Alexey Melnikov Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Enhancements to Internet email to support diverse service enivronments 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 Sat Mar 31 18:27:22 2007, Alexey Melnikov wrote: > You might be surprised :-). IMHO, implementors usually use examples > from RFCs to write their clients. (Except for Dave, of course ;-)) I certainly use the examples more than the text for figuring out the overall concepts. When I read the example with the BODY[1.2.MIME] fetch, I spent a long time reading through the text trying to figure out what the client needed that wasn't in BODYSTRUCTURE, assuming there must have been something forcing the MIME header fetch. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Apr 04 07:55: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 1HZ452-0004CU-5l; Wed, 04 Apr 2007 07:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ451-0004CM-BO for lemonade@ietf.org; Wed, 04 Apr 2007 07:55:11 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ450-0005Z4-1j for lemonade@ietf.org; Wed, 04 Apr 2007 07:55:11 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57692) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1HZ44L-00067f-VQ (Exim 4.63) for lemonade@ietf.org (return-path ); Wed, 04 Apr 2007 12:54:29 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HZ44J-0004Om-H6 (Exim 4.54) for lemonade@ietf.org (return-path ); Wed, 04 Apr 2007 12:54:27 +0100 Date: Wed, 4 Apr 2007 12:54:27 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: lemonade@ietf.org Subject: Re: [lemonade] draft-fanf-smtp-quickstart-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 Now available at http://www.ietf.org/internet-drafts/draft-fanf-smtp-quickstart-00.txt Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: VARIABLE 3, BECOMING NORTHWEST 4 OCCASIONALLY 5. SLIGHT. FAIR. MAINLY GOOD. _______________________________________________ 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 Apr 04 08:25:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4YE-0004Ab-HC; Wed, 04 Apr 2007 08:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4YD-00046j-PM for lemonade@ietf.org; Wed, 04 Apr 2007 08:25:21 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4YC-0007Uk-8i for lemonade@ietf.org; Wed, 04 Apr 2007 08:25:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E7E82498010 for ; Wed, 4 Apr 2007 13:25:12 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18281-10 for ; Wed, 4 Apr 2007 13:25:06 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 1714549800E for ; Wed, 4 Apr 2007 13:25:06 +0100 (BST) Subject: Re: [lemonade] draft-fanf-smtp-quickstart-00 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <15499.1175689506.080017@peirce.dave.cridland.net> Date: Wed, 04 Apr 2007 13:25:06 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Wed Apr 4 12:54:27 2007, Tony Finch wrote: > Now available at > > http://www.ietf.org/internet-drafts/draft-fanf-smtp-quickstart-00.txt I spotted this, and added the reference to my working copy of the profile bis draft - also updated the RFC2554 reference to draft-siemborski-rfc2554bis. (This is at http://svn.dave.cridland.net/svn/ietf-drafts/draft-ietf-lemonade-profile-bis.xml and is in something quite close to xml2rfc format, although I use some preprocessor tools for references). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Apr 04 08:35:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4hc-00020X-RY; Wed, 04 Apr 2007 08:35:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4ha-0001y1-G4 for lemonade@ietf.org; Wed, 04 Apr 2007 08:35:02 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4gP-0000fg-Pn for lemonade@ietf.org; Wed, 04 Apr 2007 08:33:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 2CC09498010 for ; Wed, 4 Apr 2007 13:33:49 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18862-06 for ; Wed, 4 Apr 2007 13:33:48 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 457CD49800E for ; Wed, 4 Apr 2007 13:33:48 +0100 (BST) MIME-Version: 1.0 Message-Id: <15499.1175690028.254804@peirce.dave.cridland.net> Date: Wed, 04 Apr 2007 13:33:48 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.5 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [lemonade] IMAP SASL-IR 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 Just realized that this is neither in the slides from Prague, nor in Profile Bis. Do we want the IMAP SASL-IR extension? Saves us a round-trip on authentication, and it's quite commonly implemented in servers anyway, as well as being an active draft once more. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Apr 04 09:43: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 1HZ5lX-0001sR-CM; Wed, 04 Apr 2007 09:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ5lW-0001sK-Ax for lemonade@ietf.org; Wed, 04 Apr 2007 09:43:10 -0400 Received: from klee.esys.ca ([198.161.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ5lT-0004j6-UN for lemonade@ietf.org; Wed, 04 Apr 2007 09:43:10 -0400 Received: from [198.161.92.72] (galileo.esys.ca [198.161.92.72]) by klee.esys.ca via TCP (smtp internal) with ESMTPA; Wed, 4 Apr 2007 07:42:38 -0600 Message-ID: <4613AB5E.9010007@messagingdirect.com> Date: Wed, 04 Apr 2007 07:42:54 -0600 From: Steve Hole User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Tony Finch Subject: Re: [lemonade] draft-fanf-smtp-quickstart-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: lemonade@ietf.org 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 Tony Finch wrote: > Now available at > > http://www.ietf.org/internet-drafts/draft-fanf-smtp-quickstart-00.txt > > Tony. > Out of curiosity ... why don't you extend the EHLO command directly to initiate the AUTH or STARTLS sequence rather than provide the extended QHLO and QTLS commands? You're not waiting for any responses from the SMTP server anyway, so you might as well throw it all over the fence at the beginning. Success or failure of the submit transaction is bounded by the entire sequence of SMTP commands in the model. Cheers. -- Steve Hole Chief Technical Officer PlaNet Correspondence Technologies 424-4922 (wk) 905-9116 (mb) mailto:shole@planetct.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 Wed Apr 04 10:13: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 1HZ6Ef-0001BC-TC; Wed, 04 Apr 2007 10:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6Ee-0001Ax-HT for lemonade@ietf.org; Wed, 04 Apr 2007 10:13:16 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6Ec-0007Mr-8Q for lemonade@ietf.org; Wed, 04 Apr 2007 10:13:16 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:34353) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1HZ6Dz-00032T-PC (Exim 4.63) (return-path ); Wed, 04 Apr 2007 15:12:35 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HZ6Dz-0002lT-M9 (Exim 4.54) (return-path ); Wed, 04 Apr 2007 15:12:35 +0100 Date: Wed, 4 Apr 2007 15:12:35 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Steve Hole Subject: Re: [lemonade] draft-fanf-smtp-quickstart-00 In-Reply-To: <4613AB5E.9010007@messagingdirect.com> Message-ID: References: <4613AB5E.9010007@messagingdirect.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org 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 Wed, 4 Apr 2007, Steve Hole wrote: > Out of curiosity ... why don't you extend the EHLO command directly to > initiate the AUTH or STARTLS sequence rather than provide the extended > QHLO and QTLS commands? Because the SMTP extension framework only allows extension parameters on the MAIL and RCPT commands. If you want to change other aspects of SMTP you have to introduce new verbs. Tony. -- f.a.n.finch http://dotat.at/ FAEROES SOUTHEAST ICELAND: WEST 6 OR 7, OCCASIONALLY GALE 8, VEERING NORTHEAST 4 OR 5. ROUGH OR VERY ROUGH. RAIN OR DRIZZLE, THEN WINTRY SHOWERS. GOOD, OCCASIONALLY MODERATE OR POOR. _______________________________________________ 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 Apr 04 10:24:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6PY-0001H6-HA; Wed, 04 Apr 2007 10:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6PX-0001Gv-KD for lemonade@ietf.org; Wed, 04 Apr 2007 10:24:31 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6PT-0005N1-7N for lemonade@ietf.org; Wed, 04 Apr 2007 10:24:31 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l34ENrBQ011991; Wed, 4 Apr 2007 09:24:24 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 09:24:20 -0500 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] draft-fanf-smtp-quickstart-00 Date: Wed, 4 Apr 2007 09:23:43 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19988D3B@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] draft-fanf-smtp-quickstart-00 thread-index: Acd2w3X45l9Ls+hQQbakHA6bZ8ccvwAAPD4A From: "Vaudreuil, Greg M \(Greg\)" To: "Tony Finch" X-OriginalArrivalTime: 04 Apr 2007 14:24:20.0397 (UTC) FILETIME=[EF4F55D0:01C776C4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: lemonade@ietf.org 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 SMTP extension framework is really the EHLO framework. It is certianly possible to provide an alternate framework based on another HELO variant if there is compelling need. =20 Greg V. -----Original Message----- From: Tony Finch [mailto:dot@dotat.at] Sent: Wednesday, April 04, 2007 10:13 AM To: Steve Hole Cc: lemonade@ietf.org Subject: Re: [lemonade] draft-fanf-smtp-quickstart-00 On Wed, 4 Apr 2007, Steve Hole wrote: > Out of curiosity ... why don't you extend the EHLO command directly to > initiate the AUTH or STARTLS sequence rather than provide the extended > QHLO and QTLS commands? Because the SMTP extension framework only allows extension parameters on the MAIL and RCPT commands. If you want to change other aspects of SMTP you have to introduce new verbs. Tony. --=20 f.a.n.finch http://dotat.at/ FAEROES SOUTHEAST ICELAND: WEST 6 OR 7, OCCASIONALLY GALE 8, VEERING NORTHEAST 4 OR 5. ROUGH OR VERY ROUGH. RAIN OR DRIZZLE, THEN WINTRY SHOWERS. GOOD, OCCASIONALLY MODERATE OR POOR. _______________________________________________ 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 Apr 04 10:57: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 1HZ6vc-0008WK-SF; Wed, 04 Apr 2007 10:57:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6uj-0007qU-He for lemonade@ietf.org; Wed, 04 Apr 2007 10:56:45 -0400 Received: from klee.esys.ca ([198.161.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6pY-000057-Hl for lemonade@ietf.org; Wed, 04 Apr 2007 10:51:26 -0400 Received: from [198.161.92.72] (galileo.esys.ca [198.161.92.72]) by klee.esys.ca via TCP (smtp internal) with ESMTPA; Wed, 4 Apr 2007 08:50:48 -0600 Message-ID: <4613BB59.4050901@messagingdirect.com> Date: Wed, 04 Apr 2007 08:51:05 -0600 From: Steve Hole User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" Subject: Re: [lemonade] draft-fanf-smtp-quickstart-00 References: <89017B166CB7E140BA80577FF744AE19988D3B@ILEXC2U01.ndc.lucent.com> In-Reply-To: <89017B166CB7E140BA80577FF744AE19988D3B@ILEXC2U01.ndc.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Tony Finch , lemonade@ietf.org 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 Vaudreuil, Greg M (Greg) wrote: > The SMTP extension framework is really the EHLO framework. It is > certianly possible to provide an alternate framework based on another > HELO variant if there is compelling need. > Precisely -- vis-a-vis the LHLO command of LMTP (LMTP is really just a profile of SMTP). I'm thinking that you would like to doing something similar to the LMTP thing here. Really I don't care all the much in the end -- I was thinking mostly about the state handling issues in the SMTP server implementation. Adding an additional command into the state sequence is likely to be more complex to implement that providing the additional handling of the extension parameters in the EHLO variant (presumably QHLO). That is, the support for HELO, EHLO, LHLO in many servers is handled by the same state processing, with variant behavior depending on the actual protocol verb and subsequent arguments. At any rate, it is just a thought. I'll shut up now. Cheers. -- Steve Hole Chief Technical Officer PlaNet Correspondence Technologies 424-4922 (wk) 905-9116 (mb) mailto:shole@planetct.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 Wed Apr 04 11:21:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7IH-0001w0-DQ; Wed, 04 Apr 2007 11:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7IG-0001vv-PU for lemonade@ietf.org; Wed, 04 Apr 2007 11:21:04 -0400 Received: from ppsw-3.csi.cam.ac.uk ([131.111.8.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7I8-0001DT-Vh for lemonade@ietf.org; Wed, 04 Apr 2007 11:21:04 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51243) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:25) with esmtpa (EXTERNAL:fanf2) id 1HZ7Ha-000780-CI (Exim 4.63) for lemonade@ietf.org (return-path ); Wed, 04 Apr 2007 16:20:23 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HZ7Ha-0001R7-Mm (Exim 4.54) for lemonade@ietf.org (return-path ); Wed, 04 Apr 2007 16:20:22 +0100 Date: Wed, 4 Apr 2007 16:20:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: lemonade@ietf.org Subject: RE: [lemonade] draft-fanf-smtp-quickstart-00 In-Reply-To: <89017B166CB7E140BA80577FF744AE19988D3B@ILEXC2U01.ndc.lucent.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19988D3B@ILEXC2U01.ndc.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Wed, 4 Apr 2007, Vaudreuil, Greg M (Greg) wrote: > > The SMTP extension framework is really the EHLO framework. It is > certianly possible to provide an alternate framework based on another > HELO variant if there is compelling need. Actually I suppose quickstart does vary the framework a bit, but it tries to do so in a minimal way. It doesn't change the syntax or semantics of existing commands, only their pipelining behaviour. It does just enough to let us "throw it all over the fence at the beginning." The point of QHLO is for the client to say "I've seen your capability list, so you don't need to repeat it" which (as well as RTT elimination) saves a few bytes compared to EHLO before compression is negotiated. The point of QTLS is to let the client say "no chit-chat, let's encrypt" so it's effectively a streamlined combination of EHLO and STARTTLS. (I've made the examples clearer about this in the -01 revision of the draft.) This seems to be pretty much exactly what Steve is asking for - apart from AUTH, but I don't want to have to specify a whole new SASL profile, which is what an AUTH replacement would require. LMTP is a poor example, because if it actually followed the SMTP extension framework then it would be signalled using an ESMTP parameter on the MAIL command. A replacement for EHLO is unnecessary since it doesn't need to change the protocol's startup sequence. Tony. -- f.a.n.finch http://dotat.at/ SOLE LUNDY FASTNET: NORTHEAST 3 OR 4, OCCASIONALLY 5 AT FIRST. SLIGHT, OCCASIONALLY MODERATE IN SOLE AND FASTNET. FAIR. MAINLY GOOD. _______________________________________________ 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 Apr 04 15:51:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBVw-0005uu-Ad; Wed, 04 Apr 2007 15:51:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBV9-0004j2-Rt; Wed, 04 Apr 2007 15:50:40 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZBV9-0000qF-D8; Wed, 04 Apr 2007 15:50:39 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A620C2ACAC; Wed, 4 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZBUY-0001gn-Dx; Wed, 04 Apr 2007 15:50:02 -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: Wed, 04 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-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 --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 : The Lemonade Profile Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-profile-bis-05.txt Pages : 39 Date : 2007-4-4 This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-05.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-profile-bis-05.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-profile-bis-05.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-4-4135039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-profile-bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-profile-bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-4135039.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 Apr 05 15:50: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 1HZXyY-0002ij-84; Thu, 05 Apr 2007 15:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXyU-0002hq-Fn; Thu, 05 Apr 2007 15:50:26 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZXyK-0004dH-AL; Thu, 05 Apr 2007 15:50:26 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5F48E26F47; Thu, 5 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZXy6-00045k-8I; Thu, 05 Apr 2007 15:50:02 -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: Thu, 05 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-04.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 : Lemonade Notifications and Filters Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-notifications-04.txt Pages : 28 Date : 2007-4-5 This document discusses how to provide notification and filtering mechanisms to IMAP as part the Lemonade profile. This document also discusses the use of Lemonade notifications to implement server to server notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-04.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-notifications-04.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-notifications-04.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-4-5134018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-notifications-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-notifications-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-5134018.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 Sat Apr 07 04:53:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha6fF-0004Gs-Uf; Sat, 07 Apr 2007 04:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha6fF-0004Gn-7c for lemonade@ietf.org; Sat, 07 Apr 2007 04:52:53 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha6fD-0000wV-P5 for lemonade@ietf.org; Sat, 07 Apr 2007 04:52:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 0E45B498003 for ; Sat, 7 Apr 2007 09:52:51 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29214-08 for ; Sat, 7 Apr 2007 09:52:47 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 2D8F7498002 for ; Sat, 7 Apr 2007 09:52:47 +0100 (BST) Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-05.txt References: In-Reply-To: MIME-Version: 1.0 Message-Id: <24445.1175935967.183759@peirce.dave.cridland.net> Date: Sat, 07 Apr 2007 09:52:47 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Wed Apr 4 20:50:02 2007, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. Just to remind people I'd really like some reviews here. Please remember that the draft has changed radically since -04, and any changes I've arbitrarily made - such as mandatory support of ACAP - will survive into publication as an RFC unless people speak up. And remember, an RFC is for life, not just for Easter. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Sat Apr 07 05:38: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 1Ha7NX-0005Bl-U9; Sat, 07 Apr 2007 05:38:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha7NX-0005Bd-6J for lemonade@ietf.org; Sat, 07 Apr 2007 05:38:39 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha7NU-0003JD-Oz for lemonade@ietf.org; Sat, 07 Apr 2007 05:38:39 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 74A594AC2B; Sat, 7 Apr 2007 11:38:23 +0200 (CEST) Message-Id: Date: Sat, 7 Apr 2007 11:36:54 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-05.txt References: <24445.1175935967.183759@peirce.dave.cridland.net> In-Reply-To: <24445.1175935967.183759@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Dave Cridland writes: > On Wed Apr 4 20:50:02 2007, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. > > Just to remind people I'd really like some reviews here. > > Please remember that the draft has changed radically since -04, and > any changes I've arbitrarily made - such as mandatory support of ACAP > - will survive into publication as an RFC unless people speak up. I think you could simplify section 4.2 by also using the "ASN.1 in XML" RFCs-to-be. They're in the editor's queue, so adding a dependency on them won't slow down lemonade. Seriously, I'll review the document immediately after easter. 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 Sun Apr 08 16:12: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 1Hadk5-0001Gy-7o; Sun, 08 Apr 2007 16:12:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hadk3-0001Gd-B7 for lemonade@ietf.org; Sun, 08 Apr 2007 16:12:03 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hadk2-0003a5-2H for lemonade@ietf.org; Sun, 08 Apr 2007 16:12:03 -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 ; Sun, 8 Apr 2007 21:12:00 +0100 Message-ID: <46161C79.9070706@isode.com> Date: Fri, 06 Apr 2007 11:10:01 +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 MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] IMAP SASL-IR References: <15499.1175690028.254804@peirce.dave.cridland.net> In-Reply-To: <15499.1175690028.254804@peirce.dave.cridland.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Enhancements to Internet email to support diverse service enivronments 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 Dave Cridland wrote: > Just realized that this is neither in the slides from Prague, nor in > Profile Bis. Ah, an omission on my part. > Do we want the IMAP SASL-IR extension? Saves us a round-trip on > authentication, and it's quite commonly implemented in servers anyway, > as well as being an active draft once more. I always assumed that it would be in the Lemonade Profile Bis. Considering that the SASL-IR is past IETF LC, it should not delay the Profile Bis 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 Sun Apr 08 16:12: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 1HadkA-0001WF-Dq; Sun, 08 Apr 2007 16:12:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hadk8-0001Kj-Dz for lemonade@ietf.org; Sun, 08 Apr 2007 16:12:08 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hadk6-0003aA-SD for lemonade@ietf.org; Sun, 08 Apr 2007 16:12:08 -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 ; Sun, 8 Apr 2007 21:12:05 +0100 Message-ID: <4616327C.5040203@isode.com> Date: Fri, 06 Apr 2007 12:43:56 +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 MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] Profile Bis updated References: <5933.1175598309.377419@peirce.dave.cridland.net> In-Reply-To: <5933.1175598309.377419@peirce.dave.cridland.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Enhancements to Internet email to support diverse service enivronments 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 Dave Cridland wrote: > Things I've not done yet: > > 1) I have "Allow Partial URLs in CATENATE and URLAUTH" - are we going > to require a capability tag to indicate this? Yes, we should, as the client would otherwise have to way of knowing (it will have to try and see if partial URLs work). Should we just do this in the Lemonade Profile Bis itself? > 2) ENABLE - I've got ENABLE listed as something we'll need to be > requiring, because it's needed for something else - but I cannot see > what that something else is. If I remember correctly, ENABLE was born around EXPUNGED/QRESYNC WGLC. In particular there was a suggestion to use ENABLE with CONDSTORE and QRESYNC. Is this something that people still would like to be able to do in Lemonade Profile Bis? _______________________________________________ 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 Sun Apr 08 18:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HafZC-0001WT-Am; Sun, 08 Apr 2007 18:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HafZB-0001WM-Bh for lemonade@ietf.org; Sun, 08 Apr 2007 18:08:57 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HafZ9-0006Fx-VX for lemonade@ietf.org; Sun, 08 Apr 2007 18:08:57 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A3FCF4AC22; Mon, 9 Apr 2007 00:08:52 +0200 (CEST) Message-Id: <3OEALSStqC8uAUk5cthVOg.md5@libertango.oryx.com> Date: Mon, 9 Apr 2007 00:07:31 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] IMAP SASL-IR References: <15499.1175690028.254804@peirce.dave.cridland.net> <46161C79.9070706@isode.com> In-Reply-To: <46161C79.9070706@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 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 Alexey Melnikov writes: > Dave Cridland wrote: >> Do we want the IMAP SASL-IR extension? Saves us a round-trip on >> authentication, and it's quite commonly implemented in servers >> anyway, as well as being an active draft once more. > > I always assumed that it would be in the Lemonade Profile Bis. > Considering that the SASL-IR is past IETF LC, it should not delay the > Profile Bis document. FYI, it's on the agenda for the upcoming IESG meeting. 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 Sun Apr 08 18:58:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HagLF-0003NH-Ky; Sun, 08 Apr 2007 18:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HagLD-0003N3-Pq for lemonade@ietf.org; Sun, 08 Apr 2007 18:58:35 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HagLC-0004Dj-83; Sun, 08 Apr 2007 18:58:35 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l38MwSXe027513; Sun, 8 Apr 2007 15:58:28 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l38MwP7J027313; Sun, 8 Apr 2007 15:58:26 -0700 Received: from 172.24.28.78 ([172.24.28.78]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 8 Apr 2007 22:58:28 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 08 Apr 2007 17:15:28 -0400 From: Eric Burger To: "lemonade@ietf.org" , Message-ID: Thread-Topic: Deprecate IMAP IDLE? Thread-Index: Acd6Iwf/RpwX/uYWEdurjAAWy4mm/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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [lemonade] Deprecate IMAP IDLE? 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 In Prague, it was brought up that (1) some people consider IMAP IDLE to be an ugly wart on IMAP, (2) the point of IMAP IDLE is for "in-band" notifications, and (3) the IMAP NOTIFY method is a clean way of doing "in-band" notifications. Because of this, it was proposed that IMAP NOTIFY would supercede IMAP IDLE, leading to its deprecation. What do we think of this? As chair, my only care is whether we say it obsoletes RFC 2177 or not. I personally do not care if it obsoletes IDLE or not. 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 Sun Apr 08 19:08:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HagUv-0008IX-0I; Sun, 08 Apr 2007 19:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HagUt-0008IS-VC for lemonade@ietf.org; Sun, 08 Apr 2007 19:08:35 -0400 Received: from smtp01.bis.na.blackberry.com ([216.9.248.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HagUs-00064I-Mr; Sun, 08 Apr 2007 19:08:35 -0400 Message-ID: <342181038-1176073709-cardhu_blackberry.rim.net-187002956-@bwe059-cell00.bisx.prod.on.blackberry> References: In-Reply-To: Sensitivity: Normal Importance: Normal To: "Eric Burger" , "lemonade@ietf.org" , imap-ext@ietf.org Subject: Re: [lemonade] Deprecate IMAP IDLE? From: "=?UTF-8?B?U3RlcGhhbmUgSC4gTWFlcw==?=" Date: Sun, 8 Apr 2007 23:07:59 +0000 MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stephane.maes@oracle.com List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122890792==" Errors-To: lemonade-bounces@ietf.org --===============2122890792== Content-Transfer-Encoding: base64 Content-type: text/plain SSBsaWtlIGl0IGEgbG90IQ0KDQpTdGVwaGFuZQ0KX19fX18NClN0ZXBoYW5lIEguIE1hZXMsIFBo RCwNCkRpcmVjdG9yIG9mIEFyY2hpdGVjdHVyZSwgTW9iaWxlLCBWb2ljZSwgYW5kIENvbW11bmlj YXRpb25zIFBsYXRmb3JtcywgT3JhY2xlDQpQaDogKzEtMjAzLTMwMC03Nzg2IChtb2JpbGUvU01T L3NreXBlKTsgRmF4IC8gT2ZmaWNlIFVNOiArMS02NTAtNjA3LTYyOTYuDQplLW1haWw6IHN0ZXBo YW5lLm1hZXNAb3JhY2xlLmNvbQ0KSU06IHNobWFlcyAoQUlNL1khKSBvciBzdGVwaGFuZV9tYWVz QGhvdG1haWwuY29tIChNU04gTWVzc2VuZ2VyKSBvciBzdGVwaGFuZS5tYWVzQGdtYWlsLmNvbSAo R29vZ2xlKSAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmljIEJ1cmdl ciA8ZWJ1cmdlckBiZWEuY29tPg0KRGF0ZTogU3VuLCAwOCBBcHIgMjAwNyAxNzoxNToyOCANClRv OiJsZW1vbmFkZUBpZXRmLm9yZyIgPGxlbW9uYWRlQGlldGYub3JnPiwgPGltYXAtZXh0QGlldGYu b3JnPg0KU3ViamVjdDogW2xlbW9uYWRlXSBEZXByZWNhdGUgSU1BUCBJRExFPw0KDQpJbiBQcmFn dWUsIGl0IHdhcyBicm91Z2h0IHVwIHRoYXQgKDEpIHNvbWUgcGVvcGxlIGNvbnNpZGVyIElNQVAg SURMRSB0byBiZQ0KYW4gdWdseSB3YXJ0IG9uIElNQVAsICgyKSB0aGUgcG9pbnQgb2YgSU1BUCBJ RExFIGlzIGZvciAiaW4tYmFuZCINCm5vdGlmaWNhdGlvbnMsIGFuZCAoMykgdGhlIElNQVAgTk9U SUZZIG1ldGhvZCBpcyBhIGNsZWFuIHdheSBvZiBkb2luZw0KImluLWJhbmQiIG5vdGlmaWNhdGlv bnMuDQoNCkJlY2F1c2Ugb2YgdGhpcywgaXQgd2FzIHByb3Bvc2VkIHRoYXQgSU1BUCBOT1RJRlkg d291bGQgc3VwZXJjZWRlIElNQVAgSURMRSwNCmxlYWRpbmcgdG8gaXRzIGRlcHJlY2F0aW9uLg0K DQpXaGF0IGRvIHdlIHRoaW5rIG9mIHRoaXM/ICBBcyBjaGFpciwgbXkgb25seSBjYXJlIGlzIHdo ZXRoZXIgd2Ugc2F5IGl0DQpvYnNvbGV0ZXMgUkZDIDIxNzcgb3Igbm90LiAgSSBwZXJzb25hbGx5 IGRvIG5vdCBjYXJlIGlmIGl0IG9ic29sZXRlcyBJRExFIG9yDQpub3QuDQoNCg0KTm90aWNlOiAg VGhpcyBlbWFpbCBtZXNzYWdlLCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cywgbWF5IGNv bnRhaW4gaW5mb3JtYXRpb24gIG9mICBCRUEgU3lzdGVtcywgIEluYy4sICBpdHMgc3Vic2lkaWFy aWVzICBhbmQgIGFmZmlsaWF0ZWQgZW50aXRpZXMsICB0aGF0IG1heSBiZSBjb25maWRlbnRpYWws ICBwcm9wcmlldGFyeSwgIGNvcHlyaWdodGVkICBhbmQvb3IgbGVnYWxseSBwcml2aWxlZ2VkLCBh bmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSBuYW1lZCBpbiB0aGlzIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIGFuZCBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNl IGltbWVkaWF0ZWx5IHJldHVybiB0aGlzIGJ5IGVtYWlsIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxlbW9uYWRl IG1haWxpbmcgbGlzdA0KbGVtb25hZGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xlbW9uYWRlDQpTdXBwbGVtZW50YWwgV2ViIFNpdGU6DQpodHRwOi8v d3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlDQo= --===============2122890792== 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 --===============2122890792==-- From lemonade-bounces@ietf.org Sun Apr 08 19:42:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hah1o-0007pg-QA; Sun, 08 Apr 2007 19:42:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hah1n-0007pb-KF for lemonade@ietf.org; Sun, 08 Apr 2007 19:42:35 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hah1j-0004s8-7t; Sun, 08 Apr 2007 19:42:35 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l38NgMG7019994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Apr 2007 16:42:22 -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.03) with ESMTP id l38NgJ9S022843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Apr 2007 16:42:21 -0700 Date: Sun, 8 Apr 2007 16:42:18 -0700 (PDT) From: Mark Crispin To: Eric Burger Subject: Re: [lemonade] Deprecate IMAP IDLE? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.8.163334 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "lemonade@ietf.org" , imap-ext@ietf.org 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 Sun, 8 Apr 2007, Eric Burger wrote: > In Prague, it was brought up that (1) some people consider IMAP IDLE to be > an ugly wart on IMAP, (2) the point of IMAP IDLE is for "in-band" > notifications, and (3) the IMAP NOTIFY method is a clean way of doing > "in-band" notifications. All true, but... > Because of this, it was proposed that IMAP NOTIFY would supercede IMAP IDLE, > leading to its deprecation. > > What do we think of this? As chair, my only care is whether we say it > obsoletes RFC 2177 or not. I personally do not care if it obsoletes IDLE or > not. I strongly oppose this, even while I agree with the underlying sentiment. IMHO, it is out of charter for LEMONADE to deprecate IDLE, much less obsolete RFC 2177. IDLE is used by applications other than mobile devices. Deprecating IDLE may be in charter for IMAPEXT, but I doubt that at this late stage IMAPEXT will want to deal with it. I recommend that this is a sleeping dog that is best allowed to lie. As desirable as it may be, it is work for a future WG. -- 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 Mon Apr 09 02:51:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haniw-0003SA-6I; Mon, 09 Apr 2007 02:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haniv-0003S5-BM for lemonade@ietf.org; Mon, 09 Apr 2007 02:51:33 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hanir-0007kT-VD for lemonade@ietf.org; Mon, 09 Apr 2007 02:51:33 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BAE1C4AC22; Mon, 9 Apr 2007 08:51:30 +0200 (CEST) Message-Id: Date: Mon, 9 Apr 2007 08:50:10 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Deprecate IMAP IDLE? References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Eric Burger writes: > Because of this, it was proposed that IMAP NOTIFY would supercede IMAP > IDLE, leading to its deprecation. > > What do we think of this? As chair, my only care is whether we say it > obsoletes RFC 2177 or not. I think obsoleting 2177 is out of scope for Lemonade. All Lemonade can/should do is say things in profile-bis. 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 Tue Apr 10 07:11: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 1HbEGG-0006KA-Vv; Tue, 10 Apr 2007 07:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEGF-0006Jx-Fo for lemonade@ietf.org; Tue, 10 Apr 2007 07:11:43 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEGD-0007xz-1D for lemonade@ietf.org; Tue, 10 Apr 2007 07:11:43 -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, 10 Apr 2007 12:11:32 +0100 Message-ID: <461A8EFC.5050208@isode.com> Date: Mon, 09 Apr 2007 20:07:40 +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 MIME-Version: 1.0 To: Dan Karp , Cyrus Daboo Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: diverse service enivronments , Enhancements, IMAP Extensions WG 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 Dan Karp wrote: >>http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt >> >> >Comments interspersed btween snippets of the draft: > > Hi Dan, > Changes from -10 to -11: > 7. Added match type and collation identifier to the LIST-EXTENDED > selection option. > 8. Made support for IMAP-I18N a requirement. > > Text comparisons may be done as part of the GETMETADATA or LIST- > EXTENDED commands. As a result, support for the COMPARATOR > [I-D.ietf-imapext-i18n] extension is REQUIRED. > >GETMETADATA doesn't actually do text comparisons, right? The BNF >doesn't seem to tie in the "matchtype" or "collation" productions. > > Check the , it references both. >But more to the point, I believe that the intention was that METADATA >should be a simple, baseline extenstion that will be required by a wide >range of other extensions. If that's the case, *PLEASE* reconsider the >wisdom of adding the LT, LE, GT, and GE matchers (and thus the >COMPARATOR requirement) to this draft. It doesn't apear to be core >functionality for METADATA, and since COMPARATOR appears nontrivial to >implement > Can you please elaborate on this? (Note that the COMPARATOR extension is about to switch to i;unicode-casemap collation (as mandatory to implement), which is much easier to implement than i;basic) > this may not only prevent server authors from implementing >METADATA but also keep us from impelenting any future extension that >requires METADATA. > > > A user can only set and retrieve private or shared annotations on a > mailbox which exists and is returned to them via a LIST or LSUB > command, irrespective of whether they have read or write access to > the actual message content of the mailbox. If the client attempts to > set or retrieve annotations on other mailboxes, the server MUST > respond with a NO response. > >I can understand the logic behind requiring LIST/LSUB access for reading >public mailbox annotations and for setting private annotations. But >that seems to be a very low bar for setting public mailbox annotations. >Adding a new ACL permission for setting annotations would make this >extension more complex and would also introduce a dependency on the ACL >extension, > Dependency in what sense? > but perhaps requiring [READ-WRITE] access to the mailbox >might be reasonable? > > > The new SETMETADATA command and the METADATA response each have a > mailbox name argument, indicating that the annotations being referred > to are attached to the specified mailbox. An empty string can be > used for the mailbox name to signify server annotations. > >What rights are required to set public and private annotations on the >server? > > None. But maybe this should be stated explicitly. > This command sets the specified list of entries by adding or > replacing the specified attributes with the values provided, on the > specified existing mailboxes. Clients can use NIL for values of > attributes it wants to remove from entries. The server MAY return a > METADATA response containing the updated annotation data. > >In this case, the server may return a METADATA response that doesn't >contain the updated annotation data or a LIST response that does, >correct? > > > This extension adds the GETMETADATA command. This allows clients to > retrieve server annotations. Mailbox annotations are retrieved via > the extended LIST command described in the next section. > > This extension adds the SETMETADATA command. This allows clients to > set annotations. > >It's a little incongruous that GETMETADATA is used only to retrieve >server annotations, but SETMETADATA can be used to set both server and >mailbox annotations. I understand that the mailbox-level function of >GETMETADATA has been passed to the LIST-EXTENDED feature, but generally >it's clearer when a GETFOO and SETFOO pair cover the same target space. > > Yes, but the alternative is to have 2 ways of getting annotations, which is worse. > If the METADATA extension is present, support for shared annotations > is REQUIRED, whilst support for private annotations is OPTIONAL. > This recognizes the fact that support for private annotations may > introduce significantly more complexity to a server in terms of > tracking ownership of the annotations, how quota is determined for > users based on their own annotations etc. Clients that support the > METADATA extension MUST handle both shared and private annotations. > >Is there a mechanism for informing clients that a server does not >support private annotations? Or is a client expected to determine this >from METADATA NOPRIVATE response codes on a SETMETADATA NO response? > > Currently the latter. >If the latter is the case, won't client implementations end up allowing >users one attempt to set private annotations and only then inform them >that the functionality is not supported by the server? > Clients can try to workaround this by trying to set an annotation to a fake value. Yes, this doesn't look very nice, but works. Defining a new capability wouldn't work, because in general case NOPRIVATE can be namespace or even mailbox-specific. We can add a new \NoPrivate per mailbox attribute to return this in LIST? > (This would probably occur once per IMAP session...) > > > If the server is unable to set an annotation because the size of its > value is too large, the server MUST return a tagged NO response with > a "[METADATA TOOBIG]" response code. > >Likewise, is there a mechanism for a server to tell its clients the >maximum annotation length it supports? Or is it up to the client to >determine this from METADATA TOOBIG error code responses? > > The latter. Also note, that the server might return TOOBIG because it simply ran out of storage space, so advertising the maximum might not be that helpful to the client. > Entry and attribute names are case-sensitive. > > Entry and attribute names MUST NOT contain asterisk ("*") or percent > ("%") characters and MUST NOT contain non-ASCII characters or the NUL > octet. Invalid entry or attribute names result in a BAD response in > any IMAP commands where they are used. > > Use of control or punctuation characters in entry and attribute names > is strongly discouraged. > >It's probably cleaner in the long run to use the BNF to explicitly >specify a limited set of permitted characters for entry and attribute >names. Constraining them to something like "atom" plus the delimiters >is probably not a bad idea. > >Given that these names are already constrained to ASCII, > I don't think this is the case! Annotation names can contain UTF-8. > I'd favor eliminating the case-sensitivity requirement. It differs from other >IMAP commands and extensions' general consistent overall case- >insensitivity (e.g. RFC 3501 keywords). > > > value > A string or binary data representing the value of the annotation. > To delete an annotation, the client can store "NIL" into the > value. The content represented by the string is determined by the > Content-Type used to register the entry (see Section 6.1 for entry > registration templates). Where applicable, the registered > Content-Type MUST include a charset parameter. Text values SHOULD > use the utf-8 [RFC3629] character set. > >Is there any reason not to mandate UTF-8 for text values? > Values can also be binary and not every binary value is a valid UTF-8. > We seem to be >moving towards standardizing on UTF-8 in IMAP, and this seems a good >opportunity to draw a line. > > "Values for annotations published on Standard track MUST use charset=UTF-8"? This still allows vendors to do whatever they want with their private annotations. > /sort > Defines the default sort criteria [I-D.ietf-imapext-sort] to use > when first displaying the mailbox contents to the user, or NIL if > sorting is not required. Note that the presence of this attribute > does not imply that the server supports the IMAP SORT > [I-D.ietf-imapext-sort] extension - servers can choose to support > or not support SORT independently of this extension. In the > absence of the SORT extension, clients can choose to interpret > this entry as suggesting a client-side sort ordering of the > corresponding mailbox. > > /thread > Defines the default thread criteria [I-D.ietf-imapext-sort] to use > when first displaying the mailbox contents to the user, or NIL if > threading is not required. If both sort and thread are not NIL, > then threading should take precedence over sorting. Note that the > presence of this attribute does not imply that the server supports > the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can > choose to support or not support THREAD independently of this > extension. In the absence of the THREAD extension, clients can > choose to interpret this entry as a client-side thread ordering of > the corresponding mailbox. > >These registered annotations are odd ducks. They seem most appropriate >as private annotations on a mailbox, but in practice they may be >confusing to the end user because sorting and threading preferences are >often client-specific, not user-specific. > >For instance, a user may prefer to read their mail nonthreaded on the >desktop, but on a mobile device they may want to make use of the reduced >visual footprint of a threaded display. Likewise, more likely than not >a user won't expect their sort preferences to automatically be >transferred between their devices and clients. > > I would let other people comment on this. > Mailboxes or the server as a whole may have zero or more annotations > associated with them. An annotation contains a uniquely named entry > with a set of uniquely named attributes, each of which has a value. > Annotations can be added to mailboxes when a mailbox name is provided > as the first argument to the new command, or to the server as a whole > when the empty string is provided as the first argument to the new > command. > >Just a nitpick here, but you should probably refer to SETMETADATA >command by name since (a) it hasn't been introduced at this point in the >document and (b) there is more than one new command added by the draft. > > Agreed. > Each annotation is an entry that has a hierarchical name, with each > component of the name separated by a slash ("/"). An entry name MUST > NOT contain two consecutive "/" characters and MUST NOT end with a > "/" character. > > Each entry is made up of a set of attributes. Each attribute has a > hierarchical name, with each component of the name separated by a > period ("."). An attribute name MUST NOT contain two consecutive "." > characters and MUST NOT end with a "." character. > >My last comment is personal preference: I fear that this may be a bit of >overkill for folder annotation. I understand the need for this type of >flexible syntax for ACAP's purposes, but the use cases for IMAP appear >significantly more limited in scope. In accordance with the KISS >philosophy, is there any chance I might be able to convince everyone to >consider shedding a layer of hierarchy here? > > This is not going to be a problem in practice. IMHO, new attributes are unlikely to be standardized. IMHO, the current model of value.priv + value.shared per annotation should work for 99% cases. _______________________________________________ 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 Apr 10 07:12:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEGZ-0006Qb-28; Tue, 10 Apr 2007 07:12:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEGX-0006QW-No for lemonade@ietf.org; Tue, 10 Apr 2007 07:12:01 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEGW-00083c-4D for lemonade@ietf.org; Tue, 10 Apr 2007 07:12:01 -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, 10 Apr 2007 12:11:35 +0100 Message-ID: <461A9AF7.9050901@isode.com> Date: Mon, 09 Apr 2007 20:58:47 +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: Randall Gellens MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: Lemonade WG Subject: [lemonade] Initial comments on draft-ietf-lemonade-notifications-04.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 Hi Randy, Thank you for the update. I've done some quick scan through the document, mostly concentrating on classifying references and checking how they are used. My comments are below: 5. Capability A server supporting Lemonade notifications MUST report the following set of capabilities: IDLE, METADATA, LISTEXT, LNOTIFICATION, VFOLDER. This list if out-of-date: s/LISTEXT/LIST-EXTENDED. Should VFOLDER be dropped or replace with CONTEXT? Need to review what LNOTIFICATION does and whether it needs to be replaced with something. (Sorry, I didn't have time to check this) 14.4. Notification payloads [...] # Realize the messaging mecanisms typo: mechanisms Later in the same section: s/Login to mailbox/Mailbox open ? A similar change regarding Logout. (Login/Logout have a different meaning in IMAP) s/Delete Message/Mark message as deleted ? (to match IMAP) "Mailbox full cancellation" - what does this mean? In general, the list of tasks needs to be reviewed and synchronized with Chris' draft on message event types. Later in the same section: reference [RFC-URL] is not defined. I think both [RFC-URL] and [URLAUTH] needs to be replaced with a single reference pointing to 2192bis. 16. Normative and Informative References [[ editor's note: split into two sections, update references ]] [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. http://www.ietf.org/rfc/rfc2234 Not referenced [ANNOTATEMORE] Daboo, C., "IMAP ANNOTATEMORE Extension", work in progress, draft-daboo-imap-annotatemore-xx, (work in progress). Normative [GSM03.40] GSM 03.40 v7.4.0 Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS). ETSI 2000 This seems to be informative [IMAP-DISC] Melnikov, A. "Synchronization operations for disconnected IMAP4 clients", draft-melnikov-imap-disc-06.txt, October 2004. Informative [IMAP-EVENTS] Melnikov, A. " Lemonade Inband Notifications", draft-melnikov-lemonade-imap-events-00.txt, June 17, 2006 Normative [IMAPSIEVE] Leiba, B., "Support for Sieve in Internet Message Access Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-0x (work in progress). This seems to be informative but might become normative. This depends on what the WG decides on use of Sieve in Lemonade. [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", draft-ietf-lemonade-profile-XX.txt, (work in progress). I suggest dropping this one. It is used only in one place and it doesn't have to be referenced. This reference is Informative at best. [LEMONADEPROFILEBIS] Maes, S.H., Melnikov A. and D. Cridland, " LEMONADE profile bis", draft-ietf-lemonade-profile-bis-xx.txt, (work in progress). Normative [MANAGESIEVE] Martin, T. and A. Melnikov, "A Protocol for Remotely Managing Sieve Scripts", draft-martin-managesieve-xx.txt, (work in progress). Normative. Hmm, we need to decide if this reference would be needed for the Lemonade Profile Bis. [MSGEVENTS] Newman, C., "Internet Message Store Events", draft- newman-lemonade-msgevent-xx.txt, (work in progress). Normative [NOTIFICATIONPROTOCOL] Maes, S.H., " Lemonade Notification protocol ", draft-ietf-lemonade-notification-protocol-xx.txt, (work in progress). Normative [OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August 2002. http://www.openmobilealliance.org/tech/docs/EmailNot/OMA- Push-EMN-V1_0-20020830-C.pdf This is normative. If the WG decides not to use EMN, then this reference will go away. [OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document, (Work in progress). http://www.openmobilealliance.org/ Not referenced [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, (Work in progress). http://www.openmobilealliance.org/ Informative? [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S- M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). Informative [RECONNECT] A. Melnikov, C. Wilson, "IMAP4 Extensions for Quick Add an empty line after this. The definition seems to be truncated. This needs to point to draft-ietf-lemonade-reconnect-client-03.txt [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997. http://www.ietf.org/rfc/rfc2177. Normative. After Barry saying that IMAP NOTIFY should obsolete IDLE, should we at least add a reference to IMAP NOTIFY? [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 This is only used in one sentence, but I don't think the sentence gives any information. So I suggest to remove the sentence. However, it seems that the ABNF section needs a reference to RFC 3501, in which case this will become a normative reference. [SIEVE] SIEVE WG, http://www.ietf.org/html.charters/sieve- charter.html I suggest to replace this with 3028bis. This seems to be Normative. [SIEVENOTIFICATIONS] Melnikov, A., "Sieve -- An extension for providing instant notifications", draft-ietf-sieve-notify-XX.txt, (work in progress) Not referenced [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth- XX.txt, (work in progress). Normative. I think this is should be replaced with 2192bis. [VFOLDER] Maes, S. and et Al., "Persistent Search Extensions and Virtual Folder to the IMAP Protocol", draft-maes-lemonade-vfolder- 0x, (work in progress). Normative. Replace with a reference to IMAP CONTEXT? [WAPWDP] Wireless Datagram Protocol, Version 14-Jun-2001, Wireless Application Protocol WAP-259-WDP- 20010614-aWAP (WDP) Informative _______________________________________________ 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 Apr 10 16:28:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMxK-0006j0-MW; Tue, 10 Apr 2007 16:28:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMxJ-0006iu-0a for lemonade@ietf.org; Tue, 10 Apr 2007 16:28:45 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMxH-0003bi-Jg for lemonade@ietf.org; Tue, 10 Apr 2007 16:28:45 -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, 10 Apr 2007 21:28:42 +0100 Message-ID: <461BF349.7080903@isode.com> Date: Tue, 10 Apr 2007 21:27:53 +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 MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Open Issues with IMAP CONVERT References: <460A7A38.5000304@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> <460BDBF9.9040901@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: lemonade@ietf.org 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 wrote: >>>>3). There is one big issue surrounding INFORMATIONLOSS. I will publish >>>> >>>>an updated draft shortly, but it will not tackle this issue. I will >>>>try to address the issue in the subsequent revision. >>>> >>>> >>>Could You elaborate this, please? >>> >>> >>The issue is how the client can figure out which bodypart was >>converted with loss when the client requested multiple >>conversions in a single FETCH command. >>Some suggested to use URLs to identify the bodypart. Arnt wrote the >>following: >> >> >>>Serious: I don't like the INFORMATIONLOSS response code - it's on the >>> >>> >>>wrong response. As it stands, it means "one or more of the preceeding >>> >>>untagged responses is approximate rather than exact". Either it should >>> >>> >>>be a flag on BODYPARTSTRUCTURE to show exactly which conversion is >>>approximate, or it should carry some arguments to specify the inexact >>> >>> >>>bodypart(s). >>> >>> >Can we take a moment and think about why we need this? >I mean I am not sure that we need this: > - Probably no client will upscale->no loss. > - Most clients will downscale -> there is always loss. > - Some clients might use format/size conversions-> If client requests >explicit conversion, it should be aware that there might be loss, while >if the client left the conversion choice up to the server, it should >assume that there was a loss. > >What do You think? > > Hi Zoltan, You are making convincing arguments for dropping the response code. Would anybody like to defend why the INFORMATIONLOSS is needed? _______________________________________________ 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 Apr 11 06:51: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 1HbaQ7-00038F-K8; Wed, 11 Apr 2007 06:51:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbaQ6-00038A-Eo for lemonade@ietf.org; Wed, 11 Apr 2007 06:51:22 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HbaQ2-0003CN-GN for lemonade@ietf.org; Wed, 11 Apr 2007 06:51:22 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E91F0498004 for ; Wed, 11 Apr 2007 11:51:06 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16145-09 for ; Wed, 11 Apr 2007 11:51:04 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 4499C498001 for ; Wed, 11 Apr 2007 11:51:04 +0100 (BST) Subject: Re: [lemonade] Open Issues with IMAP CONVERT References: <460A7A38.5000304@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> <460BDBF9.9040901@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com> <461BF349.7080903@isode.com> In-Reply-To: <461BF349.7080903@isode.com> MIME-Version: 1.0 Message-Id: <6701.1176288664.449163@peirce.dave.cridland.net> Date: Wed, 11 Apr 2007 11:51:04 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Tue Apr 10 21:27:53 2007, Alexey Melnikov wrote: > Zoltan.Ordogh@nokia.com wrote: >> Can we take a moment and think about why we need this? >> I mean I am not sure that we need this: >> - Probably no client will upscale->no loss. >> - Most clients will downscale -> there is always loss. >> - Some clients might use format/size conversions-> If client=20 >> requests >> explicit conversion, it should be aware that there might be loss,=20 >> while >> if the client left the conversion choice up to the server, it=20 >> should >> assume that there was a loss. >>=20 >> What do You think? >> =20 > Hi Zoltan, > You are making convincing arguments for dropping the response code. >=20 > Would anybody like to defend why the INFORMATIONLOSS is needed? Well, I'm not convinced it's needed, but I'll advance an argument. Let's assume that a client has very limited capability for character=20 sets. A message arrives in, say, Japanese, and the client requests a=20 conversion of the textual message to ASCII. Severe information loss=20 will take place, and the user almost certainly needs to know that=20 this is the case. Conversly, it may well be useful to know that the converted body part=20 has been losslessly transcoded under some circumstances. Let's=20 suppose an audio part arrives, and the user wishes to listen to it -=20 if the converted part is unintelligible, but the part has been=20 losslessly converted, it would be reasonable for the user to reply=20 with a message saying so. However, if the process of conversion is=20 responsible for the problem, then the user might either wish to wait=20 until they are at a more capable client, or else reply asking for a=20 different format. This all said, I think Zolt=E1n's arguments have convinced me that the=20 common case will be INFORMATIONLOSS, and as a result we should be=20 flagging lossless conversions if we flag anything at all. I'd put myself at around 70% in favour of flagging lossless=20 conversions, incidentally. Dave. --=20 Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Apr 11 07:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbabv-0002Mo-6k; Wed, 11 Apr 2007 07:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbabt-0002Mi-TC for lemonade@ietf.org; Wed, 11 Apr 2007 07:03:33 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbabs-0008Of-FR for lemonade@ietf.org; Wed, 11 Apr 2007 07:03:33 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 923274AC22 for ; Wed, 11 Apr 2007 13:03:33 +0200 (CEST) Message-Id: Date: Wed, 11 Apr 2007 13:02:24 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Open Issues with IMAP CONVERT References: <460A7A38.5000304@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> <460BDBF9.9040901@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com> <461BF349.7080903@isode.com> <6701.1176288664.449163@peirce.dave.cridland.net> In-Reply-To: <6701.1176288664.449163@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 In general terms, I think that if a test suite (or conformance tester) needs to distinguish between two cases, then it should be possible to do so using protocol. Testing is enough of a reason. In other words, this is bad * BYE I logged you out for this reason * BYE I logged you out for that reason because only human-readable text distinguishes between the two cases. Good would be to use protocol, perhaps like this: * BYE [THISREASON] logout for whatever reason * BYE [THATREASON] some human-readable text So: Is it likely that a test suite or conformance tester would need to distinguish between lossless and lossy conversion? Sounds plausible to me, but I've only glanced at the document. 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 Wed Apr 11 09:49:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbdCN-0004dm-G0; Wed, 11 Apr 2007 09:49:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbdCM-0004db-GZ for lemonade@ietf.org; Wed, 11 Apr 2007 09:49:22 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbdCD-0003Xr-4m for lemonade@ietf.org; Wed, 11 Apr 2007 09:49:22 -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 ; Wed, 11 Apr 2007 14:49:09 +0100 Message-ID: <461CE723.9080202@isode.com> Date: Wed, 11 Apr 2007 14:48:19 +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 MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] Open Issues with IMAP CONVERT References: <460A7A38.5000304@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> <460BDBF9.9040901@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com> <461BF349.7080903@isode.com> <6701.1176288664.449163@peirce.dave.cridland.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org 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 Arnt Gulbrandsen wrote: > In general terms, I think that if a test suite (or conformance tester) > needs to distinguish between two cases, then it should be possible to > do so using protocol. Testing is enough of a reason. > > In other words, this is bad > > * BYE I logged you out for this reason > * BYE I logged you out for that reason > > because only human-readable text distinguishes between the two cases. > > Good would be to use protocol, perhaps like this: > > * BYE [THISREASON] logout for whatever reason > * BYE [THATREASON] some human-readable text > > So: Is it likely that a test suite or conformance tester would need to > distinguish between lossless and lossy conversion? Sounds plausible to > me, but I've only glanced at the document. Conformance tester might not be a good enough reason to have INFORMATIONLOSS (or its opposite). We might also have problems with defining what lossless conversion means. E.g. can conversion from text/html to text/plain be lossless? _______________________________________________ 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 Apr 11 11:08:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbeQt-0003X3-QU; Wed, 11 Apr 2007 11:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbeQs-0003Ws-I9 for lemonade@ietf.org; Wed, 11 Apr 2007 11:08:26 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbeQm-0007nt-Kk for lemonade@ietf.org; Wed, 11 Apr 2007 11:08:26 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MFAE8XQ5DC002UF6@mauve.mrochek.com> for lemonade@ietf.org; Wed, 11 Apr 2007 08:08:11 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MF4XXX2O9S000053@mauve.mrochek.com>; Wed, 11 Apr 2007 08:08:05 -0700 (PDT) Date: Wed, 11 Apr 2007 07:58:54 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Open Issues with IMAP CONVERT In-reply-to: "Your message dated Wed, 11 Apr 2007 11:51:04 +0100" <6701.1176288664.449163@peirce.dave.cridland.net> To: Dave Cridland Message-id: <01MFAE8UVAGY000053@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1176304090; h=MIME-version: Content-transfer-encoding:Content-type:Date:From:Subject; b=D1AO8ky lnCueZjiZ/v0iDQQMWp2vLUG2N8lNqZSjVUiYFXTcBZNolk+zeJ0u/gdCKHd2BdSHa2 /zPjNiZhNiGg== References: <460A7A38.5000304@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> <460BDBF9.9040901@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com> <461BF349.7080903@isode.com> <6701.1176288664.449163@peirce.dave.cridland.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Enhancements to Internet email to support diverse service enivronments 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 Tue Apr 10 21:27:53 2007, Alexey Melnikov wrote: > > Zoltan.Ordogh@nokia.com wrote: > >> Can we take a moment and think about why we need this? > >> I mean I am not sure that we need this: > >> - Probably no client will upscale->no loss. > >> - Most clients will downscale -> there is always loss. > >> - Some clients might use format/size conversions-> If client > >> requests > >> explicit conversion, it should be aware that there might be loss= , > >> while > >> if the client left the conversion choice up to the server, it > >> should > >> assume that there was a loss. > >> > >> What do You think? > >> > > Hi Zoltan, > > You are making convincing arguments for dropping the response cod= e. > > > > Would anybody like to defend why the INFORMATIONLOSS is needed? > Well, I'm not convinced it's needed, but I'll advance an argument. I think the information can be very useful in some cases, but only if= you know which parts had conversion losses and which parts did not. So while I= remain unpersuaded that a general "loss occcured" reply is useful, I can thi= nk of cases where a "this part was converted with loss" would be. > Let's assume that a client has very limited capability for characte= r > sets. A message arrives in, say, Japanese, and the client requests = a > conversion of the textual message to ASCII. Severe information loss > will take place, and the user almost certainly needs to know that > this is the case. This is exactly the case that came to mind for me as well, although a= better example would perhaps be conversion from, say, utf-8 to, say, iso-202= 2-jp. In the case of forcing everything to US-ASCII the only time it will work= well is if the original material was in fact US-ASCII with a poor label choic= e of UTF-8. In the case of UTF-8 to ISO-2022-JP, it is entirely reasonasbl= e for UTF-8 to be used regardless of whether the underlying text is Japanes= e (in which case conversion to ISO-2022-JP is fine) or Arabic (in which cas= e the conversion is going to trash the content). A similar case might arise with conversion of formatted documents. In= fact I beleive this is the case that led to the inclusion of "conversion wit= h loss" responses in X.400. > Conversly, it may well be useful to know that the converted body pa= rt > has been losslessly transcoded under some circumstances. Let's > suppose an audio part arrives, and the user wishes to listen to it = - > if the converted part is unintelligible, but the part has been > losslessly converted, it would be reasonable for the user to reply > with a message saying so. However, if the process of conversion is > responsible for the problem, then the user might either wish to wai= t > until they are at a more capable client, or else reply asking for a > different format. > This all said, I think Zolt=E1n's arguments have convinced me that = the > common case will be INFORMATIONLOSS, and as a result we should be > flagging lossless conversions if we flag anything at all. > I'd put myself at around 70% in favour of flagging lossless > conversions, incidentally. I can't get excited about whether or not there's a NOT in front of th= e reported condition. =09=09=09=09Ned _______________________________________________ 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 Apr 11 15:25: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 1HbiRh-0005t1-0k; Wed, 11 Apr 2007 15:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbiRf-0005st-BH for lemonade@ietf.org; Wed, 11 Apr 2007 15:25:31 -0400 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbiRe-0002l4-5T for lemonade@ietf.org; Wed, 11 Apr 2007 15:25:31 -0400 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail3.panix.com (Postfix) with ESMTP id 0772C13A869 for ; Wed, 11 Apr 2007 15:25:30 -0400 (EDT) Received: from [192.168.1.11] (ool-45749fe3.dyn.optonline.net [69.116.159.227]) by mailspool2.panix.com (Postfix) with ESMTP id EC3A653EAA0 for ; Wed, 11 Apr 2007 15:25:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: This is what the ph server said. Message-Id: In-Reply-To: <461CE723.9080202@isode.com> References: <460A7A38.5000304@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> <460BDBF9.9040901@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com> <461BF349.7080903@isode.com> <6701.1176288664.449163@peirce.dave.cridland.net> <461CE723.9080202@isode.com> X-Mailer: Eudora for Mac OS X 6.2.4 (MacOS 10.4.9) Date: Wed, 11 Apr 2007 13:28:06 -0400 To: lemonade@ietf.org From: "Robert A. Rosenberg" Subject: Re: [lemonade] Open Issues with IMAP CONVERT Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 14:48 +0100 on 04/11/2007, Alexey Melnikov wrote about Re: [lemonade] Open Issues with IMAP CONVERT: >We might also have problems with defining what lossless conversion >means. E.g. can conversion from text/html to text/plain be lossless? That depends on what information is being lost. If it is only formatting (ie: You get the same text/plain as would occur with a multi-part/alternate email) then it is lossless. OTOH, if there are HTML entry characters and these can not be displayed in the text/plain charset then there is some information loss. _______________________________________________ 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 Apr 12 04:11: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 1HbuOr-0004mR-3W; Thu, 12 Apr 2007 04:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbuOp-0004mJ-AP for lemonade@ietf.org; Thu, 12 Apr 2007 04:11:23 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbuOo-0000iB-Qo for lemonade@ietf.org; Thu, 12 Apr 2007 04:11:23 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3C8AkvX003204; Thu, 12 Apr 2007 11:11:20 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 11:11:15 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 11:11:14 +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] Open Issues with IMAP CONVERT Date: Thu, 12 Apr 2007 11:09:30 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15753C41E@esebe199.NOE.Nokia.com> In-Reply-To: <6701.1176288664.449163@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Open Issues with IMAP CONVERT Thread-Index: Acd8J6JuJ6CU3vRfRfOGwAjoSQWADAArwlpw References: <460A7A38.5000304@isode.com><4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com><460BDBF9.9040901@isode.com><4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com><461BF349.7080903@isode.com> <6701.1176288664.449163@peirce.dave.cridland.net> From: To: , X-OriginalArrivalTime: 12 Apr 2007 08:11:14.0879 (UTC) FILETIME=[23CE5CF0:01C77CDA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070412111120-0A9ACBB0-7D1606CC/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Dave, I added some responses below. >>> Can we take a moment and think about why we need this? >>> I mean I am not sure that we need this: >>> - Probably no client will upscale->no loss. >>> - Most clients will downscale -> there is always loss. >>> - Some clients might use format/size conversions-> If=20 >client requests=20 >>> explicit conversion, it should be aware that there might be loss,=20 >>> while if the client left the conversion choice up to the server, it=20 >>> should assume that there was a loss. >>>=20 >>> What do You think? >>> =20 >> Hi Zoltan, >> You are making convincing arguments for dropping the response code. >>=20 >> Would anybody like to defend why the INFORMATIONLOSS is needed? > >Well, I'm not convinced it's needed, but I'll advance an argument. > >Let's assume that a client has very limited capability for=20 >character sets. A message arrives in, say, Japanese, and the=20 >client requests a conversion of the textual message to ASCII.=20 >Severe information loss will take place, and the user almost=20 >certainly needs to know that this is the case. I suppose in this case the conversion shoud fail because there is no way to convert Japanese to ASCII. >Conversly, it may well be useful to know that the converted=20 >body part has been losslessly transcoded under some=20 >circumstances. Let's suppose an audio part arrives, and the=20 >user wishes to listen to it - if the converted part is=20 >unintelligible, but the part has been losslessly converted, it=20 >would be reasonable for the user to reply with a message=20 >saying so. However, if the process of conversion is=20 >responsible for the problem, then the user might either wish=20 >to wait until they are at a more capable client, or else reply=20 >asking for a different format. Could You provide a use case for this: the process of conversion is responsible for creating unintelligible content. I was thinking something like: You receive a large image (1600*1200), and Your client requests coverting it to a server-selected size (and server picks 32*32). But then I realized that in this case the culprit is not the process of conversion. It is the server for picking an extremently low resolution - instead of creating unintelligible content, the server should fail this request instead. _______________________________________________ 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 Apr 12 18:50:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc87G-0005Re-Lh; Thu, 12 Apr 2007 18:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc879-0005DJ-Hh; Thu, 12 Apr 2007 18:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc879-0001qq-9Y; Thu, 12 Apr 2007 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A283C26E8A; Thu, 12 Apr 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hc878-0006qj-B8; Thu, 12 Apr 2007 18:50:02 -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: Thu, 12 Apr 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-06.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) : S. Maes, et al. Filename : draft-ietf-lemonade-convert-06.txt Pages : 16 Date : 2007-4-12 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-06.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-06.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-06.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-4-12151317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-12151317.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 Fri Apr 13 04:40:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHKr-0007Z8-8D; Fri, 13 Apr 2007 04:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHKr-0007Z3-0B for lemonade@ietf.org; Fri, 13 Apr 2007 04:40:49 -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 1HcHKp-0000sY-IH for lemonade@ietf.org; Fri, 13 Apr 2007 04:40:48 -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 l3D8eW15006319 for ; Fri, 13 Apr 2007 11:40:45 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 11:40:33 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 11:40:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [lemonade] Interim meeting Date: Fri, 13 Apr 2007 11:38:48 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15753CC9F@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Interim meeting Thread-Index: Acd9pyfDklXhfR36QpGoutXFgFUsvA== From: To: X-OriginalArrivalTime: 13 Apr 2007 08:40:32.0905 (UTC) FILETIME=[66159790:01C77DA7] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070413114045-1871ABB0-0B15B92E/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: , Content-Type: multipart/mixed; boundary="===============0225499892==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0225499892== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77DA7.660D12B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77DA7.660D12B5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, would it be possbile to update the web site with the details of the = interim meeting? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 ------_=_NextPart_001_01C77DA7.660D12B5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [lemonade] Interim meeting

Hi all,
would it be possbile to = update the web site with the details of the interim meeting?
Thank You.

Best regards: Zolt=E1n = =D6rd=F6gh
E-mail: zoltan = dot ordogh at nokia dot com
Phone: = +358 50 386 = 0566


------_=_NextPart_001_01C77DA7.660D12B5-- --===============0225499892== 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 --===============0225499892==-- From lemonade-bounces@ietf.org Fri Apr 13 07:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKNd-0003Nf-JK; Fri, 13 Apr 2007 07:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKNc-0003NV-MQ for lemonade@ietf.org; Fri, 13 Apr 2007 07:55:52 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKNb-0004QS-9Q for lemonade@ietf.org; Fri, 13 Apr 2007 07:55:52 -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, 13 Apr 2007 12:55:49 +0100 Message-ID: <461F4731.1010804@isode.com> Date: Fri, 13 Apr 2007 10:02:41 +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: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org 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 Randall Gellens wrote: > Also in Section 4.2, perhaps it would be more compact, and easier on > clients and servers, to advertise the supported conversions under the > media type rather than sub-type? So rather than have > '/convert/image/jpeg' just have '/convert/image' contain the supported > destination formats? Right. -06 uses '/convert/image/@/types' for the same purpose. > LPerhaps also likewise for the parameters? I haven't done this for parameters. If people think that this is needed, it can be easily added. > This may come down to how these mailbox annotations are generated > and used: if servers generate the annotations dynamically, and if > clients fetch and consume them immediately prior to requesting a > conversion, then having the extra levels of hierarchy are fine. But if > the data will be stored or cached by either side, flattening seems > beneficial. I know the example shows a server that can convert from > only one image format but can convert into a number of them. But is > that realistic? It's also true that it would be possible for > conversion parameters to be advertised that don't make sense or aren't > supported for all subtypes, but how likely is it that clients would > request them, and even so, this can be handled with an error. > > In the case of some media types (especially 'application') it might > not make sense to flatten the hierarchy. Right. The current text recommends that client check /convert///types first, and if it is not found, then the client should fall back to checking /convert//@/types. _______________________________________________ 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 Apr 13 07:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKNd-0003Na-FV; Fri, 13 Apr 2007 07:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKNc-0003NQ-Iq for lemonade@ietf.org; Fri, 13 Apr 2007 07:55:52 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKNb-0004QT-AU for lemonade@ietf.org; Fri, 13 Apr 2007 07:55:52 -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, 13 Apr 2007 12:55:48 +0100 Message-ID: <461F4591.9070504@isode.com> Date: Fri, 13 Apr 2007 09:55:45 +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 MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] WGCL Convert-05 References: <774007.99226.qm@web30502.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org 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 Arnt Gulbrandsen wrote: > In 6.1.1, I think the sentence on resize needs to make up its mind. I think you've meant "depth". > Either it's an item in the list, in which case it's a SHOULD, or it's > paragraph of its own after the list, in which case it's a gentle > suggestion. It is a separate sentence now. _______________________________________________ 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 Apr 13 07:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKNq-0003QO-PR; Fri, 13 Apr 2007 07:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKNp-0003QJ-Sr for lemonade@ietf.org; Fri, 13 Apr 2007 07:56:05 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKNn-0004S6-6l for lemonade@ietf.org; Fri, 13 Apr 2007 07:56:05 -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, 13 Apr 2007 12:55:49 +0100 Message-ID: <461F4AFF.7080400@isode.com> Date: Fri, 13 Apr 2007 10:18:55 +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: Lingyan Wu , Randall Gellens References: <22C8A0D5D5E095449AB509FE777B5F8006DC969@svr-exchange.avocado.emccsoft.com> <11375.1169027406.780704@invsysm1> <45AEB6FE.3080306@pathbreaker.com> <07c701c73f9e$ad39af90$4e78a40a@china.huawei.com> In-Reply-To: <07c701c73f9e$ad39af90$4e78a40a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Lemonade WG Subject: [lemonade] How can a server identify client's capabilities (was WGCL Convert-05) 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 Randall Gellens wrote: > Also in Section 5, the text mentions the server having knowledge of > the device: how does the client identify a specific device? Users may > have multiple devices. Lingyan Wu wrote: > How about to add a optional parameters (URL of UAProfile) to the > CONVERT requeste? > Server can get device capability information based on the URL provided > in the request and determine what conversions are possible. This might work, something like: c001 FETCH 2 BODY[3.CONVERT ("image/jpeg" ("DeviceID" "Nokia-770"))] ? _______________________________________________ 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 Apr 13 08:21: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 1HcKmL-000262-Cc; Fri, 13 Apr 2007 08:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKmK-00024d-Qb for lemonade@ietf.org; Fri, 13 Apr 2007 08:21:24 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKmK-0002hP-7Q for lemonade@ietf.org; Fri, 13 Apr 2007 08:21:24 -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, 13 Apr 2007 13:21:23 +0100 Message-ID: <461F7591.2020300@isode.com> Date: Fri, 13 Apr 2007 13:20:33 +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 MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-06.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Internet-Drafts@ietf.org wrote: >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) : S. Maes, et al. > Filename : draft-ietf-lemonade-convert-06.txt > Pages : 16 > Date : 2007-4-12 > >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. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-06.txt > > This revision addresses all outstanding issues except: 1). STRICT/CONVERSIONLOSS/... 2). IANA registry for conversion parameters. I think we need one. Opinions? _______________________________________________ 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 Apr 13 12:27:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOc9-0003wz-T3; Fri, 13 Apr 2007 12:27:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HcOc8-0003wu-VN for lemonade-confirm+ok@megatron.ietf.org; Fri, 13 Apr 2007 12:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOc8-0003wm-Lp for lemonade@ietf.org; Fri, 13 Apr 2007 12:27:08 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOc7-0002ho-7r for lemonade@ietf.org; Fri, 13 Apr 2007 12:27:08 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 161574AC30; Fri, 13 Apr 2007 18:27:08 +0200 (CEST) Message-Id: Date: Fri, 13 Apr 2007 18:26:09 +0200 From: Arnt Gulbrandsen To: Dave Cridland , Lemonade WG Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [lemonade] profile-bis review 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 I notice that 3.1 now requires BURL imap, as opposed to BURL. That breaks my code, which only provides BURL imap://prearranged.trusted.blah, ie. it can only catenate within the trust domain, not from arbitrary IMAP servers across the net. 3.1 also requires QUICKSTART, which I'd rather drop. I sort of like QUICSTART, but I like the idea of concluding Lemonade even more and QUICKSTART doesn't buy us very much. It saves roundtrips (and some bytes) when submitting messages, but IMO that's insignificant. There aren't very many messages, and the user does not have to wait - the client can finish submitting in the background while the user reads some more mail, replies to something else, etc. 3.2... I've mixed feelings about some of these extensions. Oh well. 4.6 contains a typo. $lt; should be <. 6 could say that clients should do SRV lookups to find their Submit and IMAP servers, absent any explicit configuration of course. Why doesn't it? 8.5.2.2 contains an awful typo - the notice which says 'this notice will disappear' uses mismatched <> signs ;) 12 omits the changes between versions 4 and 5. Have a good weekend. 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 Sat Apr 14 14:55: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 1HcnPK-00019I-B1; Sat, 14 Apr 2007 14:55:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HcnPJ-00018G-F4 for lemonade-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 14:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcnPJ-000188-5A for lemonade@ietf.org; Sat, 14 Apr 2007 14:55:33 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcnPG-00069w-TC; Sat, 14 Apr 2007 14:55:33 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Sat, 14 Apr 2007 13:55:30 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Sat, 14 Apr 2007 13:55:23 -0500 To: Mark Crispin From: Pete Resnick Subject: Re: [lemonade] Deprecate IMAP IDLE? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "lemonade@ietf.org" , imap-ext@ietf.org 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 4/8/07 at 4:42 PM -0700, Mark Crispin wrote: >Deprecating IDLE may be in charter for IMAPEXT, but I doubt that at >this late stage IMAPEXT will want to deal with it. What he said. The IMAPEXT chair. -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ 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 Sun Apr 15 23:35: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 1HdI03-0005FX-E7; Sun, 15 Apr 2007 23:35:31 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdI02-0005FS-Ni for lemonade-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 23:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdI02-0005FK-E1 for lemonade@ietf.org; Sun, 15 Apr 2007 23:35:30 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdI00-0000D4-Ve for lemonade@ietf.org; Sun, 15 Apr 2007 23:35:30 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGK009QUN9TZU@szxga02-in.huawei.com> for lemonade@ietf.org; Mon, 16 Apr 2007 11:34:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JGK00L1GN9TQ6@szxga02-in.huawei.com> for lemonade@ietf.org; Mon, 16 Apr 2007 11:34:41 +0800 (CST) Received: from w48795 ([10.164.120.80]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGK001U2N9S72@szxml04-in.huawei.com> for lemonade@ietf.org; Mon, 16 Apr 2007 11:34:41 +0800 (CST) Date: Mon, 16 Apr 2007 11:34:40 +0800 From: Lingyan Wu To: Alexey Melnikov , Randall Gellens Message-id: <009d01c77fd8$2a88a450$5078a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <22C8A0D5D5E095449AB509FE777B5F8006DC969@svr-exchange.avocado.emccsoft.com> <11375.1169027406.780704@invsysm1> <45AEB6FE.3080306@pathbreaker.com> <07c701c73f9e$ad39af90$4e78a40a@china.huawei.com> <461F4AFF.7080400@isode.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Lemonade WG Subject: [lemonade] Re: How can a server identify client's capabilities (was WGCL Convert-05) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu 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 ----- Original Message ----- From: "Alexey Melnikov" To: "Lingyan Wu" ; "Randall Gellens" Cc: "Lemonade WG" Sent: Friday, April 13, 2007 5:18 PM Subject: How can a server identify client's capabilities (was WGCL Convert-05) > Randall Gellens wrote: > >> Also in Section 5, the text mentions the server having knowledge of the >> device: how does the client identify a specific device? Users may have >> multiple devices. > > Lingyan Wu wrote: > >> How about to add a optional parameters (URL of UAProfile) to the CONVERT >> requeste? >> Server can get device capability information based on the URL provided in >> the request and determine what conversions are possible. > > This might work, something like: > > c001 FETCH 2 BODY[3.CONVERT ("image/jpeg" ("DeviceID" "Nokia-770"))] > > ? > > > _______________________________________________ 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 Sun Apr 15 23:38:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdI35-0006Jn-6L; Sun, 15 Apr 2007 23:38:39 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdI34-0006Ji-Gu for lemonade-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 23:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdI34-0006Ja-7N for lemonade@ietf.org; Sun, 15 Apr 2007 23:38:38 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdI32-00026T-P5 for lemonade@ietf.org; Sun, 15 Apr 2007 23:38:38 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGK009W9NEZZU@szxga02-in.huawei.com> for lemonade@ietf.org; Mon, 16 Apr 2007 11:37:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JGK00LTWNEZQ6@szxga02-in.huawei.com> for lemonade@ietf.org; Mon, 16 Apr 2007 11:37:47 +0800 (CST) Received: from w48795 ([10.164.120.80]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGK0015UNEY72@szxml04-in.huawei.com> for lemonade@ietf.org; Mon, 16 Apr 2007 11:37:47 +0800 (CST) Date: Mon, 16 Apr 2007 11:37:46 +0800 From: Lingyan Wu To: Randall Gellens , Alexey Melnikov Message-id: <00a301c77fd8$997d2ed0$5078a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <22C8A0D5D5E095449AB509FE777B5F8006DC969@svr-exchange.avocado.emccsoft.com> <11375.1169027406.780704@invsysm1> <45AEB6FE.3080306@pathbreaker.com> <07c701c73f9e$ad39af90$4e78a40a@china.huawei.com> <461F4AFF.7080400@isode.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Lemonade WG Subject: [lemonade] Re: How can a server identify client's capabilities (was WGCL Convert-05) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu 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. Just as what I thought before. Thank you! BTW. I'm sorry I sent an email with nothing just now. Best Regards, Lingyan ----- Original Message ----- From: "Alexey Melnikov" To: "Lingyan Wu" ; "Randall Gellens" Cc: "Lemonade WG" Sent: Friday, April 13, 2007 5:18 PM Subject: How can a server identify client's capabilities (was WGCL Convert-05) > Randall Gellens wrote: > >> Also in Section 5, the text mentions the server having knowledge of the >> device: how does the client identify a specific device? Users may have >> multiple devices. > > Lingyan Wu wrote: > >> How about to add a optional parameters (URL of UAProfile) to the CONVERT >> requeste? >> Server can get device capability information based on the URL provided in >> the request and determine what conversions are possible. > > This might work, something like: > > c001 FETCH 2 BODY[3.CONVERT ("image/jpeg" ("DeviceID" "Nokia-770"))] > > ? > > > _______________________________________________ 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 Apr 16 08:03:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdPvb-0006tC-3f; Mon, 16 Apr 2007 08:03:27 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdPvZ-0006sy-In for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 08:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdPvZ-0006sq-9O for lemonade@ietf.org; Mon, 16 Apr 2007 08:03:25 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdPvW-0001mG-QT for lemonade@ietf.org; Mon, 16 Apr 2007 08:03:25 -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 ; Mon, 16 Apr 2007 13:03:21 +0100 Message-ID: <462102FA.40601@isode.com> Date: Sat, 14 Apr 2007 17:36: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: Tony Finch MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Lemonade WG Subject: [lemonade] Comment on draft-fanf-smtp-quickstart-00.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 Below are my comments after reviewing -00, most of them are editorial: 3. QUICKSTART SMTP service extension definition [...] o The QUICKSTART EHLO keyword value has four OPTIONAL parameters ("QTLS", "AUTH", "QHLO=", and "STARTTLS") to which more can be added by future specifications. I suggest you add a forward reference here for each optional parameter. I saw this list in section 4. I suggest you move it here. 5. The QHLO command The QHLO command has two forms. Support for the basic form defined in this section is REQUIRED. The full form is OPTIONAL, and is defined in Section 8. IMHO, it would be better if you can quickly explain here how the two forms differ, i.e. the full form includes an extra qhlo-id parameter. An SMTP client that supports QUICKSTART MUST first ensure that the server supports it by checking the server's greeting against the syntax specified in Section 4. The client then issues QHLO as its first command instead of EHLO. The basic form of QHLO has the same semantics as the EHLO command, except that it MAY be pipelined if the In a way it seems more similar to the HELO command, as it doesn't return the list of supported extensions. server also supports PIPELINING [RFC2920], How can the client know if PIPELINING is supported? (There is no keyword for PIPELINING in the qsmtp-greet) Suggestion: make PIPELINING REQUIRED everywhere in the document. and the server's 220 response to QHLO does not include its list of supported extensions. 7. Changes to the AUTH command This section describes an OPTIONAL change to the behavior of the AUTH command [RFC2554], support for which is indicated by the presence of the AUTH parameter after the QUICKSTART keyword in the list of extensions supported by the server. This change is also specified by [RFC4468], so if the server lists support for BURL and This change is now formally defined in 2554bis (SMTP AUTH). QUICKSTART and PIPELINING then it MUST include the QUICKSTART AUTH parameter. If the client uses a SASL mechanism which can be completed in one round trip, such as EXTERNAL [RFC4422] or PLAIN [RFC4616], then it MAY pipeline the AUTH command. Suggestion: just reference 2554bis here. If the authentication fails, the server SHOULD reject all subsequent commands other than AUTH, NOOP, Why is this requirement? If authentication is optional, surely this is not a problem? Does this requirement only apply to pipelined command? HELO, EHLO, QHLO, or QUIT with a "530 Authentication failure" reply. If the server supports ENHANCEDSTATUSCODES [RFC2034] [RFC3463], the status code to be returned SHOULD be 5.7.0. 8. Issuing commands early [...] Support for this is OPTIONAL, and is indicated by the presence of the "QHLO=" parameter after the QUICKSTART keyword in the list of extensions supported by the server. The server MUST also support PIPELINING [RFC2920]. Just to make the last sentence more clear: The server that advertises "QHLO=" MUST also support PIPELINING [RFC2920]. _______________________________________________ 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 Apr 16 10:17:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdS15-00041V-JO; Mon, 16 Apr 2007 10:17:15 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdS14-00041Q-Ab for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 10:17:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdS14-00041I-18 for lemonade@ietf.org; Mon, 16 Apr 2007 10:17:14 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdS10-0001qj-JS for lemonade@ietf.org; Mon, 16 Apr 2007 10:17:13 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59816) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1HdS0S-00089z-2R (Exim 4.63) (return-path ); Mon, 16 Apr 2007 15:16:36 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HdS0S-0007eD-NZ (Exim 4.54) (return-path ); Mon, 16 Apr 2007 15:16:36 +0100 Date: Mon, 16 Apr 2007 15:16:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alexey Melnikov In-Reply-To: <462102FA.40601@isode.com> Message-ID: References: <462102FA.40601@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Lemonade WG Subject: [lemonade] Re: Comment on draft-fanf-smtp-quickstart-00.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 On Sat, 14 Apr 2007, Alexey Melnikov wrote: > Below are my comments after reviewing -00, most of them are editorial: Thanks for looking through it! > 3. QUICKSTART SMTP service extension definition > > o The QUICKSTART EHLO keyword value has four OPTIONAL parameters > > I suggest you add a forward reference here for each optional parameter. Optional parameters will be going away. > 5. The QHLO command > > IMHO, it would be better if you can quickly explain here how the two > forms differ, i.e. the full form includes an extra qhlo-id parameter. Variant forms of QHLO will be going away. > In a way it seems more similar to the HELO command, as it doesn't return > the list of supported extensions. Noted in my current version. > server also supports PIPELINING [RFC2920], > > How can the client know if PIPELINING is supported? > (There is no keyword for PIPELINING in the qsmtp-greet) Section 4 says the server SHOULD include PIPELINING in its extension keyword list in the greeting. (MUST in my current version.) > Suggestion: make PIPELINING REQUIRED everywhere in the document. Already done :-) > 7. Changes to the AUTH command > > This change is now formally defined in 2554bis (SMTP AUTH). Hmm, I'm worried that this silent change will cause interoperability problems. For example, Exim advertises AUTH and PIPELINING but forbids pipelined AUTH (drops the connection). So you can only make this change to the protocol if the server advertises another EHLO keyword to tell the client it is OK to use the new feature. BURL and QUICKSTART serve this purpose. > If the authentication fails, the > server SHOULD reject all subsequent commands other than AUTH, NOOP, > > Why is this requirement? > If authentication is optional, surely this is not a problem? The client is expecting to establish its credentials and if this fails then its later commands won't be interpreted by the server in the way the client expects. For example, consider a dual-purpose server that acts as a submission server if the client authenticates and as an MX otherwise. If authentication fails then the client's messages will be accepted or rejected (by the anti-relaying check) depending on whether the recipients are local or not. > Does this requirement only apply to pipelined command? Yes, because with non-pipelined AUTH the client knows whether or not the AUTH worked before it issues more commands. Tony. -- f.a.n.finch http://dotat.at/ WIGHT PORTLAND PLYMOUTH: MAINLY NORTHERLY 3 OR 4, OCCASIONALLY 5. SLIGHT OR MODERATE. FOG PATCHES AND ISOLATED SHOWERS. MODERATE OR GOOD, OCCASIONALLY VERY POOR. _______________________________________________ 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 Apr 16 12:15:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTr4-0008Cw-Qp; Mon, 16 Apr 2007 12:15:02 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdTr3-00087w-Lq for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 12:15:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTr2-000876-O8 for lemonade@ietf.org; Mon, 16 Apr 2007 12:15:01 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTr1-0008Nv-CC for lemonade@ietf.org; Mon, 16 Apr 2007 12:15:00 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 9D714810C47; Mon, 16 Apr 2007 09:08:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id CA590F2923; Mon, 16 Apr 2007 09:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsauBtrqkC7C; Mon, 16 Apr 2007 09:14:57 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id CC622F2922; Mon, 16 Apr 2007 09:14:57 -0700 (PDT) Date: Mon, 16 Apr 2007 09:14:57 -0700 (PDT) From: Dan Karp To: Alexey Melnikov Message-ID: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <461A8EFC.5050208@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Enhancements to Internet email to support diverse service enivronments , Cyrus Daboo , IMAP Extensions WG Subject: [lemonade] ANNOTATEMORE and COMPARATOR 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 I'd really like to implement LEMONADE. LEMONADE consists of several IMAP extensions which require METADATA, and the current METADATA draft in turn requires LIST-EXTENDED and COMPARATOR. Unfortunately, my server implementation is not compatible with COMPARATOR, in particular the requirement to support i;octet in SEARCH. I'm hoping that there's a way to come to a compromise whereby METADATA can return to not requiring COMPARATOR while still maintaining all its core functionality. I'd hate for such a small thing to be a roadblock for my and others' LEMONADE implementations. Right now, METADATA uses COMPARATOR to specify LIST-EXTENDED selection constraints. The GETMETADATA command doesn't appear to support these constraints at present (though this may be an oversight): getmetadata = "GETMETADATA" SP entries SP attribs entries = entry-match / "(" entry-match *(SP entry-match) ")" entry-match = list-mailbox attribs = attrib / "(" attrib *(SP attrib) ")" attrib = astring I've looked through all the entries defined by the base METADATA draft as well as those defined by several of the LEMONADE drafts that metion METADATA (/comment, /motd, /admin, /sort, /thread, /check, /checkperiod, /convert/..., etc.). None of these appear to benefit in a meaningful way from the LIST-EXTENDED match/collation feature, so I'm gathering that the inclusion of COMPARATOR is intended as more of a nice-to-have with an eye towards accommodating possible future needs rather than a real core METADATA feature. If this is the case -- and towards the end of making METADATA a workable foundation extension that every server can implement -- I'd like to request that the LIST-EXTENDED METADATA selection option type be removed from the METADATA draft. If in the future there is a new METADATA entry that would substantially benefit from using COMPARATOR with LIST-EXTENDED, it should be possible to reintroduce this functionality (or a subset thereof) in the same RFC that registers the new entry. _______________________________________________ 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 Apr 16 12:35:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUAy-00071H-Aw; Mon, 16 Apr 2007 12:35:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUAw-0006yi-Ra for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 12:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUAw-0006ya-IB for lemonade@ietf.org; Mon, 16 Apr 2007 12:35:34 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUAt-0008PE-5K for lemonade@ietf.org; Mon, 16 Apr 2007 12:35:34 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 6FC664AC23; Mon, 16 Apr 2007 18:35:31 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 18:34:46 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org References: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Alexey Melnikov , Cyrus Daboo Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 Dan Karp writes: > Unfortunately, my server implementation is not compatible with > COMPARATOR, in particular the requirement to support i;octet in > SEARCH. Why not? 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 Apr 16 12:41:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUGm-0007bW-G6; Mon, 16 Apr 2007 12:41:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUGl-0007bP-Gt for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 12:41:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUGl-0007bE-79 for lemonade@ietf.org; Mon, 16 Apr 2007 12:41:35 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUGj-0001cK-V1 for lemonade@ietf.org; Mon, 16 Apr 2007 12:41:35 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 5AB9B810C48; Mon, 16 Apr 2007 09:35:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8B464F2923; Mon, 16 Apr 2007 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt0DP9Ysv3AF; Mon, 16 Apr 2007 09:41:33 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 90F12F2922; Mon, 16 Apr 2007 09:41:33 -0700 (PDT) Date: Mon, 16 Apr 2007 09:41:33 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Alexey Melnikov , lemonade@ietf.org, Cyrus Daboo , ietf-imapext@imc.org Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 > > Unfortunately, my server implementation is not compatible with > > COMPARATOR, in particular the requirement to support i;octet in > > SEARCH. > > Why not? Searchable content is effectively transcoded to UTF-16. The original content needed for "i;octet" is available only by serially opening, reading, and reparsing each message in the mailbox (stored 1 file per message), which is sufficiently nonperformant that we can't permit 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 Apr 16 13:07:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUg7-0000rm-7c; Mon, 16 Apr 2007 13:07:47 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUg5-0000qo-0R for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUg4-0000qJ-Ln for lemonade@ietf.org; Mon, 16 Apr 2007 13:07:44 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUcL-0004d9-0r for lemonade@ietf.org; Mon, 16 Apr 2007 13:03:54 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 59AE3810C45; Mon, 16 Apr 2007 09:57:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 7060FF2923; Mon, 16 Apr 2007 10:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+tM-HXrTYcC; Mon, 16 Apr 2007 10:03:52 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 482BDF2922; Mon, 16 Apr 2007 10:03:52 -0700 (PDT) Date: Mon, 16 Apr 2007 10:03:51 -0700 (PDT) From: Dan Karp To: Timo Sirainen Message-ID: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1176742390.16189.364.camel@hurina> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org, Cyrus Daboo , ietf-imapext@imc.org, Alexey Melnikov Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 > > Searchable content is effectively transcoded to UTF-16. The > > original content needed for "i;octet" is available only by serially > > opening, reading, and reparsing each message in the mailbox (stored 1 > > file per message), which is sufficiently nonperformant that we can't > > permit it. > > Do you support full substring searches as standard SEARCH command > requires? In Zimbra's feature list I see "Ability to search using a > prefix plus a wildcard", which seems like a "no" answer. In that case > you're already noncompliant. *That* is a red herring, and I believe that you know it. Can we please redirect the discussion back to the core issue, which is that a) COMPARATOR is a reasonably heavy extension to implement b) METADATA is meant to be a reasonably light extension to implement c) METADATA is being positioned as a prerequisite for many new extensions d) No METADATA entries appear able to make use of the COMPARATOR functionality _______________________________________________ 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 Apr 16 13:08: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 1HdUgS-0001C2-HN; Mon, 16 Apr 2007 13:08:08 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUgP-00013T-D3 for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUgO-00010Z-Ov for lemonade@ietf.org; Mon, 16 Apr 2007 13:08:04 -0400 Received: from dovecot.org ([213.157.71.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUS4-0000RV-D2 for lemonade@ietf.org; Mon, 16 Apr 2007 12:53:17 -0400 Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id BD932F0BF8; Mon, 16 Apr 2007 19:53:10 +0300 (EEST) From: Timo Sirainen To: Dan Karp In-Reply-To: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> Date: Mon, 16 Apr 2007 19:53:10 +0300 Message-Id: <1176742390.16189.364.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org, Cyrus Daboo , ietf-imapext@imc.org, Alexey Melnikov Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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: , Content-Type: multipart/mixed; boundary="===============1588943526==" Errors-To: lemonade-bounces@ietf.org --===============1588943526== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fYPDKaFTsPDGb6/paBZs" --=-fYPDKaFTsPDGb6/paBZs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-04-16 at 09:41 -0700, Dan Karp wrote: > > > Unfortunately, my server implementation is not compatible with=20 > > > COMPARATOR, in particular the requirement to support i;octet in=20 > > > SEARCH. > >=20 > > Why not? >=20 > Searchable content is effectively transcoded to UTF-16. The original con= tent needed for "i;octet" is available only by serially opening, reading, a= nd reparsing each message in the mailbox (stored 1 file per message), which= is sufficiently nonperformant that we can't permit it. Do you support full substring searches as standard SEARCH command requires? In Zimbra's feature list I see "Ability to search using a prefix plus a wildcard", which seems like a "no" answer. In that case you're already noncompliant. --=-fYPDKaFTsPDGb6/paBZs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGI6n1yUhSUUBViskRAqOyAJ4v8JioTLJXABDMMQTsJkHI2GIVFQCZAdXa DV+uZVkeW2hKLPcIvZGdXMU= =fkR5 -----END PGP SIGNATURE----- --=-fYPDKaFTsPDGb6/paBZs-- --===============1588943526== 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 --===============1588943526==-- From lemonade-bounces@ietf.org Mon Apr 16 13:09:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUhf-0001vb-8H; Mon, 16 Apr 2007 13:09:23 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUhe-0001vR-6q for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUhd-0001vJ-Ta for lemonade@ietf.org; Mon, 16 Apr 2007 13:09:21 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUhc-0006xV-Fe for lemonade@ietf.org; Mon, 16 Apr 2007 13:09:21 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 5B16D4AC23 for ; Mon, 16 Apr 2007 19:09:21 +0200 (CEST) Message-Id: <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> Date: Mon, 16 Apr 2007 19:08:37 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Alexey Melnikov , Cyrus Daboo Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 Dan Karp writes: > Searchable content is effectively transcoded to UTF-16. The original > content needed for "i;octet" is available only by serially opening, > reading, and reparsing each message in the mailbox (stored 1 file per > message), which is sufficiently nonperformant that we can't permit > it. Makes sense. (We do something similar, although in our case it the problem is mitigated by other circumstances.) I'm wondering whether the i;octet requirement has outlived its rationale. I know why it needed to be there in the early drafts (other collations fell back to i;octet for some input), but I don't know whether it needs to any more...? 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 Apr 16 13:13:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUlL-0002s9-6p; Mon, 16 Apr 2007 13:13:11 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUlK-0002s2-Cn for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUlK-0002ru-1A for lemonade@ietf.org; Mon, 16 Apr 2007 13:13:10 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUlI-0008Co-KR for lemonade@ietf.org; Mon, 16 Apr 2007 13:13:09 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 49BA84AC22; Mon, 16 Apr 2007 19:13:09 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 19:12:25 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org References: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Alexey Melnikov , Timo Sirainen , Cyrus Daboo Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 Dan Karp writes: > a) COMPARATOR is a reasonably heavy extension to implement I don't think COMPARATOR ought to be that. Various other extensions require it, and it seems wrong for me that COMPARATOR should be heavier than its users. Tail wagging dog. Tell me what makes COMPATOR heavy? 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 Apr 16 13:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUnK-0003nM-Bh; Mon, 16 Apr 2007 13:15:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUnI-0003nD-QE for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUnI-0003n5-Gi for lemonade@ietf.org; Mon, 16 Apr 2007 13:15:12 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUnG-00010Z-42 for lemonade@ietf.org; Mon, 16 Apr 2007 13:15:12 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GHF8l8022755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 10:15:09 -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.03) with ESMTP id l3GHF5Ug028505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2007 10:15:07 -0700 Date: Mon, 16 Apr 2007 10:15:04 -0700 (PDT) From: Mark Crispin To: Timo Sirainen In-Reply-To: <1176742390.16189.364.camel@hurina> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <1176742390.16189.364.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.95936 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: lemonade@ietf.org, IMAP Extensions WG Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 Mon, 16 Apr 2007, Timo Sirainen wrote: > On Mon, 2007-04-16 at 09:41 -0700, Dan Karp wrote: >> Searchable content is effectively transcoded to UTF-16. The original >> content needed for "i;octet" is available only by serially opening, >> reading, and reparsing each message in the mailbox (stored 1 file per >> message), which is sufficiently nonperformant that we can't permit it. > Do you support full substring searches as standard SEARCH command > requires? In Zimbra's feature list I see "Ability to search using a > prefix plus a wildcard", which seems like a "no" answer. In that case > you're already noncompliant. True. I'm not sure what "search using a prefix plus a wildcard" is supposed to mean in IMAP searching, which is of substrings only. For collations in the IMAP context, UTF-16 is problematic for i;octet, i;ascii-casemap, and i;unicode-casemap. I'm not sure about i;basic. I suggest that you use either UTF-8 or UCS-4. The attraction of UTF-16 is to save memory space and a mostly-constant width if most characters are in the BMP (thus effectively the same as UCS-2 handling), but at the cost of MUCH more complex handling of non-BMP characters. -- 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 Mon Apr 16 13:19: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 1HdUrJ-0006Dh-3T; Mon, 16 Apr 2007 13:19:21 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUrH-0006Dc-SC for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:19:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUrH-0006DU-Ii for lemonade@ietf.org; Mon, 16 Apr 2007 13:19:19 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUrG-0002Os-AK for lemonade@ietf.org; Mon, 16 Apr 2007 13:19:19 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id A7B0F810C47; Mon, 16 Apr 2007 10:12:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id BF44DF2923; Mon, 16 Apr 2007 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NRc8PyFwBp9; Mon, 16 Apr 2007 10:19:17 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 74602F2922; Mon, 16 Apr 2007 10:19:17 -0700 (PDT) Date: Mon, 16 Apr 2007 10:19:17 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, Timo Sirainen , Cyrus Daboo , ietf-imapext@imc.org, Alexey Melnikov Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 > > a) COMPARATOR is a reasonably heavy extension to implement > > I don't think COMPARATOR ought to be that. Various other extensions > require it, and it seems wrong for me that COMPARATOR should be > heavier than its users. Tail wagging dog. > > Tell me what makes COMPARATOR heavy? IMAP (via SEARCH) essentially requires that message content be searchable in some intermediate transcoded form (we chose UTF-16). COMPARATOR (via "i;octet") requires that message content be searchable in its original form pace content-encoding. _______________________________________________ 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 Apr 16 13:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUsl-0006gw-J6; Mon, 16 Apr 2007 13:20:51 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdUsk-0006gr-Ad for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUsk-0006gj-1H for lemonade@ietf.org; Mon, 16 Apr 2007 13:20:50 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUsi-0002g2-KC for lemonade@ietf.org; Mon, 16 Apr 2007 13:20:50 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E69034AC23; Mon, 16 Apr 2007 19:20:48 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 19:20:05 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <1176742390.16189.364.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Mark Crispin , Timo Sirainen 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 Mark Crispin writes: > For collations in the IMAP context, UTF-16 is problematic for i;octet, yes. > i;ascii-casemap, and i;unicode-casemap. I'm not sure about i;basic. None of these - the problem was raised about a year ago by an RFC 4790 reviewer and we solved it. Using UTF-16 or UTF-8 instead of a sensible unicode encoding may make it more difficult to implement e.g. i;ascii-casemap, but not especially. Every kind of processing is more difficult in UTF-* than in UCS-*, IMO, and most collations are just specific examples of this general rules. 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 Apr 16 13:43:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVEo-0007Or-87; Mon, 16 Apr 2007 13:43:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdVEm-0007Oj-DE for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:43:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVEm-0007Ob-3l for lemonade@ietf.org; Mon, 16 Apr 2007 13:43:36 -0400 Received: from dovecot.org ([213.157.71.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdVEk-0000zS-Or for lemonade@ietf.org; Mon, 16 Apr 2007 13:43:36 -0400 Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id C6B56F0BBA; Mon, 16 Apr 2007 20:43:33 +0300 (EEST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR From: Timo Sirainen To: Arnt Gulbrandsen In-Reply-To: <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> Date: Mon, 16 Apr 2007 20:43:33 +0300 Message-Id: <1176745413.16189.379.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org, ietf-imapext@imc.org, Cyrus Daboo , 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: , Content-Type: multipart/mixed; boundary="===============0172771822==" Errors-To: lemonade-bounces@ietf.org --===============0172771822== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-K+TEBP4YHYMuMTvRZ4hT" --=-K+TEBP4YHYMuMTvRZ4hT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-04-16 at 19:08 +0200, Arnt Gulbrandsen wrote: > I'm wondering whether the i;octet requirement has outlived its=20 > rationale. I know why it needed to be there in the early drafts (other=20 > collations fell back to i;octet for some input), but I don't know=20 > whether it needs to any more...? The only place I see i;octet required is i18n draft, so I guess it's still possible to change it? I would also want to see i;octet requirement gone. Actually I'd go even a bit further. Is there a reason why a client should be able to force a server to use i;ascii-casemap if i;unicode-casemap is also available? I can't think of any, but it would reduce optimization possibilities for server implementations. Is the i;basic mentioned in i18n draft the same as i;octet? --=-K+TEBP4YHYMuMTvRZ4hT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGI7XFyUhSUUBViskRAmXNAKCJDUxvg+eySM2NZbTNMdhPMwGTLwCfd5tA GoS1+Hnef8yXW7NZoKhQeoI= =WJFi -----END PGP SIGNATURE----- --=-K+TEBP4YHYMuMTvRZ4hT-- --===============0172771822== 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 --===============0172771822==-- From lemonade-bounces@ietf.org Mon Apr 16 13:52: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 1HdVNV-0001Ms-7h; Mon, 16 Apr 2007 13:52:37 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdVNT-0001Ml-Oq for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 13:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVNT-0001Md-FS for lemonade@ietf.org; Mon, 16 Apr 2007 13:52:35 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdVNS-0002uh-6u for lemonade@ietf.org; Mon, 16 Apr 2007 13:52:35 -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 ; Mon, 16 Apr 2007 18:52:33 +0100 Message-ID: <4623B7AC.10600@isode.com> Date: Mon, 16 Apr 2007 18:51:40 +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 MIME-Version: 1.0 To: Timo Sirainen Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: <1176745413.16189.379.camel@hurina> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: lemonade@ietf.org, ietf-imapext@imc.org 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 Timo Sirainen wrote: >Is the i;basic mentioned in i18n draft the same as i;octet? > > No. i;basic is defined in draft-gulbrandsen-collation-basic-01.txt. Note that the mandatory-to-implement in i18n draft is going to be i;unicode-casemap. _______________________________________________ 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 Apr 16 14:00: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 1HdVVY-0004pE-Q1; Mon, 16 Apr 2007 14:00:56 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdVVX-0004nt-HZ for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 14:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVVX-0004nk-84 for lemonade@ietf.org; Mon, 16 Apr 2007 14:00:55 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdVVU-0005Ur-P2 for lemonade@ietf.org; Mon, 16 Apr 2007 14:00:55 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GI0o7b028048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 11:00:51 -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.03) with ESMTP id l3GI0mDn004763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2007 11:00:49 -0700 Date: Mon, 16 Apr 2007 11:00:47 -0700 (PDT) From: Mark Crispin To: Timo Sirainen Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <1176745413.16189.379.camel@hurina> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.104634 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org, IMAP Extensions WG 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 IMHO: i;ascii-casemap is important because there are legacy implementations that implement it. Specifically, i;ascii-casemap *is* effectively the comparator of IMAP since its creation in 1986. I believe that most modern IMAP server implementations do some version of i;unicode-casemap instead of i;ascii-casemap, and there is no way for the client to know with a server that does not otherwise support COMPARATOR. I can't imagine that a client would choose i;ascii-casemap instead of i;unicode-casemap. AFAIK, i;octet was documented for completeness. I would be alright with i;unicode-casemap as being mandatory-to-implement for COMPARATOR, and optional-to-implement (albeit with a SHOULD) instead of i;ascii-casemap for non-COMPARATOR servers. -- 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 Mon Apr 16 15:36:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdX03-0001k2-EO; Mon, 16 Apr 2007 15:36:31 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdX02-0001jw-MW for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 15:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdX02-0001jo-D7 for lemonade@ietf.org; Mon, 16 Apr 2007 15:36:30 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdX00-0003Cd-Tv for lemonade@ietf.org; Mon, 16 Apr 2007 15:36:30 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 82E7F4AC23; Mon, 16 Apr 2007 21:36:24 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 21:35:41 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: <1176745413.16189.379.camel@hurina> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Cyrus Daboo , Alexey Melnikov , Timo Sirainen 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 Timo Sirainen writes: > On Mon, 2007-04-16 at 19:08 +0200, Arnt Gulbrandsen wrote: >> I'm wondering whether the i;octet requirement has outlived its >> rationale. I know why it needed to be there in the early drafts >> (other collations fell back to i;octet for some input), but I don't >> know whether it needs to any more...? > > The only place I see i;octet required is i18n draft, so I guess it's > still possible to change it? That's the stated requirement. There may be an actual requirement elsewhere. SORT comes to mind. > I would also want to see i;octet requirement gone. Actually I'd go > even a bit further. Is there a reason why a client should be able to > force a server to use i;ascii-casemap if i;unicode-casemap is also > available? Yes, but they're odd and weird. > I can't think of any, but it would reduce optimization possibilities > for server implementations. i;ascii-casemap is the same as i;unicode-casemap for the intersection of their definition set, which would give you these optimisations back. (IIRC, and it's late and...) 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 Apr 16 15: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 1HdX33-0003ca-5O; Mon, 16 Apr 2007 15:39:37 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdX31-0003cV-Ri for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 15:39:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdX31-0003cN-IB for lemonade@ietf.org; Mon, 16 Apr 2007 15:39:35 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdX30-0003mY-5F for lemonade@ietf.org; Mon, 16 Apr 2007 15:39:35 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E327D4AC22; Mon, 16 Apr 2007 21:39:34 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 21:38:51 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Mark Crispin , Timo Sirainen 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 Mark Crispin writes: > AFAIK, i;octet was documented for completeness. FWIW: 2244 specified it, I don't know why, although I'm sure the reason is in an archive somewhere. 4790 defined a registry and inserted the preexisting collations. 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 Apr 16 15:45: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 1HdX8o-0005CW-7j; Mon, 16 Apr 2007 15:45:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdX8n-0005CR-4I for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 15:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdX8m-0005CJ-R5 for lemonade@ietf.org; Mon, 16 Apr 2007 15:45:32 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdX8l-0007xU-Ds for lemonade@ietf.org; Mon, 16 Apr 2007 15:45:32 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GJjNYx009434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 12:45:23 -0700 X-Auth-Received: from Ningyo-no-Mori.Panda.COM ([166.129.255.148]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GJj7f2023754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 12:45:18 -0700 Date: Mon, 16 Apr 2007 12:44:33 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.123434 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org, ietf-imapext@imc.org, Timo Sirainen , Cyrus Daboo , 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 Mon, 16 Apr 2007, Arnt Gulbrandsen wrote: >> The only place I see i;octet required is i18n draft, so I guess it's still >> possible to change it? > That's the stated requirement. There may be an actual requirement elsewhere. > SORT comes to mind. No. SORT would use i;unicode-casemap or (older servers) i;ascii-casemap. I always assumed that i;octet was there as a baseline for documentation purposes. I never implemen ted it. >> Is there a reason why a client should be able to force a >> server to use i;ascii-casemap if i;unicode-casemap is also available? > Yes, but they're odd and weird. Examples, please? My software did i;ascii-casemap, but only in old versions as an interim measure. Newer versions are i;unicode-casemap only. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ 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 Apr 16 16:14: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 1HdXau-0004nJ-TP; Mon, 16 Apr 2007 16:14:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdXat-0004ly-GX for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 16:14:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXJj-0006uq-8S for lemonade@ietf.org; Mon, 16 Apr 2007 15:56:51 -0400 Received: from dovecot.org ([213.157.71.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXHG-00053b-Cp for lemonade@ietf.org; Mon, 16 Apr 2007 15:54:33 -0400 Received: from [192.168.10.217] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 2EB14F0BCC; Mon, 16 Apr 2007 22:54:17 +0300 (EEST) In-Reply-To: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Timo Sirainen Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Date: Mon, 16 Apr 2007 22:54:09 +0300 To: Arnt Gulbrandsen X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: lemonade@ietf.org, ietf-imapext@imc.org, Cyrus Daboo , 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: , Content-Type: multipart/mixed; boundary="===============1076934112==" Errors-To: lemonade-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1076934112== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-877554154" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-877554154 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 16.4.2007, at 22.35, Arnt Gulbrandsen wrote: >> I would also want to see i;octet requirement gone. Actually I'd go >> even a bit further. Is there a reason why a client should be able >> to force a server to use i;ascii-casemap if i;unicode-casemap is >> also available? > > Yes, but they're odd and weird. > >> I can't think of any, but it would reduce optimization >> possibilities for server implementations. > > i;ascii-casemap is the same as i;unicode-casemap for the > intersection of their definition set, which would give you these > optimisations back. (IIRC, and it's late and...) I'm just worried that some clients (or users) would select the i;ascii-casemap even when they could (or should) use i;unicode-casemap. Non-ASCII characters with i;ascii-casemap are different, so if the server optimized i;unicode-casemap searches and a client did a non- ASCII search with i;ascii-casemap, the server would have to verify the unicode-optimized matches by searching through the messages to see if the non-ASCII casing matches exactly or not. Probably not that big of a deal, but it would be pretty pointless extra code. --Apple-Mail-1-877554154 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD4DBQFGI9RlyUhSUUBViskRAuJVAJ0STb33TJNhAsj4cT/k+5gTe+9HeACWN+sZ 8yDs/02Q92RYgCbHqI2Hng== =SGj+ -----END PGP SIGNATURE----- --Apple-Mail-1-877554154-- --===============1076934112== 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 --===============1076934112==-- From lemonade-bounces@ietf.org Mon Apr 16 17:59: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 1HdZEF-0005Ly-1p; Mon, 16 Apr 2007 17:59:19 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdZEE-0005Lt-En for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 17:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdZEE-0005Ll-5C for lemonade@ietf.org; Mon, 16 Apr 2007 17:59:18 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdZEC-0005dz-Oj for lemonade@ietf.org; Mon, 16 Apr 2007 17:59:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 01C8849800C; Mon, 16 Apr 2007 22:59:15 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07595-07; Mon, 16 Apr 2007 22:59:09 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 52B46498002; Mon, 16 Apr 2007 22:59:09 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: MIME-Version: 1.0 Message-Id: <4156.1176760749.310421@peirce.dave.cridland.net> Date: Mon, 16 Apr 2007 22:59:09 +0100 From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Enhancements to Internet email to support diverse service enivronments , Mark Crispin , Timo Sirainen , ietf-imapext@imc.org 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 Mon Apr 16 20:38:51 2007, Arnt Gulbrandsen wrote: > Mark Crispin writes: >> AFAIK, i;octet was documented for completeness. > > FWIW: 2244 specified it, I don't know why, although I'm sure the > reason is in an archive somewhere. 4790 defined a registry and > inserted the preexisting collations. ACAP deals in arbitrary binary data which *might* be treatable as text - the server has no way of knowing. "i;octet" is remarkably useful at doing exact matches, whether text or binary, and was the only comparator capable of doing case-sensitive matching on text. In IMAP, this is the only use, and there are undoubtedly better ways of doing this. (I do feel the need, sometimes, for case sensitivity - as today, when searching for messages with the subject line including "OMA"). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Mon Apr 16 19:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdaFX-0007ip-KL; Mon, 16 Apr 2007 19:04:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdaFX-0007ik-8l for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 19:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdaFW-0007ic-VX for lemonade@ietf.org; Mon, 16 Apr 2007 19:04:42 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdaFV-0006Pl-Jl for lemonade@ietf.org; Mon, 16 Apr 2007 19:04:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GN4dHX003440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 16:04:39 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GN4dpw027585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 16:04:39 -0700 Date: Mon, 16 Apr 2007 16:04:24 -0700 (Pacific Daylight Time) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <4156.1176760749.310421@peirce.dave.cridland.net> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.155034 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Enhancements to Internet email to support diverse service enivronments , Timo Sirainen , ietf-imapext@imc.org 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 Mon, 16 Apr 2007, Dave Cridland wrote: > ACAP deals in arbitrary binary data which *might* be treatable as text - the > server has no way of knowing. "i;octet" is remarkably useful at doing exact > matches, whether text or binary, and was the only comparator capable of doing > case-sensitive matching on text. > In IMAP, this is the only use, and there are undoubtedly better ways of doing > this. I don't understand. Everything in IMAP is case-insensitive by definition. There is, AFAIK, no need or use for i;octet anywhere in IMAP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ 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 Apr 16 21:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdcRT-0004Nh-Dx; Mon, 16 Apr 2007 21:25:11 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdcRS-0004Nc-JZ for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 21:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdcRS-0004NU-A7 for lemonade@ietf.org; Mon, 16 Apr 2007 21:25:10 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdcRP-0004nf-OX for lemonade@ietf.org; Mon, 16 Apr 2007 21:25:10 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HdcRK-0001Vq-CD for lemonade@ietf.org; Tue, 17 Apr 2007 03:25:02 +0200 Received: from kaksi.ifi.uio.no ([129.240.65.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 03:25:02 +0200 Received: from kjetilho by kaksi.ifi.uio.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 03:25:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: lemonade@ietf.org From: Kjetil Torgrim Homme Date: Tue, 17 Apr 2007 02:32:19 +0200 Lines: 32 Message-ID: <1rfy6zx2lo.fsf@kaksi.ifi.uio.no> References: <462102FA.40601@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: kaksi.ifi.uio.no User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:8WJbZl0OOjbsrR9HpvuPZIIaG5Q= X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [lemonade] Re: Comment on draft-fanf-smtp-quickstart-00.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 [Tony Finch]: > > > How can the client know if PIPELINING is supported? > > (There is no keyword for PIPELINING in the qsmtp-greet) > > Section 4 says the server SHOULD include PIPELINING in its > extension keyword list in the greeting. (MUST in my current > version.) (in the current 01-draft, it seems PIPELINING support is only mandatory in the presence of QHLO, but your comment above indicates to me you've made PIPELINING mandatory for all QUICKSTART implementations, which I think is the way to go.) isn't this just wasteful? a QUICKSTART client will know PIPELINING is implied, other clients will use EHLO to get the capability list once more, and look for PIPELINING there. sure, it's only 16 bytes, but in any case I don't think it is helpful to give the impression that you may have to add special code to handle a QUICKSTART server which doesn't advertise PIPELINING. as you mention in section 10, the capabilities in should be ignored when considering the EHLO response. in my opinion this means omiting PIPELINING in the banner makes more sense, since it doesn't tempt clients to carry its presence over into normal EHLO mode. I have some more questions, but I'll hold off until I see your current copy since I assume a lot has happened since February. -- Kjetil T. _______________________________________________ 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 Apr 16 23:08: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 1Hde36-0006S2-2S; Mon, 16 Apr 2007 23:08:08 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hde32-0006Py-PA for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 23:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hde32-0006Pn-04; Mon, 16 Apr 2007 23:08:04 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hde30-00073v-J3; Mon, 16 Apr 2007 23:08:03 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3H380uG030522; Mon, 16 Apr 2007 20:08:00 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3H37x2P003208; Mon, 16 Apr 2007 20:07:59 -0700 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: 7bit Date: Mon, 16 Apr 2007 20:08:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LEMONADE Interim Agenda and Venue Thread-Index: AceAnZ0+nAfiAB8kQ8iVdX+u1/sIFQ== From: "Eric Burger" To: "chris newman" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: lemonade@ietf.org, ietf-announce@ietf.org, Glenn Parsons Subject: [lemonade] LEMONADE Interim Agenda and Venue 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 IETF LEMONADE Interim Meeting ============================= Logistics --------- Date: Wednesday, 15 May 2007, Noon ET - 5pm ET Date: Thursday, 16 May 2007, 8am ET - Noon ET Venue: BEA Systems Ltd. 2425 Matheson Blvd. East 7th Floor Mississauga (Toronto), ON L4W 5K4 Canada +1.905.361.2850 phone Remote Access: o High-Speed Internet o Conference Bridge o Jabber o iChat Proposed Agenda --------------- Editor sessions / discussions on: - IMAP CONVERT - Quick resync - IMAP Streaming - IMAP SIEVE - Notifications and filters If not done, then: - WITHIN - IMAP URL bis And, of course: - Profile bis 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 Apr 16 23:11: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 1Hde6X-0008I8-Ob; Mon, 16 Apr 2007 23:11:41 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hde6V-0008Hw-7n for lemonade-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 23:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hde6U-0008Ho-UG for lemonade@ietf.org; Mon, 16 Apr 2007 23:11:38 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hde6T-0007bY-Gs for lemonade@ietf.org; Mon, 16 Apr 2007 23:11:38 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3H3BaKW001604 for ; Mon, 16 Apr 2007 20:11:36 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3H3BYfc016676 for ; Mon, 16 Apr 2007 20:11:34 -0700 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: 7bit Date: Mon, 16 Apr 2007 20:11:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim Thread-Index: AceAnh2lLg+mZhCAThW5JsI0+aGTSw== From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [lemonade] Interim 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 It is always an optimization of sub-optimal choices... We wanted to do Tuesday / Wednesday, but Wednesday / Thursday worked out best. We were considering a venue in Europe, but this time North America worked out better. One thing we had strong consensus on was noon - noon. We will nail down the exact agenda shortly; if you are in Asia and would like your documents discussed in our afternoon session, please drop me a note (off list); if you are in Europe and would like your documents discussed in our morning session, please drop me a note (off list). Please re-RSVP so I can get a lunch & refreshment count. Thanks. -- - Eric 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 Tue Apr 17 03:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdiC3-000791-KT; Tue, 17 Apr 2007 03:33:39 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdiC1-00078w-VA for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 03:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdiC1-00078o-Bw for lemonade@ietf.org; Tue, 17 Apr 2007 03:33:37 -0400 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdiC0-0005M9-2V for lemonade@ietf.org; Tue, 17 Apr 2007 03:33:37 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50317) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1HdiBl-0007TS-Cu (Exim 4.63) (return-path ); Tue, 17 Apr 2007 08:33:21 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HdiBk-0007AE-VI (Exim 4.54) (return-path ); Tue, 17 Apr 2007 08:33:20 +0100 Date: Tue, 17 Apr 2007 08:33:20 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Kjetil Torgrim Homme Subject: Re: [lemonade] Re: Comment on draft-fanf-smtp-quickstart-00.txt In-Reply-To: <1rfy6zx2lo.fsf@kaksi.ifi.uio.no> Message-ID: References: <462102FA.40601@isode.com> <1rfy6zx2lo.fsf@kaksi.ifi.uio.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org 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 Tue, 17 Apr 2007, Kjetil Torgrim Homme wrote: > > as you mention in section 10, the capabilities in > should be ignored when considering the EHLO response. in my opinion > this means omiting PIPELINING in the banner makes more sense, since it > doesn't tempt clients to carry its presence over into normal EHLO > mode. I've decided that it's simpler if the server's capability lists are always consistent between EHLO and QUICKSTART, especially for "full" QUICKSTART. This implies that the server has to offer both QUICKSTART and PIPELINING. It's easier to allow differing capabilities in "simple" QUICKSTART and as you say it is probably worth doing so. I've split the draft into -a (simple) and -b (full) versions so that each looks more like a final spec. They should be out RSN. I'm still undecided about which to go with because I want more opinions from other people about expedience versus generality. I prefer the -b version because it is more powerful. Tony. -- f.a.n.finch http://dotat.at/ DOVER WIGHT PORTLAND: NORTH OR NORTHEAST 3 OR 4, OCCASIONALLY 5. SLIGHT OR MODERATE. SHOWERS WITH FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. _______________________________________________ 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 Apr 17 04:39: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 1HdjDZ-0002mt-3w; Tue, 17 Apr 2007 04:39:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdjDW-0002mf-7M for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 04:39:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdjDV-0002mX-R5 for lemonade@ietf.org; Tue, 17 Apr 2007 04:39:13 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdjDU-0002jL-8w for lemonade@ietf.org; Tue, 17 Apr 2007 04:39:13 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 9B97A4AC23; Tue, 17 Apr 2007 10:39:12 +0200 (CEST) Message-Id: <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> Date: Tue, 17 Apr 2007 10:38:31 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Cyrus Daboo , Alexey Melnikov , Timo Sirainen , Mark Crispin 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 Mark Crispin writes: > On Mon, 16 Apr 2007, Arnt Gulbrandsen wrote: >>> The only place I see i;octet required is i18n draft, so I guess it's >>> still possible to change it? >> That's the stated requirement. There may be an actual requirement >> elsewhere. SORT comes to mind. > > No. SORT would use i;unicode-casemap or (older servers) > i;ascii-casemap. I always assumed that i;octet was there as a > baseline for documentation purposes. I never implemen ted it. SORT requires a complete sort, doesn't it? Nothing other than i;octet provides that any more. i;unicode-casemap contains a sentence which might be construed as "and use i;octet from this point on". I'll try to suggest a alternative wording there, something that reads naturally for an UCS-4 implementation without i;octet. >>> Is there a reason why a client should be able to force a server to >>> use i;ascii-casemap if i;unicode-casemap is also available? >> Yes, but they're odd and weird. > > Examples, please? Any test suite. A test client wishing to test everything required by lemonade would append some carefully constructed messages and use search on them with i;ascii-casemap. An IMAP client which connects to n IMAP servers and executes the same commands on each, noting any differences between the server responses. I thought of something rather different last night, can't remember what it was. But odd and weird - nothing a MUA would do. 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 Tue Apr 17 04:44:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdjIk-0005RN-9f; Tue, 17 Apr 2007 04:44:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdjIj-0005RB-9p for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 04:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdjIi-0005Qx-TP for lemonade@ietf.org; Tue, 17 Apr 2007 04:44:36 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdjIg-0004Ud-V8 for lemonade@ietf.org; Tue, 17 Apr 2007 04:44:36 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 83DEC4AC22; Tue, 17 Apr 2007 10:44:35 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 10:43:54 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org References: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Alexey Melnikov , Timo Sirainen , Cyrus Daboo Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 Dan Karp writes: > IMAP (via SEARCH) essentially requires that message content be > searchable in some intermediate transcoded form (we chose UTF-16). > COMPARATOR (via "i;octet") requires that message content be > searchable in its original form pace content-encoding. Only i;octet does that... we did a lot of work for RFC4790 to allow your kind of implementation, so I think it should be reasonable that COMPARATOR allows it too. As far as I can see, the mention of i;octet in draft-crispin-collation-unicasemap is the only substantial requirement on i;octet, and it's weak. The one in draft-ietf-imapext-i18n is a leftover - something I forgot to delete when its rationale disappeared. 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 Tue Apr 17 05:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjim-0004CX-Hr; Tue, 17 Apr 2007 05:11:32 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hdjik-0004CB-Sx for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 05:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjik-0004C1-I1 for lemonade@ietf.org; Tue, 17 Apr 2007 05:11:30 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdjij-0005ng-50 for lemonade@ietf.org; Tue, 17 Apr 2007 05:11:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3A5C649800C; Tue, 17 Apr 2007 10:11:28 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14023-05; Tue, 17 Apr 2007 10:11:22 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id E539D498002; Tue, 17 Apr 2007 10:11:21 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> In-Reply-To: <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> MIME-Version: 1.0 Message-Id: <4156.1176801081.929064@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 10:11:21 +0100 From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Enhancements to Internet email to support diverse service enivronments , Timo Sirainen , Cyrus Daboo , Mark Crispin , ietf-imapext@imc.org, 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 Tue Apr 17 09:38:31 2007, Arnt Gulbrandsen wrote: > i;unicode-casemap contains a sentence which might be construed as > "and use i;octet from this point on". I'll try to suggest a > alternative wording there, something that reads naturally for an > UCS-4 implementation without i;octet. Well, to do "i;octet" would mean encoding to UTF-8 first. However, you get the same result if you perform a dictionary-like ordering over UCS-4, as far as I'm aware, so it's not a problem for collations, and equality tests work fine too. It's things like substring matching which cause problems, since you can search for a substring matching partial UTF-8 sequences in principle, however, if you've already called those out as illegal input at a protocol level (or "super-comparator" level in this case), even that's blocked. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Tue Apr 17 05:20:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdjrS-0001gI-7b; Tue, 17 Apr 2007 05:20:30 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdjrR-0001g7-6u for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 05:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdjrQ-0001fw-Tb for lemonade@ietf.org; Tue, 17 Apr 2007 05:20:28 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdjrP-0007yZ-Oi for lemonade@ietf.org; Tue, 17 Apr 2007 05:20:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3002F49800C; Tue, 17 Apr 2007 10:20:27 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14023-10; Tue, 17 Apr 2007 10:20:21 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 02038498002; Tue, 17 Apr 2007 10:20:21 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <4156.1176801621.000131@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 10:20:20 +0100 From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Enhancements to Internet email to support diverse service enivronments , Timo Sirainen , ietf-imapext@imc.org 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 Tue Apr 17 00:04:24 2007, Mark Crispin wrote: > > On Mon, 16 Apr 2007, Dave Cridland wrote: >> ACAP deals in arbitrary binary data which *might* be treatable as >> text - the server has no way of knowing. "i;octet" is remarkably >> useful at doing exact matches, whether text or binary, and was the >> only comparator capable of doing case-sensitive matching on text. >> In IMAP, this is the only use, and there are undoubtedly better >> ways of doing this. > > I don't understand. Everything in IMAP is case-insensitive by > definition. There is, AFAIK, no need or use for i;octet anywhere in > IMAP. As I said, I was searching for OMA in subject lines rather a lot yesterday - if I were able to have specified a case-sensitive match, I would have done, since the sequence "oma" appears rather a lot in spurious results. (Such as "Domain", "Automaton", and rather interestingly, "to make" and "from a" on several implementations). I don't think it's quite right to state that "everything in IMAP is case-insensitive", since it seems intuitive to me that subject lines and other human-orientated text is demonstratively case-sensitive; it merely may be more useful to search it case-insensitively for much of the time. (This is not a demand for an "i;unicode-not-casemap" or anything, merely an observation.) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Tue Apr 17 09:30: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 1HdnlP-0006H3-UV; Tue, 17 Apr 2007 09:30:31 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdnlN-0006G8-GK for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 09:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdnlN-0006EH-59 for lemonade@ietf.org; Tue, 17 Apr 2007 09:30:29 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdnlJ-0001TU-Op for lemonade@ietf.org; Tue, 17 Apr 2007 09:30:29 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3HDULhg032731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Apr 2007 06:30:21 -0700 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3HDUI75031000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Apr 2007 06:30:20 -0700 Date: Tue, 17 Apr 2007 06:30:14 -0700 From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <4156.1176801621.000131@peirce.dave.cridland.net> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> <4156.1176801621.000131@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.17.61834 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG 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 Tue, 17 Apr 2007, Dave Cridland wrote: > I don't think it's quite right to state that "everything in IMAP is > case-insensitive", since it seems intuitive to me that subject lines and > other human-orientated text is demonstratively case-sensitive; it merely may > be more useful to search it case-insensitively for much of the time. Take a time machine back 21 years and tell me that I am wrong for specifying that everything in IMAP is case-insensitive. I would have told you back then that you are wrong, and I see no good cause to reverse that choice today. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ 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 Apr 17 10:07:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdoLG-0006b2-KX; Tue, 17 Apr 2007 10:07:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdoLE-0006ap-Iq for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 10:07:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdoLE-0006ah-9K for lemonade@ietf.org; Tue, 17 Apr 2007 10:07:32 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdoLA-0007oG-SY for lemonade@ietf.org; Tue, 17 Apr 2007 10:07:32 -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, 17 Apr 2007 15:07:26 +0100 Message-ID: <4624D46A.1090408@isode.com> Date: Tue, 17 Apr 2007 15:06:34 +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 MIME-Version: 1.0 To: Arnt Gulbrandsen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Lemonade WG Subject: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis 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 Arnt Gulbrandsen wrote: > 3.1 also requires QUICKSTART, which I'd rather drop. I sort of like > QUICSTART, but I like the idea of concluding Lemonade even more and > QUICKSTART doesn't buy us very much. It saves roundtrips (and some > bytes) when submitting messages, but IMO that's insignificant. I actually disagree that this is insignificant. Not very many clients keep persistent SMTP connections. > There aren't very many messages, and the user does not have to wait - > the client can finish submitting in the background while the user > reads some more mail, replies to something else, etc. After reviewing the QUICKSTART document I think that it should not be included in the Lemonade Profile Bis, because it is tricky to implement and thus very easy to get wrong. However I would suggest that the WG continues working on 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 Tue Apr 17 10:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdowW-0005oa-JK; Tue, 17 Apr 2007 10:46:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdowU-0005oV-P2 for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 10:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdowU-0005oN-Fb for lemonade@ietf.org; Tue, 17 Apr 2007 10:46:02 -0400 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdowQ-0001mB-6D for lemonade@ietf.org; Tue, 17 Apr 2007 10:46:02 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56123) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1Hdovo-0003Xn-Ey (Exim 4.63) (return-path ); Tue, 17 Apr 2007 15:45:20 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hdovo-0004oq-Jn (Exim 4.54) (return-path ); Tue, 17 Apr 2007 15:45:20 +0100 Date: Tue, 17 Apr 2007 15:45:20 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alexey Melnikov Subject: Re: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis In-Reply-To: <4624D46A.1090408@isode.com> Message-ID: References: <4624D46A.1090408@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Lemonade WG 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 Tue, 17 Apr 2007, Alexey Melnikov wrote: > > I actually disagree that this is insignificant. Not very many clients keep > persistent SMTP connections. It occurred to me this morning that a good slogan for QUICKSTART is "makes SMTP as fast as HTTP POST". Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE: WEST OR NORTHWEST 5 TO 7, DECREASING 4 OR 5, BACKING SOUTHWEST LATER. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN WEST. SQUALLY SHOWERS. MODERATE OR GOOD. _______________________________________________ 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 Apr 17 11:02: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 1HdpBx-0005kk-1c; Tue, 17 Apr 2007 11:02:01 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdpBv-0005kf-FL for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 11:01:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpBv-0005kU-5k for lemonade@ietf.org; Tue, 17 Apr 2007 11:01:59 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpBt-0002Hs-Og for lemonade@ietf.org; Tue, 17 Apr 2007 11:01:59 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 77DE04AC2B; Tue, 17 Apr 2007 17:01:58 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 17:01:19 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <4624D46A.1090408@isode.com> In-Reply-To: <4624D46A.1090408@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Alexey Melnikov Subject: [lemonade] Re: Inclusion of QUICKSTART in Lemonade Profile-bis 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 Alexey Melnikov writes: > Arnt Gulbrandsen wrote: > >> 3.1 also requires QUICKSTART, which I'd rather drop. I sort of like >> QUICSTART, but I like the idea of concluding Lemonade even more and >> QUICKSTART doesn't buy us very much. It saves roundtrips (and some >> bytes) when submitting messages, but IMO that's insignificant. > > I actually disagree that this is insignificant. Not very many clients > keep persistent SMTP connections. You keep saying that as if it makes any difference. I've implemented persistent SMTP connections in a MUA and it doesn't save much. The SMTP server times out in a few minutes (2821 says five), and most users take a little while to compose the next message. Very few people compose and send more than 12 messages per hour. 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 Tue Apr 17 11:03: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 1HdpCv-00064G-4w; Tue, 17 Apr 2007 11:03:01 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdpCt-00064A-Ps for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 11:02:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpCt-000640-GK for lemonade@ietf.org; Tue, 17 Apr 2007 11:02:59 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpCr-0002U5-V6 for lemonade@ietf.org; Tue, 17 Apr 2007 11:02:59 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3HF2oFu001638; Tue, 17 Apr 2007 18:02:53 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 18:02:51 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 18:02:51 +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] Interim Date: Tue, 17 Apr 2007 18:01:04 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1575D3A16@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Interim Thread-Index: AceAnh2lLg+mZhCAThW5JsI0+aGTSwAYtwjA References: From: To: , X-OriginalArrivalTime: 17 Apr 2007 15:02:51.0242 (UTC) FILETIME=[780D0CA0:01C78101] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070417180253-0383DBB0-2FE6AD01/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Hello Eric, Wednesday and Thursday means 16th 17th of May, right? Canada or US? (If Canada, I need to get a visa). Do You know perhaps which city? Thank You. 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 Eric Burger [mailto:eburger@bea.com]=20 >Sent: 17 April, 2007 06:12 >To: lemonade@ietf.org >Subject: [lemonade] Interim > >It is always an optimization of sub-optimal choices... > >We wanted to do Tuesday / Wednesday, but Wednesday / Thursday=20 >worked out best. > >We were considering a venue in Europe, but this time North=20 >America worked out better. > >One thing we had strong consensus on was noon - noon. > >We will nail down the exact agenda shortly; if you are in Asia=20 >and would like your documents discussed in our afternoon=20 >session, please drop me a note (off list); if you are in=20 >Europe and would like your documents discussed in our morning=20 >session, please drop me a note (off list). > >Please re-RSVP so I can get a lunch & refreshment count. > >Thanks. > >-- >- Eric > >Notice: This email message, together with any attachments,=20 >may contain information of BEA Systems, Inc., its=20 >subsidiaries and affiliated entities, that may be=20 >confidential, proprietary, copyrighted and/or legally=20 >privileged, and is intended solely for the use of the=20 >individual or entity named in this message. If you are not the=20 >intended recipient, and have received this message in error,=20 >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 > _______________________________________________ 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 Apr 17 11:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpTg-0005P8-08; Tue, 17 Apr 2007 11:20:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdpTe-0005Os-EY for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 11:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpTe-0005Ok-4w for lemonade@ietf.org; Tue, 17 Apr 2007 11:20:18 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpTa-0000ng-M4 for lemonade@ietf.org; Tue, 17 Apr 2007 11:20:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 9E6BF49800C; Tue, 17 Apr 2007 16:20:13 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17729-03; Tue, 17 Apr 2007 16:20:07 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id CC2E1498002; Tue, 17 Apr 2007 16:20:06 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> <4156.1176801621.000131@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <26269.1176823206.810258@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 16:20:06 +0100 From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Enhancements to Internet email to support diverse service enivronments , ietf-imapext@imc.org 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 Tue Apr 17 14:30:14 2007, Mark Crispin wrote: > > On Tue, 17 Apr 2007, Dave Cridland wrote: >> I don't think it's quite right to state that "everything in IMAP >> is case-insensitive", since it seems intuitive to me that subject >> lines and other human-orientated text is demonstratively >> case-sensitive; it merely may be more useful to search it >> case-insensitively for much of the time. > > Take a time machine back 21 years and tell me that I am wrong for > specifying that everything in IMAP is case-insensitive. I would > have told you back then that you are wrong, and I see no good cause > to reverse that choice today. NO, ON FURTHER CONSIDERATION YOU'RE ABSOLUTELY RIGHT. CASE IS NEVER INDICATIVE OF ANYTHING, THEREFORE IT MAKES NO SENSE TO SEARCH FOR IT IN ANY INSTANCE. ALSO, ALL EMAIL SHOULD BE PRESENTED ON PROPER 80 COLUMN DISPLAYS, WITH NICE GREEN TEXT ON A PALE GREY SMEARED BACKGROUND YOU'RE ENCOURAGED TO CALL BLACK. Seriously, though, while I'd readily agree that case should be irrelevant in IMAP protocol elements - we've already had that argument, in fact - I don't see that the same applies to human-created, human-directed text, such as subject fields, where the paragraph above does show that case conveys information. It seems reasonable that we wouldn't want to mandate that clients should be prevented from searching case-sensitively. Similarly, many IMAP servers, by stripping away spaces and punctuation before the search test, can harm the usability of searches. Not always. Just sometimes. I don't think that's a contentious statement, and I suspect I've worded this badly if you're disagreeing with me this strongly. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Tue Apr 17 11:23:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpWQ-0007CZ-2Q; Tue, 17 Apr 2007 11:23:10 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdpWO-00078Y-H3 for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 11:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpWO-00077n-7M for lemonade@ietf.org; Tue, 17 Apr 2007 11:23:08 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpWM-0001eO-Qw for lemonade@ietf.org; Tue, 17 Apr 2007 11:23:08 -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, 17 Apr 2007 16:23:05 +0100 Message-ID: <4624E624.1090302@isode.com> Date: Tue, 17 Apr 2007 16:22:12 +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 MIME-Version: 1.0 To: Eric Burger Subject: Re: [lemonade] LEMONADE Interim Agenda and Venue References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org, chris newman 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, My personal opinion on the agenda is stated below: Eric Burger wrote: >Proposed Agenda >--------------- >Editor sessions / discussions on: >- IMAP CONVERT > Yes, even though I still have delusions of finishing the document before the interim ;-). >- Quick resync > Do you mean Tony's SMTP QUICKSTART? IMAP QRECONNECT is done. >- IMAP Streaming >- IMAP SIEVE >- Notifications and filters > Let's list each draft separately: - IMAP NOTIFY (currently draft-gulbrandsen-imap-notify-04.txt) - draft-ietf-lemonade-notifications-04.txt - draft-ietf-lemonade-msgevent-01.txt - This is more or less done. IMHO, nothing to discuss here. >If not done, then: >- WITHIN >- IMAP URL bis > > I am behind on comments from Ted and Zoltan. However they are mostly about structure of the document and not about content. So I don't think we will have much to discuss during the interim. >And, of course: >- Profile bis > _______________________________________________ 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 Apr 17 11:52:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdpyh-0005R4-Jd; Tue, 17 Apr 2007 11:52:23 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hdpyf-0005NZ-Fp for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 11:52:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdpyf-0005NO-6E for lemonade@ietf.org; Tue, 17 Apr 2007 11:52:21 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdpyd-0006vd-TF for lemonade@ietf.org; Tue, 17 Apr 2007 11:52:21 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 993FA810C89; Tue, 17 Apr 2007 08:45:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 5F01DFA862; Tue, 17 Apr 2007 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxampf6gfOw6; Tue, 17 Apr 2007 08:52:18 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id A5685FA863; Tue, 17 Apr 2007 08:52:18 -0700 (PDT) Date: Tue, 17 Apr 2007 08:52:18 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org, Timo Sirainen , Cyrus Daboo , ietf-imapext@imc.org, Alexey Melnikov Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 > > IMAP (via SEARCH) essentially requires that message content be > > searchable in some intermediate transcoded form (we chose UTF-16). > > COMPARATOR (via "i;octet") requires that message content be > > searchable in its original form pace content-encoding. > > Only i;octet does that... we did a lot of work for RFC4790 to allow > your kind of implementation, so I think it should be reasonable that > COMPARATOR allows it too. > > As far as I can see, the mention of i;octet in > draft-crispin-collation-unicasemap is the only substantial requirement > on i;octet, and it's weak. The one in draft-ietf-imapext-i18n is a > leftover - something I forgot to delete when its rationale > disappeared. i;ascii-casemap is problematic as well, for roughly the same reasons: Its equality, ordering, and substring operations are as for i;octet, except that at first, the lower-case letters (octet values 97-122) in each input string are changed to upper case (octet values 65-90). Servers wishing to optimize i;unicode-casemap may well store only a searchable upper case version of the text, which will sort incorrectly under i;ascii-casemap. COMPARATOR requires servers to implement both i;ascii-casemap and i;octet (though i;octet sounds like it may be on the way out). If your aim is to make baseline COMPARATOR support fairly lightweight for IMAP servers, you may be constrained to only requiring i;unicode-casemap. _______________________________________________ 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 Apr 17 12:46: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 1Hdqoe-0007cF-3w; Tue, 17 Apr 2007 12:46:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hdqod-0007bz-2j for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 12:46:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdqoc-0007bp-Ok for lemonade@ietf.org; Tue, 17 Apr 2007 12:46:02 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hdqob-0002Xu-6p for lemonade@ietf.org; Tue, 17 Apr 2007 12:46:02 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 2DFB14AC22; Tue, 17 Apr 2007 18:45:59 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 18:45:19 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org References: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Alexey Melnikov , Timo Sirainen , Cyrus Daboo Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 Dan Karp writes: > i;ascii-casemap is problematic as well, for roughly the same reasons: > > Its equality, ordering, and substring operations are as for > i;octet, except that at first, the lower-case letters (octet > values 97-122) in each input string are changed to upper case > (octet values 65-90). > > Servers wishing to optimize i;unicode-casemap may well store only a > searchable upper case version of the text, which will sort > incorrectly under i;ascii-casemap. Good point. I wanted to permit implementations of i;ascii-casemap to do whatever comes easiest outside US-ASCII. However, the final RFC doesn't reflect my viewpoint in this respect. I don't remember why and don't feel like searching my archive. I certainly wasn't aware of the argument you bring up now. Do you think this is a signficant issue? It doesn't affect searching to a noticeable degree, and its impact on sorting is O(size of result set), not O(size of mailbox). > If your aim is to make baseline COMPARATOR support fairly lightweight > for IMAP servers, you may be constrained to only requiring > i;unicode-casemap. Mumble. Given how many IMAP servers actually implement i;ascii-casemap and nothing else, I'm not happy doing that. Make some other people agree with you so Pete will say "WG consensus". 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 Tue Apr 17 13:06: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 1Hdr89-0001Lh-If; Tue, 17 Apr 2007 13:06:13 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hdr88-0001Lc-1b for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 13:06:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr87-0001LU-OL for lemonade@ietf.org; Tue, 17 Apr 2007 13:06:11 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdr86-0007LD-Ei for lemonade@ietf.org; Tue, 17 Apr 2007 13:06:11 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 2197A810C8B; Tue, 17 Apr 2007 09:59:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id AAE8DFA865; Tue, 17 Apr 2007 10:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgb4PgawmRSa; Tue, 17 Apr 2007 10:06:04 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id E00B5FA862; Tue, 17 Apr 2007 10:06:04 -0700 (PDT) Date: Tue, 17 Apr 2007 10:06:04 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: lemonade@ietf.org, Timo Sirainen , Cyrus Daboo , ietf-imapext@imc.org, Alexey Melnikov Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 > I wanted to permit implementations of i;ascii-casemap to do whatever > comes easiest outside US-ASCII. However, the final RFC doesn't reflect > my viewpoint in this respect. I don't remember why and don't feel like > searching my archive. I certainly wasn't aware of the argument you > bring up now. > > Do you think this is a signficant issue? It doesn't affect searching > to a noticeable degree, and its impact on sorting is O(size of result > set), not O(size of mailbox). Actually, yeah, it does impact search. If you search for "Mtley Cre", i;ascii-casemap doesn't allow that to match "MTLEY CRE". If you've only stored an upcased version of the text, you can't tell the case on the original and thus you can't determine if the non-ASCII accented characters match under i;octet. > > If your aim is to make baseline COMPARATOR support fairly > > lightweight for IMAP servers, you may be constrained to only > > requiring i;unicode-casemap. > > Mumble. Given how many IMAP servers actually implement i;ascii-casemap > and nothing else, I'm not happy doing that. Make some other people > agree with you so Pete will say "WG consensus". Is this true? Do these servers really implement i;ascii-casemap as defined in RFC 4790? I'd expect any RFC 3501-compliant server that knows about more charsets than just US-ASCII to be supporting i;unicode-casemap and *not* i;ascii-casemap because of case-insensitive "SEARCH CHARSET". _______________________________________________ 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 Apr 17 14:26: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 1HdsNg-0007Ls-UK; Tue, 17 Apr 2007 14:26:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdsNf-0007Lc-B2 for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 14:26:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsNf-0007LU-1V for lemonade@ietf.org; Tue, 17 Apr 2007 14:26:19 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdsNc-0004vO-GH for lemonade@ietf.org; Tue, 17 Apr 2007 14:26:19 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 489064AC23 for ; Tue, 17 Apr 2007 20:26:16 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 20:25:36 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org References: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Alexey Melnikov , Timo Sirainen , Cyrus Daboo Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 Dan Karp writes: >> I wanted to permit implementations of i;ascii-casemap to do whatever >> comes easiest outside US-ASCII. However, the final RFC doesn't >> reflect my viewpoint in this respect. I don't remember why and >> don't feel like searching my archive. I certainly wasn't aware of >> the argument you bring up now. >> >> Do you think this is a signficant issue? It doesn't affect searching >> to a noticeable degree, and its impact on sorting is O(size of >> result set), not O(size of mailbox). > > Actually, yeah, it does impact search. If you search for > "Mtley Cre", i;ascii-casemap doesn't allow that > to match "MTLEY CRE". If you've only stored an > upcased version of the text, you can't tell the case on the original > and thus you can't determine if the non-ASCII accented characters > match under i;octet. By the time you get that far, you've eliminated almost all messages not in the actual result set, so opening and rechecking isn't so awfully expensive. >> > If your aim is to make baseline COMPARATOR support fairly >> > lightweight for IMAP servers, you may be constrained to only >> > requiring i;unicode-casemap. >> >> Mumble. Given how many IMAP servers actually implement >> i;ascii-casemap and nothing else, I'm not happy doing that. Make >> some other people agree with you so Pete will say "WG consensus". > > Is this true? Do these servers really implement i;ascii-casemap as > defined in RFC 4790? I'd expect any RFC 3501-compliant server that > knows about more charsets than just US-ASCII to be supporting > i;unicode-casemap and *not* i;ascii-casemap because of > case-insensitive "SEARCH CHARSET". Build some consensus please. I don't want to argue today - I'm in a mood to help little old ladies halfway across the street. Being civil is a strain. 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 Tue Apr 17 14:54:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdspJ-000788-5M; Tue, 17 Apr 2007 14:54:53 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hdsp5-00072r-PC for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 14:54:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdsp5-00072Y-BM for lemonade@ietf.org; Tue, 17 Apr 2007 14:54:39 -0400 Received: from dovecot.org ([213.157.71.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdsp4-0000kV-0H for lemonade@ietf.org; Tue, 17 Apr 2007 14:54:39 -0400 Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 87CA1F0B59; Tue, 17 Apr 2007 21:54:36 +0300 (EEST) From: Timo Sirainen To: Arnt Gulbrandsen In-Reply-To: References: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> Date: Tue, 17 Apr 2007 21:54:36 +0300 Message-Id: <1176836076.16189.465.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade@ietf.org, Cyrus Daboo , ietf-imapext@imc.org, Alexey Melnikov Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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: , Content-Type: multipart/mixed; boundary="===============1923285642==" Errors-To: lemonade-bounces@ietf.org --===============1923285642== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-baA9QaoKY2tQJvsfXhIn" --=-baA9QaoKY2tQJvsfXhIn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-17 at 20:25 +0200, Arnt Gulbrandsen wrote: > >> > If your aim is to make baseline COMPARATOR support fairly > >> > lightweight for IMAP servers, you may be constrained to only > >> > requiring i;unicode-casemap. > >> > >> Mumble. Given how many IMAP servers actually implement=20 > >> i;ascii-casemap and nothing else, I'm not happy doing that. Make=20 > >> some other people agree with you so Pete will say "WG consensus". > > > > Is this true? Do these servers really implement i;ascii-casemap as=20 > > defined in RFC 4790? I'd expect any RFC 3501-compliant server that=20 > > knows about more charsets than just US-ASCII to be supporting=20 > > i;unicode-casemap and *not* i;ascii-casemap because of=20 > > case-insensitive "SEARCH CHARSET". >=20 > Build some consensus please. My server implements only i;ascii-casemap currently, but that's just because I've been busy getting it stable and no-one's complained. I'm going to move to i;unicode-casemap soon, and I don't see a need for i;ascii-casemap. I'd think anyone who is going to implement COMPARATOR won't see i;unicode-casemap requirement as a problem. --=-baA9QaoKY2tQJvsfXhIn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQBGJRfsyUhSUUBViskRAltsAJ9lvWGeuiDlYgewmyoC8ySIphqyUwCYs/wm tKhlQLVXb9mHL+rS34DO7Q== =tFd3 -----END PGP SIGNATURE----- --=-baA9QaoKY2tQJvsfXhIn-- --===============1923285642== 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 --===============1923285642==-- From lemonade-bounces@ietf.org Tue Apr 17 18:13: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 1Hdvvg-00054u-Gk; Tue, 17 Apr 2007 18:13:40 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hdvvf-00054p-JU for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 18:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdvvf-00054h-9w for lemonade@ietf.org; Tue, 17 Apr 2007 18:13:39 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdvvd-00088w-TW for lemonade@ietf.org; Tue, 17 Apr 2007 18:13:39 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3HMDZKs003181 for ; Tue, 17 Apr 2007 15:13:35 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3HMDTmE015540 for ; Tue, 17 Apr 2007 15:13:34 -0700 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: 7bit Date: Tue, 17 Apr 2007 15:07:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC 2192 bis Thread-Index: AceBPNvIywpcmJDdRZmsCBdaqO17nw== From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [lemonade] WGLC 2192 bis 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 http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-04.tx t Have at it. There are already a bunch of editorial nits found - look for content problems. Thanks. Work Group Last Call closes 1 May 2007. 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 Tue Apr 17 19:33: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 1HdxAf-0004mv-24; Tue, 17 Apr 2007 19:33:13 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdxAe-0004mj-9G for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 19:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdxAd-0004mb-Vx for lemonade@ietf.org; Tue, 17 Apr 2007 19:33:11 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdxAc-0000r0-HG for lemonade@ietf.org; Tue, 17 Apr 2007 19:33:11 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3HNX8FR023848; Tue, 17 Apr 2007 16:33:08 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3HNWpSC028574; Tue, 17 Apr 2007 16:33:07 -0700 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] Interim Date: Tue, 17 Apr 2007 16:27:19 -0700 Message-ID: In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1575D3A16@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Interim Thread-Index: AceAnh2lLg+mZhCAThW5JsI0+aGTSwAYtwjAABGu6vA= References: <4C38DC11F6B4FF4FAEA73E30DB5AA1575D3A16@esebe199.NOE.Nokia.com> From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: lemonade@ietf.org 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 16th / 17th; Mississauga, which is a suburb of Toronto.=20 -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Sent: Tuesday, April 17, 2007 11:01 AM To: Eric Burger; lemonade@ietf.org Subject: RE: [lemonade] Interim Hello Eric, Wednesday and Thursday means 16th 17th of May, right? Canada or US? (If Canada, I need to get a visa). Do You know perhaps which city? Thank You. 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 Eric Burger [mailto:eburger@bea.com] >Sent: 17 April, 2007 06:12 >To: lemonade@ietf.org >Subject: [lemonade] Interim > >It is always an optimization of sub-optimal choices... > >We wanted to do Tuesday / Wednesday, but Wednesday / Thursday worked=20 >out best. > >We were considering a venue in Europe, but this time North America=20 >worked out better. > >One thing we had strong consensus on was noon - noon. > >We will nail down the exact agenda shortly; if you are in Asia and=20 >would like your documents discussed in our afternoon session, please=20 >drop me a note (off list); if you are in Europe and would like your=20 >documents discussed in our morning session, please drop me a note (off=20 >list). > >Please re-RSVP so I can get a lunch & refreshment count. > >Thanks. > >-- >- Eric > >Notice: This email message, together with any attachments, may contain=20 >information of BEA Systems, Inc., its subsidiaries and affiliated=20 >entities, that may be confidential, proprietary, copyrighted and/or=20 >legally privileged, and is intended solely for the use of the=20 >individual or entity named in this message. If you are not the intended=20 >recipient, and have received this message in error, please immediately=20 >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 > 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 Tue Apr 17 21:06: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 1HdydK-0003we-5W; Tue, 17 Apr 2007 21:06:54 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdydI-0003wT-Q4 for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 21:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdydI-0003wL-Ga; Tue, 17 Apr 2007 21:06:52 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdydH-00030j-68; Tue, 17 Apr 2007 21:06:52 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3I16lpb019371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2007 18:06:48 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3I16jta001362; Tue, 17 Apr 2007 18:06:46 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 17 Apr 2007 18:03:07 -0700 To: "Eric Burger" , "chris newman" From: Randall Gellens Subject: Re: [lemonade] LEMONADE Interim Agenda and Venue 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, ietf-announce@ietf.org, Glenn Parsons 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 8:08 PM -0700 4/16/07, Eric Burger wrote: > Date: Thursday, 16 May 2007, 8am ET - Noon ET 8 AM is particularly brutal, especially for people coming from western time zones. Even more so since the venue is not in a hotel, so there's extra travel time. I think 10 AM to 1 PM would be much more sane. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Make no judgments where you have no compassion. _______________________________________________ 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 Apr 17 22:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzgO-00072a-7E; Tue, 17 Apr 2007 22:14:08 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HdzgM-00072R-Q7 for lemonade-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 22:14:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzgM-00072I-7S for lemonade@ietf.org; Tue, 17 Apr 2007 22:14:06 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdzgH-0000Yo-NN for lemonade@ietf.org; Tue, 17 Apr 2007 22:14:06 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hdzg4-0008Qw-E2 for lemonade@ietf.org; Wed, 18 Apr 2007 04:13:48 +0200 Received: from kaksi.ifi.uio.no ([129.240.65.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Apr 2007 04:13:48 +0200 Received: from kjetilho by kaksi.ifi.uio.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Apr 2007 04:13:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: lemonade@ietf.org From: Kjetil Torgrim Homme Date: Wed, 18 Apr 2007 04:13:35 +0200 Lines: 30 Message-ID: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: kaksi.ifi.uio.no User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:cf5YKdM27ppyUV5XGy7e3ja725o= X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [lemonade] Re: WGLC 2192 bis 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 Burger]: > > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-04.txt > > Have at it. There are already a bunch of editorial nits found - > look for content problems. sorry if I missed previous discussion, but I think it should say something explicit about STARTTLS, ie., something like the client SHOULD issue STARTTLS before authenticating if the server supports it. this may require the examples to be reworked, since it essentially means you *always* have to do CAPABILITY. if this is unacceptable, I think we need a syntax in the URL to make TLS required -- I don't feel comfortable that messages may start getting sent unencrypted just because a server upgrade added support for DIGESTMD5 in addition to good old PLAIN... on a similar note, should something be said about the special case which is port 993? an editorial comment, if I may: I found the ABNF grammar hard to navigate. if you look at e.g. RFC 2822, you'll see that Pete Resnick started at the top (for each concept) and did a depth first expansion of the elements. there are some exceptions in there, but as a general rule, that ordering is very easy to follow, IMHO. this will probably make it easier to keep the elements required by URLAUTH separate, too. -- Kjetil T. _______________________________________________ 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 Apr 18 08:24: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 1He9DS-0003oA-Ef; Wed, 18 Apr 2007 08:24:54 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1He9DR-0003o5-I3 for lemonade-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 08:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9DR-0003nx-87 for lemonade@ietf.org; Wed, 18 Apr 2007 08:24:53 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9DP-00066N-S3 for lemonade@ietf.org; Wed, 18 Apr 2007 08:24:53 -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 ; Wed, 18 Apr 2007 13:24:50 +0100 Message-ID: <4625580F.40902@isode.com> Date: Wed, 18 Apr 2007 00:28:15 +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 MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis) References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Lemonade WG 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 wrote: >16. Wording chage suggestion in section 3.2 paragraph 9: >"An authentication mechanism is used which will not reveal information to the server which could be used to compromise future connections." >-> >"Use an authentication mechanism with the server that does not reveal any information that could be used to compromise future connections." "Reveal to the server" part is important. The replacement sentence doesn't have it. I understand that the sentence might be difficult to understand, but it is correct. What is the exact problem with the existing sentence? >24. Re-location proposal for section 6.1.2 last paragraph: shouldn't this be in section 6.1.1.5? I would rather not do that. Section 6.1.1.5 provides definition. The last paragraph of section 6.1.2 mostly talks about encoding. Any other opinions? _______________________________________________ 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 Apr 18 08:24: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 1He9DT-0003on-NC; Wed, 18 Apr 2007 08:24:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1He9DS-0003oX-Tr for lemonade-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 08:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9DS-0003oF-K8 for lemonade@ietf.org; Wed, 18 Apr 2007 08:24:54 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9DR-00066N-Ak for lemonade@ietf.org; Wed, 18 Apr 2007 08:24:54 -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 ; Wed, 18 Apr 2007 13:24:51 +0100 Message-ID: <46255B15.60603@isode.com> Date: Wed, 18 Apr 2007 00:41:09 +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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis) References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org 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 wrote: >23. Clarification needed in section 6.1.2 paragraph 4. What is "submit+", what is a "access identifier prefix" and what is a "userid" - these have not been mentioned before, and these are not in the ABNF either. >Same question for "user+", "authuser" in the following paragraphs. > > The previous paragraph starts with: The URLAUTH takes the form ";URLAUTH=::", and MUST be at the end of the URL. So the sentence like the following: The "submit+" access identifier prefix, followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use this URL. really means: The "submit+" identifier prefix, followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use this URL. Would it be clearer if I include <> around "access"? _______________________________________________ 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 Apr 18 08:54:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9fr-0005BP-Kf; Wed, 18 Apr 2007 08:54:15 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1He9fq-0005BG-QR for lemonade-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 08:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9fq-0005B8-H4 for lemonade@ietf.org; Wed, 18 Apr 2007 08:54:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9fp-0001R1-4i for lemonade@ietf.org; Wed, 18 Apr 2007 08:54:14 -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 ; Wed, 18 Apr 2007 13:54:11 +0100 Message-ID: <462614BD.2070208@isode.com> Date: Wed, 18 Apr 2007 13:53:17 +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 MIME-Version: 1.0 To: Kjetil Torgrim Homme Subject: Re: [lemonade] Re: WGLC 2192 bis References: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> In-Reply-To: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org 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 Kjetil Torgrim Homme wrote: >an editorial comment, if I may: I found the ABNF grammar hard to >navigate. if you look at e.g. RFC 2822, you'll see that Pete Resnick >started at the top (for each concept) and did a depth first expansion >of the elements. there are some exceptions in there, but as a general >rule, that ordering is very easy to follow, IMHO. this will probably >make it easier to keep the elements required by URLAUTH separate, too. > Hi Kjetil, I've received a similar comment from Zoltan and Ted, so I will look into improving this. _______________________________________________ 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 Apr 18 09:04:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9pq-0003LT-L1; Wed, 18 Apr 2007 09:04:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1He9pq-0003LN-9o for lemonade-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 09:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9pq-0003LF-0N for lemonade@ietf.org; Wed, 18 Apr 2007 09:04:34 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9po-0004lc-II for lemonade@ietf.org; Wed, 18 Apr 2007 09:04:33 -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 ; Wed, 18 Apr 2007 14:04:31 +0100 Message-ID: <46261729.1080009@isode.com> Date: Wed, 18 Apr 2007 14:03:37 +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 MIME-Version: 1.0 To: Kjetil Torgrim Homme Subject: Re: [lemonade] Re: WGLC 2192 bis References: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> In-Reply-To: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org 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 Kjetil Torgrim Homme wrote: >[Eric Burger]: > > >> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-04.txt >> >> Have at it. There are already a bunch of editorial nits found - >> look for content problems. >> >> >sorry if I missed previous discussion, but I think it should say >something explicit about STARTTLS, ie., something like the client >SHOULD issue STARTTLS before authenticating if the server supports it. >this may require the examples to be reworked, since it essentially >means you *always* have to do CAPABILITY. > Fair enough. Can you suggest specific text to be added? >if this is unacceptable, I >think we need a syntax in the URL to make TLS required -- I don't feel >comfortable that messages may start getting sent unencrypted just >because a server upgrade added support for DIGESTMD5 in addition to >good old PLAIN... > > I was thinking about adding such syntactic element myself. I would like to hear other opinions on this before proceeding. >on a similar note, should something be said about the special case >which is port 993? > > No, this document doesn't describe imaps. _______________________________________________ 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 Apr 18 12:11: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 1HeCkk-0004UW-7o; Wed, 18 Apr 2007 12:11:30 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeCki-0004OT-Ve for lemonade-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 12:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCki-0004N5-J1; Wed, 18 Apr 2007 12:11:28 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCkh-0007Qo-AF; Wed, 18 Apr 2007 12:11:28 -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 ; Wed, 18 Apr 2007 17:11:26 +0100 Message-ID: <462642F7.5000507@isode.com> Date: Wed, 18 Apr 2007 17:10:31 +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: Randall Gellens Subject: Re: [lemonade] LEMONADE Interim Agenda and Venue References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, chris newman , ietf-announce@ietf.org, Glenn Parsons 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 Randall Gellens wrote: > At 8:08 PM -0700 4/16/07, Eric Burger wrote: > >> Date: Thursday, 16 May 2007, 8am ET - Noon ET > > 8 AM is particularly brutal, especially for people coming from western > time zones. Even more so since the venue is not in a hotel, so > there's extra travel time. I think 10 AM to 1 PM would be much more > sane. +1. _______________________________________________ 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 Apr 19 00:03:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeNsC-0004cF-KS; Thu, 19 Apr 2007 00:03:56 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeNsC-0004cA-5H for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 00:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeNsB-0004c2-Rs for lemonade@ietf.org; Thu, 19 Apr 2007 00:03:55 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeNsA-0000fk-KX for lemonade@ietf.org; Thu, 19 Apr 2007 00:03:55 -0400 Received: from [10.0.2.5] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Wed, 18 Apr 2007 23:03:55 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: <4C38DC11F6B4FF4FAEA73E30DB5AA1575D3A16@esebe199.NOE.Nokia.com> X-Mailer: Eudora [Macintosh version 6.3a0] Date: Wed, 18 Apr 2007 23:03:51 -0500 To: "Eric Burger" From: Pete Resnick Subject: RE: [lemonade] Interim Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: lemonade@ietf.org, 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 On 4/17/07 at 4:27 PM -0700, Eric Burger wrote: >16th / 17th; Mississauga, which is a suburb of Toronto. Except everything says 15th / 16th. You should get that fixed. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ 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 Apr 19 00:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeO6v-0000Qy-59; Thu, 19 Apr 2007 00:19:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeO6u-0000Qt-Gp for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 00:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeO6s-0000OG-GM for lemonade@ietf.org; Thu, 19 Apr 2007 00:19:07 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeO6r-0005LF-83 for lemonade@ietf.org; Thu, 19 Apr 2007 00:19:06 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 1FB88810C38; Wed, 18 Apr 2007 21:12:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 9CF57FA863; Wed, 18 Apr 2007 21:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeWu0WpAvU2o; Wed, 18 Apr 2007 21:19:04 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 890F0FA862; Wed, 18 Apr 2007 21:19:04 -0700 (PDT) Date: Wed, 18 Apr 2007 21:19:04 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <594230642.32611176956344320.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, Timo Sirainen , Cyrus Daboo , ietf-imapext@imc.org, Alexey Melnikov Subject: [lemonade] Re: ANNOTATEMORE and COMPARATOR 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 > > Is this true? Do these servers really implement i;ascii-casemap as > > defined in RFC 4790? I'd expect any RFC 3501-compliant server that > > knows about more charsets than just US-ASCII to be supporting > > i;unicode-casemap and *not* i;ascii-casemap because of > > case-insensitive "SEARCH CHARSET". > > Build some consensus please. I chatted with Arnt, and he thinks it'd be worthwhile to canvas the troops and get some hard data on what various servers actually implement for their default SEARCH comparator. I've thrown together a little 5-question survey which I'll send out under separate cover. _______________________________________________ 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 Apr 19 00:23:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeOBB-00042q-J2; Thu, 19 Apr 2007 00:23:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeOBA-00041V-Fi for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 00:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeOBA-00041N-6K for lemonade@ietf.org; Thu, 19 Apr 2007 00:23:32 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeOB9-00073k-SZ for lemonade@ietf.org; Thu, 19 Apr 2007 00:23:32 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id D8BF6810C3B; Wed, 18 Apr 2007 21:17:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 6908AFA864; Wed, 18 Apr 2007 21:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Djy+-tDvVZO3; Wed, 18 Apr 2007 21:23:29 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8258DFA863; Wed, 18 Apr 2007 21:23:29 -0700 (PDT) Date: Wed, 18 Apr 2007 21:23:29 -0700 (PDT) From: Dan Karp To: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments , IMAP Protocol Interest List Message-ID: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [75.31.46.252] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [lemonade] SURVEY: How does SEARCH match in your IMAP server? 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 We're collecting hard data to help refine an upcoming IMAP extension (http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-10.txt). If you're developing an IMAP server, it would be a *great* help if you could take 3 minutes to answer a few questions about your server implementation. If you email responses back to me along with your server's name and version, I'll compile the results. Assume that you've just injected the following message into an empty INBOX: ---------------------------------------------------------------------- Subject: Music Date: Tue, 17 Apr 2007 16:53:02 -0700 (PDT) From: user1@example.com To: user2@example.com Content-Type: text/plain; charset=3D"iso-8859-1" I love M=C3=B6tley Cr=C3=BCe ! ---------------------------------------------------------------------- For each of the following SEARCH requests, would your server match the message, not match the message, return NO [BADCHARSET], or return some other NO or BAD response? A001 SEARCH BODY "love" A002 SEARCH BODY "LOVE" A003 SEARCH CHARSET "iso-8859-1" BODY {4} Cr=C3=BCe A004 SEARCH CHARSET "utf-8" BODY {5} Cr=C3=83=C2=BCe A005 SEARCH CHARSET "iso-8859-1" BODY {4} CR=C3=9CE _______________________________________________ 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 Apr 19 01:49:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HePWf-0004Av-5K; Thu, 19 Apr 2007 01:49:49 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HePWe-0004An-Kb for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 01:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HePWe-0004Ae-5c for lemonade@ietf.org; Thu, 19 Apr 2007 01:49:48 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HePWb-0006iX-PX for lemonade@ietf.org; Thu, 19 Apr 2007 01:49:48 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3J5nf0Q022729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2007 22:49:42 -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.03) with ESMTP id l3J5ncL7018323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2007 22:49:40 -0700 Date: Wed, 18 Apr 2007 22:49:37 -0700 (PDT) From: Mark Crispin To: Dan Karp Subject: Re: [lemonade] SURVEY: How does SEARCH match in your IMAP server? In-Reply-To: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.com> Message-ID: References: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.co m> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-559819627-1176960403=:11458" Content-ID: X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.4.18.223836 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_AGE_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HIGHBITS 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SUBJ_PHRASE5 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments , IMAP Protocol Interest List 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-559819627-1176960403=:11458 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Your test examples aren't any good, because your message is in UTF-8 but=20 you have texts that are claimed to be ISO 8859-1. I will try to answer=20 what I *think* you intended. If my presumptions are wrong, then I reserve the right to change my=20 answers. On Wed, 18 Apr 2007, Dan Karp wrote: > server's name and version UW imapd, version imap-2006 series unless noted otherwise. > I love M=C3=B6tley Cr=C3=BCe ! Presumably, you mean "I love M" 0xf6 "tley Cr" 0xfc "e" > A001 SEARCH BODY "love" matches > A002 SEARCH BODY "LOVE" matches > A003 SEARCH CHARSET "iso-8859-1" BODY {4} > Cr=C3=BCe Presumably, you mean "Cr" 0xfc "e" matches in all versions since imap-4.1 error in imap-4 and earlier (10+ year old US-ASCII only version) > A004 SEARCH CHARSET "utf-8" BODY {5} > Cr=C3=83=C2=BCe Presuably, you mean "Cr" 0xc3 0xbc "e" matches in all versions since imap-4.1 error in imap-4 and earlier (10+ year old US-ASCII only version) > A005 SEARCH CHARSET "iso-8859-1" BODY {4} > CR=C3=9CE Presumably, you mean "CR" 0xdc "E" matches in imap-2006 series. does not match in earlier versions (earlier versions did i;ascii-casemap). error in imap-4 and earlier (10+ year old US-ASCII only version) -- 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. --0-559819627-1176960403=:11458 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 --0-559819627-1176960403=:11458-- From lemonade-bounces@ietf.org Thu Apr 19 07:33: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 1HeUt6-0004xo-Kw; Thu, 19 Apr 2007 07:33:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeUt5-0004xi-Sn for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 07:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeUt5-0004xa-JJ for lemonade@ietf.org; Thu, 19 Apr 2007 07:33:19 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeUt4-0007c5-7H for lemonade@ietf.org; Thu, 19 Apr 2007 07:33:19 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A2DD74AC22; Thu, 19 Apr 2007 13:33:18 +0200 (CEST) Message-Id: Date: Thu, 19 Apr 2007 13:32:48 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-05.txt References: <24445.1175935967.183759@peirce.dave.cridland.net> In-Reply-To: <24445.1175935967.183759@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Dave Cridland writes: > Just to remind people I'd really like some reviews here. I think you may have overlooked RFC 3691. There isn't a 'MUST support UNSELECT' or even a SHOULD anywhere in the document. Surely you cannot have decided against a possible dependency? 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 Thu Apr 19 08:07: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 1HeVQQ-0006BJ-4A; Thu, 19 Apr 2007 08:07:46 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeVQO-00062G-Dv for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 08:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeVQN-0005zO-W9 for lemonade@ietf.org; Thu, 19 Apr 2007 08:07:44 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeVQM-0003Tn-H9 for lemonade@ietf.org; Thu, 19 Apr 2007 08:07:43 -0400 Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HeVQL-0004FM-Em; Thu, 19 Apr 2007 14:07:41 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx8.uio.no) by mail-mx8.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HeVQL-0004yV-0l; Thu, 19 Apr 2007 14:07:41 +0200 Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx8.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from ) id 1HeVQK-0004xQ-Ro; Thu, 19 Apr 2007 14:07:40 +0200 Subject: Re: [lemonade] Re: WGLC 2192 bis From: Kjetil Torgrim Homme To: Alexey Melnikov In-Reply-To: <46261729.1080009@isode.com> References: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> <46261729.1080009@isode.com> Content-Type: text/plain Date: Thu, 19 Apr 2007 14:07:34 +0200 Message-Id: <1176984454.17733.47.camel@havhest.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.8, required=12.0, autolearn=disabled, AWL=0.151, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: A4965F326A69A91EE57D8FBE157407D2403C85F8 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -47 maxlevel 200 minaction 2 bait 0 mail/h: 288 total 1187818 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: lemonade@ietf.org 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 Wed, 2007-04-18 at 14:03 +0100, Alexey Melnikov wrote: > Kjetil Torgrim Homme wrote: > >sorry if I missed previous discussion, but I think it should say > >something explicit about STARTTLS, ie., something like the client > >SHOULD issue STARTTLS before authenticating if the server supports it. > >this may require the examples to be reworked, since it essentially > >means you *always* have to do CAPABILITY. > > Fair enough. Can you suggest specific text to be added? after thinking a little more about it, I've concluded that anonymous access doesn't need encryption since access is wide open anyway, so we shouldn't encourage "wastefulness". how about this? after this paragrah: If no user name or authentication mechanism is supplied, the client must authenticate as anonymous to the server. [...] new text: For non-anonymous accesses, the client SHOULD issue STARTTLS before authenticating if the server has the capability. <> I'm not sure we need the clarification for anonymous access. with the above text, only Example 3 needs to add a CAPABILITY command. > >if this is unacceptable, I > >think we need a syntax in the URL to make TLS required -- I don't feel > >comfortable that messages may start getting sent unencrypted just > >because a server upgrade added support for DIGESTMD5 in addition to > >good old PLAIN... > > I was thinking about adding such syntactic element myself. I would like > to hear other opinions on this before proceeding. it seems awkward, and unnecessary with the above addition. it is really the responsibility of the server to provide sufficient protection for the data it hands out, the client can't really enforce it. > >on a similar note, should something be said about the special case > >which is port 993? > > No, this document doesn't describe imaps. ah, of course. -- Kjetil T. _______________________________________________ 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 Apr 19 08:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeVXL-0006EE-Je; Thu, 19 Apr 2007 08:14:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeVXK-0006E9-As for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 08:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeVXK-0006Dx-1F for lemonade@ietf.org; Thu, 19 Apr 2007 08:14:54 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeVXF-0004d9-Ak for lemonade@ietf.org; Thu, 19 Apr 2007 08:14:52 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id AEE954AC22; Thu, 19 Apr 2007 14:14:49 +0200 (CEST) Message-Id: Date: Thu, 19 Apr 2007 14:14:19 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-05.txt References: <24445.1175935967.183759@peirce.dave.cridland.net> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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 One more thing. The profile-bis abstract doesn't say what makes this different from profile. Shouldn't there be a sentence of two saying why profile-bis exists, what profile-bis clients can do that profile clients can't (or can do better), etc? 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 Thu Apr 19 09:42: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 1HeWu9-0002A3-V2; Thu, 19 Apr 2007 09:42:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeWu9-00029v-H5 for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 09:42:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWu9-00029n-7V; Thu, 19 Apr 2007 09:42:33 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeWu7-0002ev-E6; Thu, 19 Apr 2007 09:42:33 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JDgRUx026057; Thu, 19 Apr 2007 06:42:27 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JDfxk1021383; Thu, 19 Apr 2007 06:42:26 -0700 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: 7bit Date: Thu, 19 Apr 2007 06:42:30 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CORRECTED DATES: IETF LEMONADE Interim Meeting Thread-Index: AceCexFk8cVnAys3TBmQiSaR3plsTQ== From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ietf-announce@ietf.org Subject: [lemonade] CORRECTED DATES: IETF LEMONADE Interim Meeting 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 NOTE: I got the days of the week right, but the dates wrong. The interim will be the 16th and 17th of May. That is still Wednesday and Thursday. The times of the second day (Thursday) is subject to change, due to popular demand. IETF LEMONADE Interim Meeting ============================= Logistics --------- Date: Wednesday, 16 May 2007, Noon ET - 5pm ET Date: Thursday, 17 May 2007, 8am ET - Noon ET Venue: BEA Systems Ltd. 2425 Matheson Blvd. East 7th Floor Mississauga (Toronto), ON L4W 5K4 Canada +1.905.361.2850 phone Remote Access: o High-Speed Internet o Conference Bridge o Jabber o iChat Proposed Agenda --------------- Editor sessions / discussions on: - IMAP CONVERT - Quick resync - IMAP Streaming - IMAP SIEVE - Notifications and filters If not done, then: - WITHIN - IMAP URL bis And, of course: - Profile bis 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 Apr 19 09:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWwP-0005fb-1h; Thu, 19 Apr 2007 09:44:53 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeWwN-0005fQ-RA for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 09:44:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWwN-0005fI-Ha; Thu, 19 Apr 2007 09:44:51 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeWwM-0003A9-5M; Thu, 19 Apr 2007 09:44:51 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JDim4W028465; Thu, 19 Apr 2007 06:44:48 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JDijff021016; Thu, 19 Apr 2007 06:44:46 -0700 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: 7bit Subject: RE: [lemonade] LEMONADE Interim Agenda and Venue Date: Thu, 19 Apr 2007 06:43:18 -0700 Message-ID: In-Reply-To: <462642F7.5000507@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE Interim Agenda and Venue Thread-Index: AceB1HaJsWqXA8ztSui9q9QBuUQnyQAp07/Q References: <462642F7.5000507@isode.com> From: "Eric Burger" To: "Alexey Melnikov" , "Randall Gellens" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org, ietf-announce@ietf.org 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 I'm all for a later start time. How about this: check your return flight options to bound how late we can go. Tell me and we'll work in four hours up to when you would need to leave. If everyone gets 3pm flights, we start early. If everyone gets 6pm flights, or are staying the evening, then we start later. -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: Wednesday, April 18, 2007 12:11 PM To: Randall Gellens Cc: Eric Burger; chris newman; lemonade@ietf.org; ietf-announce@ietf.org; Glenn Parsons Subject: Re: [lemonade] LEMONADE Interim Agenda and Venue Randall Gellens wrote: > At 8:08 PM -0700 4/16/07, Eric Burger wrote: > >> Date: Thursday, 16 May 2007, 8am ET - Noon ET > > 8 AM is particularly brutal, especially for people coming from western > time zones. Even more so since the venue is not in a hotel, so > there's extra travel time. I think 10 AM to 1 PM would be much more > sane. +1. 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 Apr 19 11:08: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 1HeYF8-0007QZ-PU; Thu, 19 Apr 2007 11:08:18 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeYF8-0007QU-0e for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 11:08:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYF7-0007QM-NO for lemonade@ietf.org; Thu, 19 Apr 2007 11:08:17 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYF5-0002d9-TA for lemonade@ietf.org; Thu, 19 Apr 2007 11:08:17 -0400 Received: from [192.168.123.102] (71-212-236-159.hlrn.qwest.net [71.212.236.159]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l3JFAnIg025216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2007 08:10:54 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l3JFAnIg025216 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1176995457; bh=Fg2ajgKPzwJgWVXBc3Bxy+B40Rg=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=IMnwWrO8o97TJYn9 h4Ol3bRzmTObOOBHtHmt+beUK0Rem2jU2qG+JuQmD3dqDEG2gXD+KX6vHrggrhQ447X sBs/mkPdivP6kFhU0oXSwK2rSq8mlVfCAEFGPINTMJhJKMCDMtwASL3HbktX2aN///i IpIE49Xmr9EvOS2aRZc18= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l3JFAnIg025216 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=jn+Sb1IFp4orXOFCnEevndgfBg8ouVxz26b59jzjU78ooex9AP/dW9gnAFQmgdVOA tC51/lRCwVzCAfd9QarCv1Vz1xN/qzc1RVRJjOwThBGqIGahheB0KIt6zgydOzwVyol PmfB2ZhOQyVZw9UUnRBx945a/G+J0ZryRXfO0+M= Date: Thu, 19 Apr 2007 09:07:54 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Kjetil Torgrim Homme Subject: Re: [lemonade] Re: WGLC 2192 bis In-Reply-To: <1176984454.17733.47.camel@havhest.ifi.uio.no> Message-ID: References: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> <46261729.1080009@isode.com> <1176984454.17733.47.camel@havhest.ifi.uio.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org, 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 Thu, 19 Apr 2007, Kjetil Torgrim Homme wrote: ... > after thinking a little more about it, I've concluded that anonymous > access doesn't need encryption since access is wide open anyway, so we > shouldn't encourage "wastefulness". how about this? While confidentiality may not be needed, integrity may be important. Negotiating TLS is the only way to get that for anonymous access. Isn't integrity-only protection what the WITH_NULL cipher suites (TLS_RSA_WITH_NULL_SHA, TLS_RSA_WITH_NULL_MD5) are for? (Mind you, there may be no server implementations that offer those suites without manual configuration, given that at least OpenSSL disables them by default...) Philip Guenther _______________________________________________ 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 Apr 19 12:16:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZIl-00024u-Rx; Thu, 19 Apr 2007 12:16:07 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeZIl-00024p-BF for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 12:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZIl-00024h-1m for lemonade@ietf.org; Thu, 19 Apr 2007 12:16:07 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZIj-0005dK-MU for lemonade@ietf.org; Thu, 19 Apr 2007 12:16:07 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3JGG2Wt015966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Apr 2007 09:16:03 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-101.qualcomm.com [10.50.16.101]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3JGG04c017711; Thu, 19 Apr 2007 09:16:00 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <462642F7.5000507@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 19 Apr 2007 09:10:51 -0700 To: "Eric Burger" , "Alexey Melnikov" , "Randall Gellens" From: Randall Gellens Subject: RE: [lemonade] LEMONADE Interim Agenda and Venue 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: lemonade@ietf.org 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 6:43 AM -0700 4/19/07, Eric Burger wrote: > I'm all for a later start time. How about this: check your return > flight options to bound how late we can go. Tell me and we'll work in > four hours up to when you would need to leave. If everyone gets 3pm > flights, we start early. If everyone gets 6pm flights, or are staying > the evening, then we start later. I thought the meeting location is very close to the airport. I was planning on a 2:40 PM flight with the noon stop time, figuring it would take only a few minutes to get to the airport. Is that unrealistic? If we stop at 1 PM, I was going to take the 3:30 flight. if we go later, I can take flights at 3:30, 4:30, 6:10, 6:30, or 6:40. Is a 4-hour window needed? I was thinking 2 hours 30 minutes would suffice. > > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Wednesday, April 18, 2007 12:11 PM > To: Randall Gellens > Cc: Eric Burger; chris newman; lemonade@ietf.org; > ietf-announce@ietf.org; Glenn Parsons > Subject: Re: [lemonade] LEMONADE Interim Agenda and Venue > > Randall Gellens wrote: > >> At 8:08 PM -0700 4/16/07, Eric Burger wrote: >> >>> Date: Thursday, 16 May 2007, 8am ET - Noon ET >> >> 8 AM is particularly brutal, especially for people coming from western > >> time zones. Even more so since the venue is not in a hotel, so >> there's extra travel time. I think 10 AM to 1 PM would be much more >> sane. > > +1. > > > 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. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is easier to fight for one's principles than to live up to them. --Alfred Adler _______________________________________________ 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 Apr 19 12:49: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 1HeZpK-0003f6-Em; Thu, 19 Apr 2007 12:49:46 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeZpI-0003f1-BZ for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 12:49:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZpI-0003et-29 for lemonade@ietf.org; Thu, 19 Apr 2007 12:49:44 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZpF-00086Q-N5 for lemonade@ietf.org; Thu, 19 Apr 2007 12:49:44 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JGnf0O012390 for ; Thu, 19 Apr 2007 16:49:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGR002017YBLS00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Thu, 19 Apr 2007 10:49:41 -0600 (MDT) Received: from [10.0.1.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR003GT82PCE10@mail-amer.sun.com>; Thu, 19 Apr 2007 10:49:41 -0600 (MDT) Date: Thu, 19 Apr 2007 09:50:08 -0700 From: Chris Newman To: arnt@oryx.com, rjs3+@andrew.cmu.edu, Lemonade WG Message-id: <9E7DA3932AE1DAEF71AF3DB7@[10.0.1.21]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Tim Polk Subject: [lemonade] draft-siemborski-imap-sasl-initial-response 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 During discussion of this document, Tim Polk raised the issue that there is no way for IMAP to distinguish between authentication errors that lead to different client UI behaviors (akin to RFC 3206). I agree with his concern but felt the problem is with the IMAP base specification, and this document does not change the situation. So we're not blocking this document. However, I would like someone from the IMAP community to do an individual submission with status codes for the IMAP server to at least distinguish service failures from a mistyped password. This can reduce service calls which I'm sure is a concern for customers of the lemonade WG. Text could be lifted from: although I recommend a less ambitious approach (akin to RFC 3206) so it gets completed this time :-). Volunteers? - Chris Newman Applications Area Director _______________________________________________ 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 Apr 19 13:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hea2q-0004jq-SJ; Thu, 19 Apr 2007 13:03:44 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hea2p-0004Z2-Bw for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 13:03:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hea2o-0004V1-Tq for lemonade@ietf.org; Thu, 19 Apr 2007 13:03:42 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hea2n-0005hX-HT for lemonade@ietf.org; Thu, 19 Apr 2007 13:03:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3JH3eVL024857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2007 10:03:40 -0700 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3JH3bmE026357 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Apr 2007 10:03:39 -0700 Date: Thu, 19 Apr 2007 10:03:31 -0700 From: Mark Crispin To: Chris Newman Subject: Re: [lemonade] draft-siemborski-imap-sasl-initial-response In-Reply-To: <9E7DA3932AE1DAEF71AF3DB7@[10.0.1.21]> Message-ID: References: <9E7DA3932AE1DAEF71AF3DB7@[10.0.1.21]> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.4.19.95334 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Lemonade WG , Tim Polk , rjs3+@andrew.cmu.edu 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 Thu, 19 Apr 2007, Chris Newman wrote: > However, I would like someone from the IMAP community to do an individual > submission with status codes for the IMAP server to at least distinguish > service failures from a mistyped password. This can reduce service calls > which I'm sure is a concern for customers of the lemonade WG. What a can of worms this opens! We do need to distinguish between "service failures" vs. "authentication failure and this is what you need to do to fix it" vs. "we don't like the authentication", since in the latter case we may wish to be somewhat tight-lipped as to the reason (e.g., "too many failures in too short a time from your IP address"). For password expiration (which presumably should be disclosed to the user), wouldn't the ALERT mechanism is more suitable since clients may disregard status codes? That's what we use. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ 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 Apr 19 13:17:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaG7-0002LH-9j; Thu, 19 Apr 2007 13:17:27 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeaG6-0002KR-Bt for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 13:17:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaG6-0002KJ-2M for lemonade@ietf.org; Thu, 19 Apr 2007 13:17:26 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeaG4-0000Sf-Lq for lemonade@ietf.org; Thu, 19 Apr 2007 13:17:26 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 246BC4AC22; Thu, 19 Apr 2007 19:17:25 +0200 (CEST) Message-Id: Date: Thu, 19 Apr 2007 19:16:55 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <9E7DA3932AE1DAEF71AF3DB7@[10.0.1.21]> In-Reply-To: <9E7DA3932AE1DAEF71AF3DB7@[10.0.1.21]> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: rjs3+@andrew.cmu.edu, Chris Newman , Tim Polk Subject: [lemonade] Re: draft-siemborski-imap-sasl-initial-response 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 Chris Newman writes: > However, I would like someone from the IMAP community to do an > individual submission with status codes for the IMAP server to at > least distinguish service failures from a mistyped password. This > can reduce service calls which I'm sure is a concern for customers of > the lemonade WG. I would be happy to do that. I've wanted that for a long time (at least if what you mean is what I want). 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 Thu Apr 19 14:57:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heboj-0007F2-RK; Thu, 19 Apr 2007 14:57:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Heboh-0007El-Qj for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 14:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heboh-0007EV-Gb for lemonade@ietf.org; Thu, 19 Apr 2007 14:57:15 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hebod-0007Ra-7x for lemonade@ietf.org; Thu, 19 Apr 2007 14:57:15 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39267) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Hebnf-0003SZ-T6 (Exim 4.63) for lemonade@ietf.org (return-path ); Thu, 19 Apr 2007 19:56:11 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hebne-0002bK-W6 (Exim 4.54) for lemonade@ietf.org (return-path ); Thu, 19 Apr 2007 19:56:10 +0100 Date: Thu, 19 Apr 2007 19:56:10 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [lemonade] QUICKSTART update 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 draft-fanf-smtp-quickstart-a-00 and draft-fanf-smtp-quickstart-b-00 have been published. I've separated it into two documents to make the two different profiles clearer. I prefer the -B profile but I'd like opinions from others about the trade-off between complexity and effectiveness. Tony. -- f.a.n.finch http://dotat.at/ SHANNON: SOUTHWEST BACKING SOUTHEAST 3 OR 4. MODERATE BECOMING SLIGHT. FAIR. MODERATE OR GOOD. _______________________________________________ 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 Apr 19 17:42:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeO6-00039S-5u; Thu, 19 Apr 2007 17:41:58 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HeeO5-00039N-GB for lemonade-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 17:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeO5-00039F-6Y for lemonade@ietf.org; Thu, 19 Apr 2007 17:41:57 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeeO3-0007l8-Os for lemonade@ietf.org; Thu, 19 Apr 2007 17:41:57 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JLfs2S002958; Thu, 19 Apr 2007 14:41:54 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JLfqsT015643; Thu, 19 Apr 2007 14:41:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [lemonade] LEMONADE Interim Agenda and Venue Date: Thu, 19 Apr 2007 14:42:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE Interim Agenda and Venue Thread-Index: AceCnhkLV9113ikxSae+YvPX+GFIjQALX9WM From: "Eric Burger" To: , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: lemonade@ietf.org 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 No - you are correct, we are that close to the airport. I'll wait for more input from the list, but it sounds like 10am will be the start time. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. -----Original Message----- From: Randall Gellens To: Eric Burger; Alexey Melnikov ; Randall Gellens CC: lemonade@ietf.org Sent: Thu Apr 19 09:10:51 2007 Subject: RE: [lemonade] LEMONADE Interim Agenda and Venue At 6:43 AM -0700 4/19/07, Eric Burger wrote: > I'm all for a later start time. How about this: check your return > flight options to bound how late we can go. Tell me and we'll work in > four hours up to when you would need to leave. If everyone gets 3pm > flights, we start early. If everyone gets 6pm flights, or are staying > the evening, then we start later. I thought the meeting location is very close to the airport. I was planning on a 2:40 PM flight with the noon stop time, figuring it would take only a few minutes to get to the airport. Is that unrealistic? If we stop at 1 PM, I was going to take the 3:30 flight. if we go later, I can take flights at 3:30, 4:30, 6:10, 6:30, or 6:40. Is a 4-hour window needed? I was thinking 2 hours 30 minutes would suffice. > > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Wednesday, April 18, 2007 12:11 PM > To: Randall Gellens > Cc: Eric Burger; chris newman; lemonade@ietf.org; > ietf-announce@ietf.org; Glenn Parsons > Subject: Re: [lemonade] LEMONADE Interim Agenda and Venue > > Randall Gellens wrote: > >> At 8:08 PM -0700 4/16/07, Eric Burger wrote: >> >>> Date: Thursday, 16 May 2007, 8am ET - Noon ET >> >> 8 AM is particularly brutal, especially for people coming from western > >> time zones. Even more so since the venue is not in a hotel, so >> there's extra travel time. I think 10 AM to 1 PM would be much more >> sane. > > +1. > > > 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. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is easier to fight for one's principles than to live up to them. --Alfred Adler 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 Fri Apr 20 17:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0HU-00037o-D0; Fri, 20 Apr 2007 17:04:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hf0HS-00037f-VK for lemonade-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 17:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0HS-00037T-EN; Fri, 20 Apr 2007 17:04:34 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0HQ-00046x-IV; Fri, 20 Apr 2007 17:04:34 -0400 Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3KL4WvF013229; Fri, 20 Apr 2007 21:04:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGT00201EFXXP00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM); Fri, 20 Apr 2007 15:04:32 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGT00ILJEJGDB10@mail-amer.sun.com>; Fri, 20 Apr 2007 15:04:30 -0600 (MDT) Date: Fri, 20 Apr 2007 14:05:00 -0700 From: Chris Newman To: Eric Burger , lemonade@ietf.org Message-id: <5F0DC28223ADA886202018C6@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ietf-announce@ietf.org Subject: [lemonade] Re: CORRECTED DATES: IETF LEMONADE Interim Meeting 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 official IETF working group procedures (BCP 25, RFC 2418) states: "Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings." The IESG interpretation of this rule as it applies to interim meetings is here: Due to the confusion with the dates, it's not clear a full month advance notice was provided for this interim. However, I do not believe this was willful or harmful to open participation (especially because the lemonade WG has a history of regular productive interim WG meetings) so I am approving this interim. If anyone feels strongly that insufficient advance notification was provided, please speak up now. - Chris Newman Applications Area Director Eric Burger wrote on 4/19/07 6:42 AM -0700: > NOTE: I got the days of the week right, but the dates wrong. The > interim will be the 16th and 17th of May. That is still Wednesday and > Thursday. The times of the second day (Thursday) is subject to change, > due to popular demand. > > > IETF LEMONADE Interim Meeting > ============================= > > > Logistics > --------- > Date: Wednesday, 16 May 2007, Noon ET - 5pm ET > Date: Thursday, 17 May 2007, 8am ET - Noon ET > > Venue: > BEA Systems Ltd. > 2425 Matheson Blvd. East > 7th Floor > Mississauga (Toronto), ON L4W 5K4 > Canada > > +1.905.361.2850 phone > > > Remote Access: > o High-Speed Internet > o Conference Bridge > o Jabber > o iChat > > > > Proposed Agenda > --------------- > Editor sessions / discussions on: > - IMAP CONVERT > - Quick resync > - IMAP Streaming > - IMAP SIEVE > - Notifications and filters > > If not done, then: > - WITHIN > - IMAP URL bis > > And, of course: > - Profile bis > > 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. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ 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 Apr 20 20:29:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf3Ty-0006Xe-5p; Fri, 20 Apr 2007 20:29:42 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hf3Tw-0006XW-N4 for lemonade-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 20:29:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf3Tw-0006XO-DS for lemonade@ietf.org; Fri, 20 Apr 2007 20:29:40 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf3Tu-00075C-VB for lemonade@ietf.org; Fri, 20 Apr 2007 20:29:40 -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 l3L0TbTP005012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Apr 2007 17:29:38 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3L0TaEv026347; Fri, 20 Apr 2007 17:29:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 20 Apr 2007 17:28:00 -0700 To: Alexey Melnikov , lemonade@ietf.org From: Randall Gellens 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: f884eb1d4ec5a230688d7edc526ea665 Cc: Subject: [lemonade] Comments on draft-ietf-lemonade-convert-06.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 ---------- Section 1: OLD: This document defines the CONVERT extension to IMAP4 [RFC3501]. It defines additional enhancements for optimization in a mobile setting: extensions to the IMAP4Rev1 protocol [RFC3501] that allows adaptation and transcoding of body parts as needed by the client. NEW: This document defines the CONVERT extension to IMAP4 [RFC3501]. CONVERT provides adaptation and transcoding of body parts as needed by the client. This is primarily intended to be useful to mobile clients. ---------- Section 4.2: OLD: Such annotation would contain a "value.shared" attribute, which is a semicolon separated list of output formats. NEW: The "value.shared" attribute of this annotation contains a semicolon separated list of type/subtype output formats. ---------- OLD: Note that a special annotation named "/convert//@/types" can be used to reference any subtype of media type. NEW: In addition to the subtype-specific annotations, a special "wildcard" annotation named "/convert//@/types" MAY be used to reference any subtype of media type. ---------- OLD: "/convert/sourcetype/destinationtype/params" annotation. NEW: "/convert/////params" annotation. ---------- OLD: or it may present the parameters as a GUI NEW: or it might, for example, present the parameters as a GUI (avoid confusion with normative words) ---------- OLD: parameter names should be standardized NEW: parameter names is expected to be standardized (just a guess, but the "should" is confusing") Also, do we want to perhaps reference RFC 2912 here? ---------- Section 5: OLD: The CONVERT extension defines a FETCH extension NEW: CONVERT defines a FETCH extension ---------- OLD: same media type, with different encoding parameters. NEW: same media type with different encoding parameters. (delete comma as it is confusing) ---------- OLD: also expected to work with IMAP BINARY data item extension NEW: also expected to work with the IMAP BINARY data item extension ---------- OLD: Each request for BODY or BINARY FETCH data item NEW: Each request for a BODY or BINARY FETCH data item ---------- OLD: the client can use a special marker NIL NEW: the client MAY use a special marker NIL ---------- OLD: Note that support for such "default conversion" request is OPTIONAL in servers. NEW: Note that support for such "default conversion" requests is OPTIONAL in servers. Also, how does the client discover if the server provides such support? I think that the only use in providing this default conversion is to support very simple clients. Thus, it doesn't make sense to make this an option for servers, since the very clients that might need it might also be too simple to have multiple code paths to handle it not being available, and anyway, what is the client to do? If we are going to include default conversions, I think they should be mandatory for servers. How the server decides remains out of scope, and we aren't requiring the server to make good choices (that's a quality-of-implementation thing), but this can't be an option. It also doesn't seem to be any more of a burden to require the server to pick something if it is going to support something. ---------- Section 6: OLD: they may decline to honor some requests NEW: they MAY decline to honor some requests Also, should we say anything here about how the server declines? That is, what does it send to the client? Some other charset, a NO response, a rude insult? ---------- Section 6.1.1: Do we really want to say SHOULD for text/html to text/plain? Is this actually useful for any mobile device that can support IMAP? I wonder if text/plain to text/html wouldn't be just as useful? (it is easier to implement). ---------- OLD: formats like proprietary document formats NEW: formats such as proprietary document formats ---------- Section 8: OLD: the server can reply NEW: the server MAY reply Do we want to say what the other server choices are? Use some default values of its choosing? ---------- OLD: malformed MIME types may also generate NEW: malformed MIME types MAY also generate ---------- OLD: (e.g. internal error NEW: (e.g., internal error ---------- OLD: NO response should be returned NEW: NO response SHOULD be returned But why is this a SHOULD? What are the server's other choices? The next paragraph says to use NO for permanent errors. I agree it would be helpful to let the client know if the error is permanent or temporary, so the client knows to retry later or not. Something like "NO [TEMPFAIL]", or an additional TEMPFAIL extension response code later in the section? ---------- OLD: Otherwise, the server should return an OK response NEW: Otherwise, the server SHOULD return an OK response ---------- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Deja Moo: The feeling that you've heard this bull before. _______________________________________________ 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 Apr 23 19:39: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 1Hg87c-0001b8-6n; Mon, 23 Apr 2007 19:39:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg87a-0001aN-8u for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 19:39:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87Z-0001aB-U8 for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:01 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg87Z-0004rR-Hd for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:01 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcxdW032681; Mon, 23 Apr 2007 16:38:59 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcrTI010046; Mon, 23 Apr 2007 16:38:58 -0700 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: 7bit Subject: Security Considerations (was RE: [lemonade] WGLC streaming) Date: Mon, 23 Apr 2007 16:39:25 -0700 Message-ID: In-Reply-To: <35A5A4A1-D3ED-41EE-A521-1C3C95AA885A@noware.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security Considerations (was RE: [lemonade] WGLC streaming) Thread-Index: AcdyDSs3YH3tB1ZJRuaTV3tcJUg3wAT0DFwQ References: <4608EF81.5050401@isode.com><6000.1175008017.686117@peirce.dave.cridland.net> <35A5A4A1-D3ED-41EE-A521-1C3C95AA885A@noware.co.uk> From: "Eric Burger" To: "Neil Cook" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org 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 Security Considerations section is a special section. There are quite a few people that will review the Security Considerations section first, and then give a cursory glance over the rest of the document. For example, we ask the security directorate to review the document. You can guess where they are going to look first. Thus it is a good idea when writing your security considerations that you include explanatory text and references, as if it was an introduction. This is a bit like the passive voice issue discussed elsewhere. When we write a document, we think of it as a whole, from front to back. When we write the security considerations section, it is often after we have written everything else. Thus we are thinking of the security considerations section in the context of the whole document, read last. However, given we know there are constituencies that will read the document starting with the security considerations section, we need to go out of our way to make it stand on its own. -----Original Message----- From: Neil Cook [mailto:neil.cook@noware.co.uk] Sent: Thursday, March 29, 2007 10:18 AM To: Dave Cridland Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] WGLC streaming [snip] > In the Security Considerations section, there seems to be a sudden > lack of references. In particular, sips, SIP, RFC4240, RFC4722, and > S/MIME all lack references (although they're in the Normative > References section). I have been in somewhat of a quandry about that. Do I reference *everytime* I mention another standard? I got the feeling that by the end of the doc, if various protocols have been referenced enough, they probably don't need any more, but I'd be happy to be corrected on that. Obviously any in that section which haven't been referenced before should be referenced. [snip] 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 Apr 23 19:39: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 1Hg87Z-0001aA-Uj; Mon, 23 Apr 2007 19:39:01 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg87Y-0001Zz-O7 for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 19:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87Y-0001Zr-EM for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:00 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg87W-0004rD-VA for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:00 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcuNm032664; Mon, 23 Apr 2007 16:38:57 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcrTE010046; Mon, 23 Apr 2007 16:38:55 -0700 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: 7bit Subject: RE: [lemonade] Open Issues with IMAP CONVERT Date: Mon, 23 Apr 2007 16:39:22 -0700 Message-ID: In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA15753C41E@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Open Issues with IMAP CONVERT Thread-Index: Acd8J6JuJ6CU3vRfRfOGwAjoSQWADAArwlpwAkCJjTA= References: <460A7A38.5000304@isode.com><4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com><460BDBF9.9040901@isode.com><4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com><461BF349.7080903@isode.com><6701.1176288664.449163@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA15753C41E@esebe199.NOE.Nokia.com> From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: lemonade@ietf.org 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 I still do not see the use case. Humans are in the loop and will notice garbage in the message. Vendors of conversion tools will learn when to give up, as in the example below which will at best result in a checker-board or, more likely, a 32x32 black square. The parameters for when to give up and just say, "I cannot convert this for you" is way beyond our charter and expertise. We only need to provide the mechanism for specifying how to signal the inability to convert something because the converter knows the result will be useless. Likewise, VIRTUALLY ALL conversions will be lossy; that is what the user is asking for! If anything, it may be academically interesting to note that the conversion was lossless. Thus, I would offer either we do a conversion, indicate we cannot do a conversion, or indicate the results of the conversion would be useless. -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] Sent: Thursday, April 12, 2007 4:10 AM To: dave@cridland.net; lemonade@ietf.org Subject: RE: [lemonade] Open Issues with IMAP CONVERT Hi Dave, I added some responses below. >>> Can we take a moment and think about why we need this? >>> I mean I am not sure that we need this: >>> - Probably no client will upscale->no loss. >>> - Most clients will downscale -> there is always loss. >>> - Some clients might use format/size conversions-> If >client requests >>> explicit conversion, it should be aware that there might be loss, >>> while if the client left the conversion choice up to the server, it >>> should assume that there was a loss. >>> >>> What do You think? >>> >> Hi Zoltan, >> You are making convincing arguments for dropping the response code. >> >> Would anybody like to defend why the INFORMATIONLOSS is needed? > >Well, I'm not convinced it's needed, but I'll advance an argument. > >Let's assume that a client has very limited capability for character >sets. A message arrives in, say, Japanese, and the client requests a >conversion of the textual message to ASCII. >Severe information loss will take place, and the user almost certainly >needs to know that this is the case. I suppose in this case the conversion shoud fail because there is no way to convert Japanese to ASCII. >Conversly, it may well be useful to know that the converted body part >has been losslessly transcoded under some circumstances. Let's suppose >an audio part arrives, and the user wishes to listen to it - if the >converted part is unintelligible, but the part has been losslessly >converted, it would be reasonable for the user to reply with a message >saying so. However, if the process of conversion is responsible for the >problem, then the user might either wish to wait until they are at a >more capable client, or else reply asking for a different format. Could You provide a use case for this: the process of conversion is responsible for creating unintelligible content. I was thinking something like: You receive a large image (1600*1200), and Your client requests coverting it to a server-selected size (and server picks 32*32). But then I realized that in this case the culprit is not the process of conversion. It is the server for picking an extremently low resolution - instead of creating unintelligible content, the server should fail this request instead. _______________________________________________ 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 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 Apr 23 19:39: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 1Hg87c-0001b8-6n; Mon, 23 Apr 2007 19:39:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg87a-0001aN-8u for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 19:39:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87Z-0001aB-U8 for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:01 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg87Z-0004rR-Hd for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:01 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcxdW032681; Mon, 23 Apr 2007 16:38:59 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcrTI010046; Mon, 23 Apr 2007 16:38:58 -0700 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: 7bit Subject: Security Considerations (was RE: [lemonade] WGLC streaming) Date: Mon, 23 Apr 2007 16:39:25 -0700 Message-ID: In-Reply-To: <35A5A4A1-D3ED-41EE-A521-1C3C95AA885A@noware.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security Considerations (was RE: [lemonade] WGLC streaming) Thread-Index: AcdyDSs3YH3tB1ZJRuaTV3tcJUg3wAT0DFwQ References: <4608EF81.5050401@isode.com><6000.1175008017.686117@peirce.dave.cridland.net> <35A5A4A1-D3ED-41EE-A521-1C3C95AA885A@noware.co.uk> From: "Eric Burger" To: "Neil Cook" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org 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 Security Considerations section is a special section. There are quite a few people that will review the Security Considerations section first, and then give a cursory glance over the rest of the document. For example, we ask the security directorate to review the document. You can guess where they are going to look first. Thus it is a good idea when writing your security considerations that you include explanatory text and references, as if it was an introduction. This is a bit like the passive voice issue discussed elsewhere. When we write a document, we think of it as a whole, from front to back. When we write the security considerations section, it is often after we have written everything else. Thus we are thinking of the security considerations section in the context of the whole document, read last. However, given we know there are constituencies that will read the document starting with the security considerations section, we need to go out of our way to make it stand on its own. -----Original Message----- From: Neil Cook [mailto:neil.cook@noware.co.uk] Sent: Thursday, March 29, 2007 10:18 AM To: Dave Cridland Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] WGLC streaming [snip] > In the Security Considerations section, there seems to be a sudden > lack of references. In particular, sips, SIP, RFC4240, RFC4722, and > S/MIME all lack references (although they're in the Normative > References section). I have been in somewhat of a quandry about that. Do I reference *everytime* I mention another standard? I got the feeling that by the end of the doc, if various protocols have been referenced enough, they probably don't need any more, but I'd be happy to be corrected on that. Obviously any in that section which haven't been referenced before should be referenced. [snip] 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 Apr 23 19:39: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 1Hg87Z-0001aA-Uj; Mon, 23 Apr 2007 19:39:01 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg87Y-0001Zz-O7 for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 19:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87Y-0001Zr-EM for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:00 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg87W-0004rD-VA for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:00 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcuNm032664; Mon, 23 Apr 2007 16:38:57 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcrTE010046; Mon, 23 Apr 2007 16:38:55 -0700 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: 7bit Subject: RE: [lemonade] Open Issues with IMAP CONVERT Date: Mon, 23 Apr 2007 16:39:22 -0700 Message-ID: In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA15753C41E@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Open Issues with IMAP CONVERT Thread-Index: Acd8J6JuJ6CU3vRfRfOGwAjoSQWADAArwlpwAkCJjTA= References: <460A7A38.5000304@isode.com><4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com><460BDBF9.9040901@isode.com><4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com><461BF349.7080903@isode.com><6701.1176288664.449163@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA15753C41E@esebe199.NOE.Nokia.com> From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: lemonade@ietf.org 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 I still do not see the use case. Humans are in the loop and will notice garbage in the message. Vendors of conversion tools will learn when to give up, as in the example below which will at best result in a checker-board or, more likely, a 32x32 black square. The parameters for when to give up and just say, "I cannot convert this for you" is way beyond our charter and expertise. We only need to provide the mechanism for specifying how to signal the inability to convert something because the converter knows the result will be useless. Likewise, VIRTUALLY ALL conversions will be lossy; that is what the user is asking for! If anything, it may be academically interesting to note that the conversion was lossless. Thus, I would offer either we do a conversion, indicate we cannot do a conversion, or indicate the results of the conversion would be useless. -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] Sent: Thursday, April 12, 2007 4:10 AM To: dave@cridland.net; lemonade@ietf.org Subject: RE: [lemonade] Open Issues with IMAP CONVERT Hi Dave, I added some responses below. >>> Can we take a moment and think about why we need this? >>> I mean I am not sure that we need this: >>> - Probably no client will upscale->no loss. >>> - Most clients will downscale -> there is always loss. >>> - Some clients might use format/size conversions-> If >client requests >>> explicit conversion, it should be aware that there might be loss, >>> while if the client left the conversion choice up to the server, it >>> should assume that there was a loss. >>> >>> What do You think? >>> >> Hi Zoltan, >> You are making convincing arguments for dropping the response code. >> >> Would anybody like to defend why the INFORMATIONLOSS is needed? > >Well, I'm not convinced it's needed, but I'll advance an argument. > >Let's assume that a client has very limited capability for character >sets. A message arrives in, say, Japanese, and the client requests a >conversion of the textual message to ASCII. >Severe information loss will take place, and the user almost certainly >needs to know that this is the case. I suppose in this case the conversion shoud fail because there is no way to convert Japanese to ASCII. >Conversly, it may well be useful to know that the converted body part >has been losslessly transcoded under some circumstances. Let's suppose >an audio part arrives, and the user wishes to listen to it - if the >converted part is unintelligible, but the part has been losslessly >converted, it would be reasonable for the user to reply with a message >saying so. However, if the process of conversion is responsible for the >problem, then the user might either wish to wait until they are at a >more capable client, or else reply asking for a different format. Could You provide a use case for this: the process of conversion is responsible for creating unintelligible content. I was thinking something like: You receive a large image (1600*1200), and Your client requests coverting it to a server-selected size (and server picks 32*32). But then I realized that in this case the culprit is not the process of conversion. It is the server for picking an extremently low resolution - instead of creating unintelligible content, the server should fail this request instead. _______________________________________________ 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 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 Apr 23 19:39:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87d-0001cZ-DK; Mon, 23 Apr 2007 19:39:05 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg87b-0001at-KP for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 19:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87b-0001ac-AO for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:03 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg87X-0004rH-T0 for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:03 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcwLV032673 for ; Mon, 23 Apr 2007 16:38:58 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcrTG010046 for ; Mon, 23 Apr 2007 16:38:57 -0700 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: 7bit Subject: RE: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis Date: Mon, 23 Apr 2007 16:39:23 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis Thread-Index: AceA/zfO9tOjezmcQEOB3Q2MiWMoxAE2pW4g References: <4624D46A.1090408@isode.com> From: "Eric Burger" To: "Lemonade WG" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Joking aside, anyone think this MUST be in Profile-bis? Alternately, anyone think it MUST NOT be in Profile-bis? -----Original Message----- From: Tony Finch [mailto:dot@dotat.at] Sent: Tuesday, April 17, 2007 10:45 AM To: Alexey Melnikov Cc: Lemonade WG Subject: Re: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis On Tue, 17 Apr 2007, Alexey Melnikov wrote: > > I actually disagree that this is insignificant. Not very many clients > keep persistent SMTP connections. It occurred to me this morning that a good slogan for QUICKSTART is "makes SMTP as fast as HTTP POST". Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE: WEST OR NORTHWEST 5 TO 7, DECREASING 4 OR 5, BACKING SOUTHWEST LATER. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN WEST. SQUALLY SHOWERS. MODERATE OR GOOD. _______________________________________________ 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 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 Apr 23 19:39:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87d-0001dG-IY; Mon, 23 Apr 2007 19:39:05 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg87b-0001az-Ob for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 19:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87b-0001ai-CG for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:03 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg87a-0004sP-UZ for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:03 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNd1NP032691; Mon, 23 Apr 2007 16:39:01 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcrTK010046; Mon, 23 Apr 2007 16:38:59 -0700 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: 7bit Subject: Passive Voice and Style (was RE: [lemonade] WGLC IMAP URL - update; comments) Date: Mon, 23 Apr 2007 16:39:24 -0700 Message-ID: In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA15743C211@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Passive Voice and Style (was RE: [lemonade] WGLC IMAP URL - update; comments) Thread-Index: Acdy0a3oOt98nhkuSA+xqq+jeFol/QAq+xBQBJcq7QA= References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com><460CCF33.6040705@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15743C211@esebe199.NOE.Nokia.com> From: "Eric Burger" To: , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: lemonade@ietf.org 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 use of passive voice, or the construction
, is poor English when writing for technical topics. Consider the example below: "Care must be taken when doing foo." ^^^^^^^^ The question is, WHO must take care? Likewise, consider this example: "Clean-up must be done before exiting." Again, WHO must do clean-up? It is rather easy to make passive voice into active voice. Take and rearrange it to be . For example, to correct the two examples above, we have: The server must take care when doing foo. ^^^^ The client must do clean-up before exiting. ^^ Altnernately, most of the time for the latter construction, when dealing with a form of "to do," one can drop the "do," as the real action verb is all that is necessary: The client must clean-up before exiting. Note that exactly specifying who does an action is (1) explicit, leaving no room for error and (2) concise, as it often is the same number of words or less. Even if you have one or two more words in your sentence from specifying the actors exactly, the removal of any ambiguity is worth the extra words. When should one use passive voice? Well, the last sentence is often a candidate, when one writes, "When can passive voice be used?" True, the latter version is one word shorter. Moreover, in the context of this e-mail, it should be obvious to whom I am addressing. However, as standards are often quoted out of context, it is a good practice to always use active voice, explicitly labeling the subject. For example, mystery writers often use passive voice, as part of the point is to not know who the active killer is. Most word processors, including Microsoft Word for Mac and Windows, will check for passive voice in their grammar checkers. Many people turn them off for creative writing. I would offer one turns them on for standards work. -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] Sent: Saturday, March 31, 2007 6:26 AM To: alexey.melnikov@isode.com Cc: lemonade@ietf.org Subject: RE: [lemonade] WGLC IMAP URL - update; comments [snip] >>12. Wording change in section 3.2 paragraph 8: "care must be >taken when resolving a URL which requires or requests any sort of >authentication" Wouldn't there be an easier way to say this? >> >I think the "Since URLs can easily come from untrusted sources" part >provides important background. I can move it till after the "Care must >be taken ...". Would this be any better? > [...] The part I do not like is "Care must be taken" it does not sound right to me, especially at the beginning of a sentence - however I can understand what it means. Perhaps a native English speaker can respond on this? [snip] 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 Apr 23 19:39:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87h-0001jd-Vn; Mon, 23 Apr 2007 19:39:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg87g-0001eN-Ky for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 19:39:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg87g-0001eF-BQ for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:08 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg87e-0004tj-Ul for lemonade@ietf.org; Mon, 23 Apr 2007 19:39:08 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNd2CX032708; Mon, 23 Apr 2007 16:39:02 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3NNcrTM010046; Mon, 23 Apr 2007 16:39:01 -0700 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: 7bit Date: Mon, 23 Apr 2007 16:39:25 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Symbolic References Thread-Index: AceF3xLur2Qx/n+0QLmwseMBHmJ7AA== From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [lemonade] Symbolic References 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 I get to change my position :-) There was a debate here about whether to use numeric or symbolic references in documents. I said I didn't care, but that the tools (and IEEE :-) use numeric references. There was a decent discussion on the IETF list about this subject. Feel free to follow the archives. The basic arguments are that numeric references are easier to find in the References section, but symbolic references are easier to track through the revision process. A suggestion is to ensure you sort your references alphabetically, so they are easier to find. Dave has what looks like cool tools; I'll let him post them here. 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 Apr 23 21:16:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9dd-0004cG-6D; Mon, 23 Apr 2007 21:16:13 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg9dc-0004cB-GZ for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 21:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9dc-0004c3-6p for lemonade@ietf.org; Mon, 23 Apr 2007 21:16:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg9da-0004Yv-SB for lemonade@ietf.org; Mon, 23 Apr 2007 21:16:12 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3O1G8j4019686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 18:16:09 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3O1G6R5025305; Mon, 23 Apr 2007 18:16:08 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4624D46A.1090408@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 23 Apr 2007 18:13:20 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: [lemonade] Re: Inclusion of QUICKSTART in Lemonade Profile-bis 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 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 At 5:01 PM +0200 4/17/07, Arnt Gulbrandsen wrote: > most users take a little while to compose the next message. Very > few people compose and send more than 12 messages per hour. Users sometimes draft messages when off-line, which are sent in a batch when next connected. Also, some clients optionally batch sent messages anyway. For example, I have my client set such that when I hit 'send'/'queue' the message is added to the outgoing queue, which is processed every 10-20 minutes (depending on account). That usually gives me a few minutes to re-open the message and edit things, which is why I like it. But I'd think saving round-trips and reducing latency is much more important when messages are sent one-by-one. Especially if the client isn't receiving mail at the same time (for example, the user sends a message but the interesting mailboxes are already resynched), since that's when the user is most aware of connection times, off-hook status, etc. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I love the smell of excessive quoting in the morning. --Steve Dorner _______________________________________________ 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 Apr 23 21:16: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 1Hg9dj-0004kj-BG; Mon, 23 Apr 2007 21:16:19 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg9di-0004ke-IX for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 21:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9di-0004kW-93 for lemonade@ietf.org; Mon, 23 Apr 2007 21:16:18 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg9dg-0004ZE-Uz for lemonade@ietf.org; Mon, 23 Apr 2007 21:16:18 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3O1GC0E019703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 18:16:13 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3O1G6R7025305; Mon, 23 Apr 2007 18:16:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4624D46A.1090408@isode.com> References: <4624D46A.1090408@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 23 Apr 2007 18:16:00 -0700 To: Alexey Melnikov , Arnt Gulbrandsen , Tony Finch From: Randall Gellens Subject: Re: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Lemonade WG 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 3:06 PM +0100 4/17/07, Alexey Melnikov wrote: > After reviewing the QUICKSTART document I think that it should not > be included in the Lemonade Profile Bis, because it is tricky to > implement and thus very easy to get wrong. Which document? I believe there are two, one that saves more round-trips but is trickier (the one that mixes TLS and SMTP initialization) and one that is simpler. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- To err is human, to moo bovine. _______________________________________________ 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 Apr 23 21:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9lK-0001jh-9d; Mon, 23 Apr 2007 21:24:10 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hg9lJ-0001jc-Vl for lemonade-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 21:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9lJ-0001jK-M2 for lemonade@ietf.org; Mon, 23 Apr 2007 21:24:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg9lI-00068u-BN for lemonade@ietf.org; Mon, 23 Apr 2007 21:24:09 -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 l3O1O5U2020832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 18:24:06 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3O1O3bK012853; Mon, 23 Apr 2007 18:24:04 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4624D46A.1090408@isod e.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 23 Apr 2007 18:21:55 -0700 To: "Eric Burger" , "Lemonade WG" From: Randall Gellens Subject: RE: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis 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: cf4fa59384e76e63313391b70cd0dd25 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 At 4:39 PM -0700 4/23/07, Eric Burger wrote: > anyone think this MUST be in Profile-bis? Alternately, > anyone think it MUST NOT be in Profile-bis? When we require server support for a feature in profile, we increase the server implementation burden, but decrease client complexity (assuming the feature has enough value that clients will want to use it). It's tricky to get this right. I'm not sure we're ready to decide yet regarding SMTP quickstart. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- All we need is a couple of facts. We already know the truth. --"Gee" on the TV show _Homicide_ _______________________________________________ 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 Apr 25 05:30:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdpI-0002r5-AI; Wed, 25 Apr 2007 05:30:16 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HgdpG-0002qf-MJ for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 05:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdpG-0002qX-3h for lemonade@ietf.org; Wed, 25 Apr 2007 05:30:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdpD-0008V7-Ku for lemonade@ietf.org; Wed, 25 Apr 2007 05:30:14 -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 ; Wed, 25 Apr 2007 10:30:10 +0100 Message-ID: <462789A9.2060209@isode.com> Date: Thu, 19 Apr 2007 16:24:25 +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 MIME-Version: 1.0 To: Kjetil Torgrim Homme Subject: Re: [lemonade] Re: WGLC 2192 bis References: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> <46261729.1080009@isode.com> <1176984454.17733.47.camel@havhest.ifi.uio.no> In-Reply-To: <1176984454.17733.47.camel@havhest.ifi.uio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org 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 Kjetil Torgrim Homme wrote: >On Wed, 2007-04-18 at 14:03 +0100, Alexey Melnikov wrote: > > >>Kjetil Torgrim Homme wrote: >> >> >>>sorry if I missed previous discussion, but I think it should say >>>something explicit about STARTTLS, ie., something like the client >>>SHOULD issue STARTTLS before authenticating if the server supports it. >>>this may require the examples to be reworked, since it essentially >>>means you *always* have to do CAPABILITY. >>> >>> >>Fair enough. Can you suggest specific text to be added? >> >> >after thinking a little more about it, I've concluded that anonymous >access doesn't need encryption since access is wide open anyway, so we >shouldn't encourage "wastefulness". > Agreed. >how about this? > >after this paragrah: > > If no user name or authentication mechanism is supplied, the > client must authenticate as anonymous to the server. [...] > >new text: > > For non-anonymous accesses, the client SHOULD issue STARTTLS > before authenticating if the server has the capability. < client MAY issue STARTTLS even for anonymous access.>> > > This seems fine, but a client can also try SASL security layer, such as GSSAPI instead. In which case TLS would not be needed. I need to think how to make your text more generic. >I'm not sure we need the clarification for anonymous access. with the >above text, only Example 3 needs to add a CAPABILITY command. > > >>>if this is unacceptable, I >>>think we need a syntax in the URL to make TLS required -- I don't feel >>>comfortable that messages may start getting sent unencrypted just >>>because a server upgrade added support for DIGESTMD5 in addition to >>>good old PLAIN... >>> >>> >>I was thinking about adding such syntactic element myself. I would like >>to hear other opinions on this before proceeding. >> >> >it seems awkward, and unnecessary with the above addition. > There are different cases. If TLS "SHOULD be negotiated", then the addition above covers it. If "TLS MUST be negotiated" (i.e. the data can't be retrieved unless connection confidentiality is achieved), then a new syntactic element is needed. The server can enforce it if such syntactic element is signed with URLAUTH. The client would know not to try accessing data if such element is present. >it is really >the responsibility of the server to provide sufficient protection for >the data it hands out, the client can't really enforce it. > > >>>on a similar note, should something be said about the special case >>>which is port 993? >>> >>> >>No, this document doesn't describe imaps. >> >> >ah, of course. > > Besides, imaps is a rathole I don't want to get into ;-) _______________________________________________ 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 Apr 25 05:30: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 1HgdpJ-0002ry-FR; Wed, 25 Apr 2007 05:30:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HgdpH-0002qx-Q5 for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 05:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdpH-0002qp-GO for lemonade@ietf.org; Wed, 25 Apr 2007 05:30:15 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdpG-0008V7-6M for lemonade@ietf.org; Wed, 25 Apr 2007 05:30:15 -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 ; Wed, 25 Apr 2007 10:30:12 +0100 Message-ID: <4628EAED.7000600@isode.com> Date: Fri, 20 Apr 2007 17:31:41 +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 MIME-Version: 1.0 To: Arnt Gulbrandsen References: <4624D46A.1090408@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org Subject: [lemonade] Re: Inclusion of QUICKSTART in Lemonade Profile-bis 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 Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> Arnt Gulbrandsen wrote: >> >>> 3.1 also requires QUICKSTART, which I'd rather drop. I sort of like >>> QUICSTART, but I like the idea of concluding Lemonade even more and >>> QUICKSTART doesn't buy us very much. It saves roundtrips (and some >>> bytes) when submitting messages, but IMO that's insignificant. >> >> I actually disagree that this is insignificant. Not very many clients >> keep persistent SMTP connections. > > You keep saying that as if it makes any difference. > > I've implemented persistent SMTP connections in a MUA and it doesn't > save much. Have you used TLS in your tests? > The SMTP server times out in a few minutes (2821 says five), and most > users take a little while to compose the next message. Very few people > compose and send more than 12 messages per hour. I think you've just made my argument for me: SMTP is essentially 1 message per connection, so any reduction in number of round trips and/or bandwidth that can be done during establishment of an SMTP session would help over time. If you are arguing that bandwidth savings are not significant when compared to bandwidth savings achievable for IMAP, I might even agree with 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 Wed Apr 25 05:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdpV-0002xy-Th; Wed, 25 Apr 2007 05:30:29 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HgdpV-0002xs-27 for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 05:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdpU-0002xk-Ml for lemonade@ietf.org; Wed, 25 Apr 2007 05:30:28 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdpT-00005B-D2 for lemonade@ietf.org; Wed, 25 Apr 2007 05:30:28 -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 ; Wed, 25 Apr 2007 10:30:21 +0100 Message-ID: <462E243F.3020908@isode.com> Date: Tue, 24 Apr 2007 16:37:35 +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: Kjetil Torgrim Homme Subject: Re: [lemonade] Re: WGLC 2192 bis References: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> <46261729.1080009@isode.com> <1176984454.17733.47.camel@havhest.ifi.uio.no> <462789A9.2060209@isode.com> In-Reply-To: <462789A9.2060209@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: lemonade@ietf.org 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 Alexey Melnikov wrote: > Kjetil Torgrim Homme wrote: > >>> Fair enough. Can you suggest specific text to be added? >> >> after thinking a little more about it, I've concluded that anonymous >> access doesn't need encryption since access is wide open anyway, so we >> shouldn't encourage "wastefulness". > > Agreed. > >> how about this? >> >> after this paragrah: >> >> If no user name or authentication mechanism is supplied, the >> client must authenticate as anonymous to the server. [...] >> >> new text: >> >> For non-anonymous accesses, the client SHOULD issue STARTTLS >> before authenticating if the server has the capability. <> client MAY issue STARTTLS even for anonymous access.>> > > This seems fine, but a client can also try SASL security layer, such > as GSSAPI instead. In which case TLS would not be needed. > I need to think how to make your text more generic. How about the following text: Clients wishing to achieve data confidentiality SHOULD use the STARTTLS command (if supported by the server) before starting authentication, or use a SASL mechanism, such as GSSAPI, that provides a confidentiality security layer. Should this text be moved to Security Considerations section? _______________________________________________ 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 Apr 25 06:05:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgeN3-0008V5-B7; Wed, 25 Apr 2007 06:05:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HgeN2-0008Rh-7r for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 06:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgeN1-0008QE-5X for lemonade@ietf.org; Wed, 25 Apr 2007 06:05:07 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgeMz-000694-Pf for lemonade@ietf.org; Wed, 25 Apr 2007 06:05:07 -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 ; Wed, 25 Apr 2007 11:05:04 +0100 Message-ID: <462F2797.6020901@isode.com> Date: Wed, 25 Apr 2007 11:04:07 +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: Randall Gellens Subject: Re: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis References: <4624D46A.1090408@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Tony Finch , Lemonade WG 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 Randall Gellens wrote: > At 3:06 PM +0100 4/17/07, Alexey Melnikov wrote: > >> After reviewing the QUICKSTART document I think that it should not >> be included in the Lemonade Profile Bis, because it is tricky to >> implement and thus very easy to get wrong. > > Which document? I believe there are two, When I reviewed it, there was only 1. > one that saves more round-trips but is trickier (the one that mixes > TLS and SMTP initialization) and one that is simpler. I might change my mind, but I would rather not include either one. (I need to review the simple one, maybe it is simple enough to be ready for inclusion). _______________________________________________ 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 Apr 25 08:57: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 1Hgh3S-0002GW-Gh; Wed, 25 Apr 2007 08:57:06 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hgh3R-0002Cy-Dd for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 08:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgh3R-0002Aw-34 for lemonade@ietf.org; Wed, 25 Apr 2007 08:57:05 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgh3P-0006sY-Od for lemonade@ietf.org; Wed, 25 Apr 2007 08:57:05 -0400 Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hgh3O-0001Y1-Qp; Wed, 25 Apr 2007 14:57:02 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx8.uio.no) by mail-mx8.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hgh3O-0000vP-D0; Wed, 25 Apr 2007 14:57:02 +0200 Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx8.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from ) id 1Hgh3O-0000vH-7X; Wed, 25 Apr 2007 14:57:02 +0200 Subject: Re: [lemonade] Re: WGLC 2192 bis From: Kjetil Torgrim Homme To: Alexey Melnikov In-Reply-To: <462E243F.3020908@isode.com> References: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> <46261729.1080009@isode.com> <1176984454.17733.47.camel@havhest.ifi.uio.no> <462789A9.2060209@isode.com> <462E243F.3020908@isode.com> Content-Type: text/plain Date: Wed, 25 Apr 2007 14:57:01 +0200 Message-Id: <1177505821.28584.164.camel@havhest.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=12.0, autolearn=disabled, AWL=0.149, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: C03C88FCF5180D3965EA259ED9CCCD59BBEEA5F3 X-UiO-Ratelimit-Test: Ratelimit X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: -48 maxlevel 200 minaction 2 bait 0 mail/h: 2042 total 1326451 max/h 8345 blacklist 0 greylist 0 ratelimit 1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org 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 Tue, 2007-04-24 at 16:37 +0100, Alexey Melnikov wrote: > How about the following text: > > Clients wishing to achieve data confidentiality SHOULD use the STARTTLS > command (if supported by the server) before starting authentication, > or use a SASL mechanism, such as GSSAPI, that provides a confidentiality > security layer. sounds good! perhaps mention integrity as well as confidentiality, as per Philip's comment? > Should this text be moved to Security Considerations section? I guess you need to mention this issue in the Security Considerations *anyway*, so I think it suffices to put it there. when I looked for guidance in the draft, I did a fulltext search for "TLS" and "crypt", so I would find it anyway, and of course everyone should do as I ;-) -- Kjetil T. _______________________________________________ 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 Apr 25 09:15: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 1HghL5-0002JS-RD; Wed, 25 Apr 2007 09:15:19 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HghL5-0002JI-2y for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 09:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghL4-0002Hk-MZ; Wed, 25 Apr 2007 09:15:18 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HghL2-0004HS-P3; Wed, 25 Apr 2007 09:15:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id AA9C049801C; Wed, 25 Apr 2007 14:15:15 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03624-02; Wed, 25 Apr 2007 14:15:08 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 5DDAA498016; Wed, 25 Apr 2007 14:15:08 +0100 (BST) MIME-Version: 1.0 Message-Id: <13829.1177506908.404308@peirce.dave.cridland.net> Date: Wed, 25 Apr 2007 14:15:08 +0100 From: Dave Cridland To: "Internet-Drafts@ietf.org" Content-Type: multipart/mixed; boundary="13829.1177506906.998919@peirce.dave.cridland.net" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.5 (/) X-Scan-Signature: afddcc4f0dbd876d4009dc71857c6cc6 Cc: Enhancements to Internet email to support diverse service enivronments Subject: [lemonade] Updated Draft: draft-cridland-imap-context 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 --13829.1177506906.998919@peirce.dave.cridland.net Content-Type: text/plain; charset="us-ascii"; format="flowed" This is draft-cridland-imap-context-01.txt Thanks. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade --13829.1177506906.998919@peirce.dave.cridland.net Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-cridland-imap-context-01.txt" Network Working Group D. Cridland Internet-Draft C. King Expires: October 27, 2007 Isode Limited April 25, 2007 Contexts for IMAP4 draft-cridland-imap-context Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results which can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. Cridland & King Expires October 27, 2007 [Page 1] Internet-Draft IMAP CONTEXT April 2007 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Context Hint . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Notifications of changes . . . . . . . . . . . . . . . . . 4 3.3.1. ADDTO Return Data Item . . . . . . . . . . . . . . . . 5 3.3.2. REMOVEFROM Return Data Item . . . . . . . . . . . . . 6 3.4. Partial results . . . . . . . . . . . . . . . . . . . . . 6 3.5. Caching results . . . . . . . . . . . . . . . . . . . . . 7 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Cookbook . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Virtual Mailboxes . . . . . . . . . . . . . . . . . . . . 10 A.2. Trash Mailboxes . . . . . . . . . . . . . . . . . . . . . 10 A.3. Other uses . . . . . . . . . . . . . . . . . . . . . . . . 11 A.4. Resynchronizing Contexts . . . . . . . . . . . . . . . . . 11 Appendix B. Server Implementation Notes . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Cridland & King Expires October 27, 2007 [Page 2] Internet-Draft IMAP CONTEXT April 2007 1. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client messaging user agent and IMAP4rev1 ([IMAP]) server respectively. The examples show a server which supports [ESEARCH] and [IDLE], neither extension is required for this specification. The IDLE command is used to denote an extended period of time during which any response may be sent to the client. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. Other capitalised words are typically names of IMAP extensions or commands - these are uppercased for clarity only, and are case- insensitive. [[ Editorial comments are like this. XML2RFC working source is held at http://svn.dave.cridland.net/svn/ietf-drafts/ draft-cridland-imap-contexts.xml ]] 2. Introduction Although the basic SEARCH command defined in [IMAP], as enhanced by [ESEARCH], is relatively compact in its representation, this reduction only saves a certain amount of data, and huge mailboxes can overwhelm the storage available for results on even relatively high- end desktop machines. This memo borrows concepts from [ACAP], providing a windowed view onto search results, as well as bandwidth and round-trip efficient updates. It is intended that the protocol may be easily adapted onto the SORT command specified in [SORT]. 3. Protocol Changes 3.1. Overview This extension is present in any IMAP4rev1 server which includes the string "CONTEXT", or any string beginning "CONTEXT=", within its advertised capabilities. Such servers also accept three additional return options, and provide three new result data items, and no new responses. The first search Cridland & King Expires October 27, 2007 [Page 3] Internet-Draft IMAP CONTEXT April 2007 return option is CONTEXT, an optional hint that the criteria will be used repeatedly, and is defined in Section 3.2. The second is UPDATE, which causes the server to provide efficient notifications of changes to the results. This is defined in Section 3.3. Finally, the PARTIAL return specifier causes the server to return a subset of the results in set-syntax. This allows for "virtual scrollbars" and other UI conveniences to be achieved without having to preload the entire result set, and is described in Section 3.4. All of the return specifiers have no interaction with either each other or any return specifiers defined in [ESEARCH]. 3.2. Context Hint The return option CONTEXT SHOULD be used by a client to indicate that subsequent use of the criteria are likely. Servers MAY ignore this return option, or use it as a hint to maintain a full result set, or index. A client might choose to obtain a count of matching messages prior to obtaining actual results. Here, the client signifies its intention to fetch the results themselves: C: A01 SEARCH RETURN (CONTEXT COUNT) UNDELETED UNKEYWORD $Junk S: * ESEARCH (TAG "A01") COUNT 23765 S: A01 OK Search completed. 3.3. Notifications of changes The search return option UPDATE, if used by a client, causes the server to issue unsolicited notifications containing updates to the SEARCH results which would be returned by an unmodified SEARCH. These results are carried in ADDTO and REMOVEFROM data items in ESEARCH/ESORT responses. Both ADDTO and REMOVEFROM data items SHOULD be delivered to clients in a timely manner, as and when results changes, whether by new messages arriving in the mailbox, metadata such as flags being changed, or messages being expunged. Typically, this would occur at the same time as the FETCH, EXISTS or EXPUNGE responses carrying the source of the change. Unlike [ACAP], there is no requirement that a context need be created Cridland & King Expires October 27, 2007 [Page 4] Internet-Draft IMAP CONTEXT April 2007 with CONTEXT to use UPDATE, and in addition, the lack of UPDATE with a CONTEXT does not affect the results caused by later SEARCH commands - there is no snapshot facility. There is no interaction between UPDATE and any other return options, therefore use of RETURN (UPDATE MIN), for example, does not notify about the minimum UID or sequence number, but notifies instead about all changes to the set of matching messages. In particular, this means that a client using UPDATE and PARTIAL on the same search program MAY receive notifications about messages which do not interest it currently. This time, the client will require notifications of updates, and chooses to obtain a count: C: B01 UID SEARCH RETURN (UPDATE COUNT) DELETED KEYWORD $Junk S: * ESEARCH (TAG "B01") COUNT 74 S: B01 OK Search completed, will notify. 3.3.1. ADDTO Return Data Item The ADDTO return data item contains, as payload, a list containing pairs of a position and a set of results to be inserted at the position. For ESEARCH responses, the position MAY be zero, and MAY be ignored by clients. The results are specified as UIDs or message numbers, depending on how the UPDATE was specified. If the UPDATE was present in a SEARCH command, the results will be message numbers; in a UID SEARCH command, they will be UIDs. C: B02 IDLE S: + Idle [...] S: * 23762 FETCH (FLAGS (\Deleted \Seen)) S: * ESEARCH (TAG "B01") UID ADDTO (0 32768) C: DONE S: B02 OK Not Idle. Note that this example assumes message 23762 with UID 32768 previously had neither \Deleted nor $Junk set. Also note that only the ADDTO is included, and not the COUNT. Cridland & King Expires October 27, 2007 [Page 5] Internet-Draft IMAP CONTEXT April 2007 3.3.2. REMOVEFROM Return Data Item The REMOVEFROM return data item contains a set of results to be removed. The results to be removed are referenced by message number or UID, as appropriate, and need not be in the same order as the results. Servers SHOULD sort the results in order to use the sequence-set syntax as efficiently as possible. There is no requirement on servers to avoid issuing REMOVEFROM return data at any particular moment, in particular this is distinct from EXPUNGE responses. The results are specified as UIDs or message numbers, depending on how the UPDATE was specified. If the UPDATE was present in a SEARCH command, the results will be message numbers; in a UID SEARCH command, they will be UIDs. Command B03 here is purely an example of a command which prohibits EXPUNGE messages. The REMOVEFROM could have been sent without any command in progress. C: B03 SEARCH RETURN () 1:* ALL S: * ESEARCH (TAG "B03") ALL 1:49152 S: * ESEARCH (TAG "B01") UID REMOVEFROM 32768 S: B03 OK Search completed. C: B04 IDLE S: + Idle S: * EXPUNGE 23762 [...] C: DONE S: B04 OK Not Idle. 3.4. Partial results The PARTIAL search return option causes the server to provide in an ESEARCH response the range from the results denoted by the sequence range given as the mandatory argument. The first result is 1, thus the first 500 results would be obtained by a return option of "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This intentionally mirrors message sequence numbers. Where a PARTIAL search return option references results which do not exist, by using a range which starts or ends higher than the COUNT of results, then the server returns those results which are in the set. This yields a PARTIAL return data item which has, as payload, the original range and a potentially missing set of results which may be shorter than the extent of the range. Cridland & King Expires October 27, 2007 [Page 6] Internet-Draft IMAP CONTEXT April 2007 The subset of results are returned in sequence-set syntax, and servers SHOULD order results from a SEARCH for maximum efficiency. Clients need not request PARTIAL results in any particular order. // Recall from A01 that there are 23764 results. C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED UNKEYWORD $Junk C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED UNKEYWORD $Junk C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED UNKEYWORD $Junk S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...) // 264 results in set syntax elided, // this spans the end of the results. S: A02 OK Completed. S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...) // 500 results in set syntax elided. S: A03 OK Completed. S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL) // No results are present, this is beyond the end of the results. S: A04 OK Completed. 3.5. Caching results Server implementations MAY cache results from a search or sort, whether or not hinted to by CONTEXT, in order to make subsequent searches more efficient, perhaps by recommencing a subsequent PARTIAL search where a previous search left off. However servers MUST behave identically whether or not internal caching is taking place, therefore any such cache is required to be updated as changes to the mailbox occur. An alternate strategy would be to discard results when any change occurs to the mailbox. Cridland & King Expires October 27, 2007 [Page 7] Internet-Draft IMAP CONTEXT April 2007 4. Formal Syntax The collected formal syntax. This includes definitions from [IMAP] and [IMAP-ABNF], and uses ABNF as defined in [ABNF]. capability =/ "CONTEXT" / "CONTEXT=" atom addto-position = number ;; Number may be 0 for SEARCH result additions. ;; from RFC3501 modifier-context = "CONTEXT" modifier-partial = "PARTIAL" SP seq-range ;; from [IMAP] modifier-update = "UPDATE" search-return-opt =/ modifier-context / modifier-partial / modifier-update ;; All conform to , from [IMAP-ABNF] ret-data-addto = "ADDTO" SP "(" addto-position SP sequence-set *(SP addto-position SP sequence-set) ")" ;; from [IMAP] ret-data-partial = "PARTIAL" SP "(" seq-range SP partial-results ")" ;; is the requested range. ;; from [IMAP] partial-results = sequence-set / "NIL" ;; from [IMAP] ;; NIL indicates no results correspond to the requested range. ret-data-removefrom = "REMOVEFROM" sequence-set ;; from [IMAP] search-return-data =/ ret-data-partial / ret-data-addto / ret-data-removefrom ;; All conform to , from [IMAP-ABNF] Cridland & King Expires October 27, 2007 [Page 8] Internet-Draft IMAP CONTEXT April 2007 5. Security Considerations It is believed that this specification introduces no serious new security considerations. However, implementors are advised to refer to [IMAP]. Creation of contexts, both for UPDATE and PARTIAL, can benefit from storing potentially large result sets on the server. Implementors are advised to take care not to provide a method for denial of service (DoS) attacks based on this; the notes in Appendix B may aid in implementation decisions. Note that a server avoiding storing the results will have much increased I/O, which may also be an avenue for DoS attacks. 6. IANA Considerations IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at: http://www.iana.org/assignments/imap4-capabilities This document defines the CONTEXT IMAP capability. IANA is requested to add it to the registry accordingly. 7. Acknowledgements Much of the design of this extension can be found in ACAP. Valuable comments, both in agreement and in dissent, were received from Alexey Melnikov, Arnt Gulbrandsen, Randall Gellens, Cyrus Daboo, and others, and many of these comments have had significant influence on the design or the text. The authors are grateful to all those involved, including those not mentioned here. 8. References 8.1. Normative References [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [IMAP-ABNF] Cridland & King Expires October 27, 2007 [Page 9] Internet-Draft IMAP CONTEXT April 2007 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 extension to SEARCH command for controlling what kind of information is returned", draft-melnikov-imap-search-ret-03 (work in progress), June 2006. [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS", draft-ietf-imapext-sort-18 (work in progress), November 2006. Appendix A. Cookbook A.1. Virtual Mailboxes It is possible to use the facilities described within this memo to create a facility largely similar to a virtual mailbox, but handled on the client side. Initially, the client SELECTs the real "backing" mailbox. Next, it can switch to a filtered view at any time by issuing a SEARCH RETURN (COUNT UPDATE CONTEXT), and using SEARCH RETURN (PARTIAL x:y) as the user scrolls, feeding the results into a FETCH as required to populate summary views. A.2. Trash Mailboxes Certain contexts are particularly useful for client developers wishing to present something similar to the common trash mailbox metaphor in limited bandwidth. The simple criteria of UNDELETED only matches undeleted messages, and the corresponding DELETED search key can be used to display a per-mailbox trash-like virtual mailbox. Cridland & King Expires October 27, 2007 [Page 10] Internet-Draft IMAP CONTEXT April 2007 A.3. Other uses It is entirely possible to simultaneously have two or more UPDATE searches in operation. This can be used to build a grouped message display in some cases, and also allows for monitoring counts of messages matching certain complex criteria. A.4. Resynchronizing Contexts The creation of a context, and immediate access to it, can all be accomplished in a single round-trip. Therefore, whilst it is possible to elide resynchronization if no changes have occurred, it is simpler in most cases to resynchronize by simply recreating the context. Appendix B. Server Implementation Notes Although a server may cache the results, this is not mandated nor required. UPDATE processing, for example, can be achieved by comparison of the old flag state (if any) and the new, and PARTIAL can be achieved by re-running the search until the suitable window is required. This is a result of there being no snapshot facility. For example, on a new message, the server can simply test for matches against all current UPDATE context search programs, and for any that match, send the ADDTO return data. Similarly, for a flag change on an existing message, the server can check whether the message matched with its old flags, whether it matches with new flags, and provide ADDTO or REMOVEFROM return data accordingly if these results differ. For PARTIAL requests, the server can perform a full search, discarding results until the lower bound is hit, and stopping the search when sufficient results have been obtained. With some additional state, it is possible to restart PARTIAL searches, thus avoiding performing the initial discard phase. For the best performance, however, caching the full search results is needed, which can allow for faster responses at the expense of memory. One reasonable strategy would be to balance this trade-off at run-time, discarding search results after a suitable timeout, and regenerating them as required. This yields state requirements of storing the search program for any UPDATE contexts, and optionally storing both search program and Cridland & King Expires October 27, 2007 [Page 11] Internet-Draft IMAP CONTEXT April 2007 (updated) results for further contexts as required. Authors' Addresses Dave Cridland Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB Email: dave.cridland@isode.com Curtis King Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB Email: cking@mumbo.ca Cridland & King Expires October 27, 2007 [Page 12] Internet-Draft IMAP CONTEXT April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Cridland & King Expires October 27, 2007 [Page 13] --13829.1177506906.998919@peirce.dave.cridland.net 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 --13829.1177506906.998919@peirce.dave.cridland.net-- From lemonade-bounces@ietf.org Wed Apr 25 09:25:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghVH-0000fz-SN; Wed, 25 Apr 2007 09:25:51 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HghVH-0000fr-8A for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 09:25:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghVG-0000fj-Up for lemonade@ietf.org; Wed, 25 Apr 2007 09:25:50 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HghVF-0007uG-Ib for lemonade@ietf.org; Wed, 25 Apr 2007 09:25:50 -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 ; Wed, 25 Apr 2007 14:25:48 +0100 Message-ID: <462F56A3.3000006@isode.com> Date: Wed, 25 Apr 2007 14:24:51 +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 MIME-Version: 1.0 To: Enhancements to Internet email to support diverse service enivronments References: <13829.1177506908.404308@peirce.dave.cridland.net> In-Reply-To: <13829.1177506908.404308@peirce.dave.cridland.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [lemonade] Treat as WGLC: draft-cridland-imap-context-01.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 Dave Cridland wrote: >Network Working Group D. Cridland >Internet-Draft C. King >Expires: October 27, 2007 Isode Limited > April 25, 2007 > > > Contexts for IMAP4 > draft-cridland-imap-context > > Work Group Last Call closes on 11 May 2007. If you chose to send private comments, please don't forget to CC them to me, so that I can keep track of issues in the document. Alexey, Lemonade WG Secretary. _______________________________________________ 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 Apr 25 09:46:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghp8-0007k0-0J; Wed, 25 Apr 2007 09:46:22 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hghp6-0007c1-ES for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 09:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghp6-0007Zj-2o for lemonade@ietf.org; Wed, 25 Apr 2007 09:46:20 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hghp4-0003Je-MY for lemonade@ietf.org; Wed, 25 Apr 2007 09:46:20 -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 ; Wed, 25 Apr 2007 14:46:18 +0100 Message-ID: <462F5B71.3050306@isode.com> Date: Wed, 25 Apr 2007 14:45:21 +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 MIME-Version: 1.0 To: Kjetil Torgrim Homme Subject: Re: [lemonade] Re: WGLC 2192 bis References: <1ry7kqv38w.fsf@kaksi.ifi.uio.no> <46261729.1080009@isode.com> <1176984454.17733.47.camel@havhest.ifi.uio.no> <462789A9.2060209@isode.com> <462E243F.3020908@isode.com> <1177505821.28584.164.camel@havhest.ifi.uio.no> In-Reply-To: <1177505821.28584.164.camel@havhest.ifi.uio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org 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 Kjetil Torgrim Homme wrote: >On Tue, 2007-04-24 at 16:37 +0100, Alexey Melnikov wrote: > > >>How about the following text: >> >> Clients wishing to achieve data confidentiality SHOULD use the STARTTLS >> command (if supported by the server) before starting authentication, >> or use a SASL mechanism, such as GSSAPI, that provides a confidentiality >> security layer. >> >> >sounds good! perhaps mention integrity as well as confidentiality, as >per Philip's comment? > > Done. >>Should this text be moved to Security Considerations section? >> >> >I guess you need to mention this issue in the Security Considerations >*anyway*, so I think it suffices to put it there. when I looked for >guidance in the draft, I did a fulltext search for "TLS" and "crypt", so >I would find it anyway, and of course everyone should do as I ;-) > > Ok, the suggested text was moved to section 10. _______________________________________________ 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 Apr 25 11:37: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 1HgjYK-0005Bt-I7; Wed, 25 Apr 2007 11:37:08 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HgjYJ-00054r-GM for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 11:37:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjYJ-00052B-4c for lemonade@ietf.org; Wed, 25 Apr 2007 11:37:07 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HgjYE-0002mT-Os for lemonade@ietf.org; Wed, 25 Apr 2007 11:37:07 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45196) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1HgjWd-000112-1U (Exim 4.63) (return-path ); Wed, 25 Apr 2007 16:35:23 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HgjWd-0002nY-Dx (Exim 4.54) (return-path ); Wed, 25 Apr 2007 16:35:23 +0100 Date: Wed, 25 Apr 2007 16:35:23 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alexey Melnikov Subject: Re: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis In-Reply-To: <462F2797.6020901@isode.com> Message-ID: References: <4624D46A.1090408@isode.com> <462F2797.6020901@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Randall Gellens , Lemonade WG 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 > > > After reviewing the QUICKSTART document I think that it should not be > > > included in the Lemonade Profile Bis, because it is tricky to implement > > > and thus very easy to get wrong. I've tried to make the tricky workflow clearer in the -B draft. Most of the difficulty is (unfortunately) at the client end, particularly pipelined STARTTLS and the working of the server capability cache. I plan an updated draft which makes it clear that the cache is optional, i.e. that the -B draft can accommodate simple clients with almost the same performance as the -A draft. Tony. -- f.a.n.finch http://dotat.at/ THAMES DOVER WIGHT PORTLAND PLYMOUTH: SOUTHWESTERLY VEERING NORTHEASTERLY 3 OR 4, INCREASING 6 OR 7. SLIGHT INCREASING MODERATE OR ROUGH. RAIN OR DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR IN THAMES AND DOVER. _______________________________________________ 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 Apr 25 14:14: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 1Hgm0P-0002lv-Ie; Wed, 25 Apr 2007 14:14:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hgm0N-0002lj-La for lemonade-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 14:14:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgm0N-0002lb-Bz for lemonade@ietf.org; Wed, 25 Apr 2007 14:14:15 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgm0L-00014H-Pe for lemonade@ietf.org; Wed, 25 Apr 2007 14:14:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id CE300498010; Wed, 25 Apr 2007 19:14:12 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06072-08; Wed, 25 Apr 2007 19:14:06 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id CA33E49800C; Wed, 25 Apr 2007 19:14:05 +0100 (BST) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <13829.1177524845.778391@peirce.dave.cridland.net> Date: Wed, 25 Apr 2007 19:14:05 +0100 From: Dave Cridland To: Eric Burger Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Enhancements to Internet email to support diverse service enivronments Subject: [lemonade] Re: Symbolic References 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 Tue Apr 24 00:39:25 2007, Eric Burger wrote: > There was a decent discussion on the IETF list about this subject. > Feel > free to follow the archives. The basic arguments are that numeric > references are easier to find in the References section, but > symbolic > references are easier to track through the revision process. A > suggestion is to ensure you sort your references alphabetically, so > they > are easier to find. > > I went out of my way to ensure that the symbolic references I'm using in profile-bis are not only sorted alphabetically, but collated according to protocol, by naming them using protocol-like prefixes. This makes the symbolic reference tags longer than usual (and I'm not really recommending doing this unless you have a lot of references), but makes them easy to find. (As it happens, I suspect that Niel Cook's streaming draft might benefit, since it makes it easy to see if it's an IMAP, SIP, etc reference). > Dave has what looks like cool tools; I'll let him post them here. > > They're not cool tools at all, but they are convenient gratuitous hacks. Look at http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-imap-contexts.xml for a simple source document. There are four things of note: 1) I use for things like authors. (One day, I'll make it so I can switch between editor and author here). 2) References ( elements) optionally have a dwdrfc-type attribute, which is usually (if it's there) "norm", indicating a normative use of the reference. 3) elements have a similar attribute, which indicates whether they're normative reference sections or not. 4) Inside all references sections, I use elements, which have an anchor attribute (my choice of anchor), and a src attribute, which either contains a full URI, or a short-hand, which points to the xml.resource.org bibxml reference fragment. Next, I have two XSL transforms: rfc2629-noinc.xsl: Takes my source as input, and outputs a "proper" xml2rfc file without any includes. It'll rewrite reference fragments as it imports them so the anchors are of my own choosing. Sorting them is left to xml2rfc. rfc2629-refchk.xsl: Outputs an XML file describing missing or unused references, or references found in the normative section which are never marked as being used normatively, or references which are used normatively but not found in the normative reference section. (Normally, the latter two checks don't find anything except refernces I've not marked up correctly; sometimes, though, I find that while I thought a reference was normative, I cannot actually find a case where it's used normatively.) Finally, there's a Makefile which will generate either a *.chk file (the output of the refchk XSLT), or a *.txt file (the output of xml2rfc over the noinc output). So to produce the text file for submission, I run "make draft-cridland-imap-contexts.txt". Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and 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 Thu Apr 26 04:48:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgzdz-0005KQ-Ki; Thu, 26 Apr 2007 04:48:03 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hgzdx-0005KI-Ri for lemonade-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 04:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgzdu-0005K9-Ql for lemonade@ietf.org; Thu, 26 Apr 2007 04:47:58 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgzdt-0006I6-Ag for lemonade@ietf.org; Thu, 26 Apr 2007 04:47:58 -0400 Received: from lochnagar.oryx.com (unknown [195.30.37.40]) by kalyani.oryx.com (Postfix) with ESMTP id 2D1724AC23 for ; Thu, 26 Apr 2007 10:47:57 +0200 (CEST) Message-Id: Date: Thu, 26 Apr 2007 10:47:16 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis References: <4624D46A.1090408@isode.com> <462F2797.6020901@isode.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Tony Finch , Alexey Melnikov , Randall Gellens 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 Just one thing I'd like to make clear: I do not think that QUICKSTART is bad as such. I just think its savings are insignificant in lemonade's part of the world. Lemonade clients don't do very much SMTP (cf. Eric Burger's .sig), and what little they do can be done in the background, without keeping the user waiting. There are other SMTP clients, and I'll review QUICKSTART eventually. 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 Thu Apr 26 08:02:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh2gH-0003Eg-O9; Thu, 26 Apr 2007 08:02:37 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hh2gG-0003EV-S6 for lemonade-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 08:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh2gG-0003EI-I7 for lemonade@ietf.org; Thu, 26 Apr 2007 08:02:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh2gG-0005Z7-37 for lemonade@ietf.org; Thu, 26 Apr 2007 08:02:36 -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 ; Thu, 26 Apr 2007 13:02:17 +0100 Message-ID: <463078CD.9030002@isode.com> Date: Thu, 26 Apr 2007 11:02:53 +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: Randall Gellens References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: lemonade@ietf.org Subject: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.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 Hi Randy, Thank you for the review! I've made most of the changes you've suggested. I would like to discuss more significant issues. Below I've grouped them by topic and named them. 1). IANA registry for parameters: > OLD: > parameter names should be standardized > > NEW: > parameter names are expected to be standardized > > (just a guess, but the "should" is confusing") > > Also, do we want to perhaps reference RFC 2912 here? I was just planning to establish a new IANA registry. Or we can reuse an existing one. Suggestions are welcome. Having an informative reference to RFC 2912 would be fine. 2). Support for default conversion: > OLD: > the client can use a special marker NIL > > NEW: > the client MAY use a special marker NIL I don't want to use MAY, as the server might not support the special marker. More on this below: > ---------- > OLD: > Note that support for such "default > conversion" request is OPTIONAL in servers. > > NEW: > Note that support for such "default > conversion" requests is OPTIONAL in servers. > > Also, how does the client discover if the server provides such support? Currently the client has to try to use it. If it receives a tagged NO response, then default conversion is not supported. > I think that the only use in providing this default conversion is to > support very simple clients. Thus, it doesn't make sense to make this > an option for servers, since the very clients that might need it might > also be too simple to have multiple code paths to handle it not being > available, and anyway, what is the client to do? If we are going to > include default conversions, I think they should be mandatory for servers. If we make it mandatory for servers, we need to define how it can be implemented, at least in general purpose IMAP servers. I have no idea what the choices are, especially which choices are good. So as a server implementor I would need some guidance about implementing this feature. > How the server decides remains out of scope, and we aren't requiring > the server to make good choices (that's a quality-of-implementation > thing), but this can't be an option. We don't want to encourage bad choices either. > It also doesn't seem to be any more of a burden to require the server > to pick something if it is going to support something. 3). Mandatory to implement conversion: > ---------- > Section 6.1.1: > > Do we really want to say SHOULD for text/html to text/plain? I think we had this discussion before and I thought that consensus was declared. However I feel that many people are unhappy with the choice, so maybe we don't actually have a consensus. Do you think charset conversion (ISO-8859-* to UTF-8) is better? > Is this actually useful for any mobile device that can support IMAP? It is useful for a desktop client that doesn't support HTML. > I wonder if text/plain to text/html wouldn't be just as useful? (it is > easier to implement). It is easier, but I think it is pointless. 4). Handling of malformed MIME types: > OLD: > malformed MIME types may also generate > > NEW: > malformed MIME types MAY also generate The whole sentence was replaced with: A syntactically invalid MIME media type SHOULD generate a BAD tagged response from the server. An unrecognized MIME media type generates a NO tagged response. Does this address your concern? _______________________________________________ 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 Apr 26 08:02: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 1Hh2gL-0003Fk-T7; Thu, 26 Apr 2007 08:02:41 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hh2gK-0003Fd-3z for lemonade-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 08:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh2gJ-0003FV-Qh for lemonade@ietf.org; Thu, 26 Apr 2007 08:02:39 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh2gJ-0005ZI-Fz for lemonade@ietf.org; Thu, 26 Apr 2007 08:02:39 -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 ; Thu, 26 Apr 2007 13:02:17 +0100 Message-ID: <46307B76.9030302@isode.com> Date: Thu, 26 Apr 2007 11:14:14 +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 MIME-Version: 1.0 To: Lemonade WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [lemonade] IESG DISCUSS on SEARCH WITHIN draft 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 search WITHIN draft got a DISCUSS comment (and a related comment) from IESG: Cullen Jennings: Discuss [2007-04-03]: It seems like it would be better if the rounding was always done in such a way that the result included a super set of what the original query requested. Given there is no way to report what sort of rounding or how much rounding was done by the server, I would be concerned about a scheme where the client could not even figure out how much of the requested time was being omitted from the returned result set. Lars Eggert: Comment [2007-04-05]: Section 4020, paragraph 0: > For example, if the client requests messages that are younger than > 4020 (67 minutes), but the server only performs searches with hourly > accuracy (as mandated above), the server performs the search as if > the client requested a 60-minute interval. Note the choice of > rounding up or down is at the discretion of the server. However, > rounding down to zero is NOT RECOMMENDED, as this may result in > searches for messages YOUNGER than a value being rounded to YOUNGER > 0, which will always fail. The issue of rounding down for YOUNGER being problematic is important. It should be moved from the example to the preceding paragraph, where behavior is specified. Also, rounding up for OLDER is similarly problematic and should be discouraged, too. (I'll let Cullen hold the DISCUSS on the rounding issue.) ============= Personally I agree with the comments. I felt that the rounding procedure is underspecified and would lead to interoperability comments. I also agree with Cullen that it would be better to round in a way that would cause the server to return superset of the correct data. At least this seems sensible to clients that display this data to users. Chris suggested that there might be two separate use cases for this extensions: 1. A vanilla SEARCH/SORT/THREAD WITHIN that is issued once. 2. When SEARCH WITHIN interacts with an IMAP extension providing dynamic results over time. In the first case he suggested that there is no reason to round the value. In the second case, a server MUST regenerate the dynamic result set at least every hour and MAY regenerate the dynamic result set more frequently. I agree with Chris' proposal. So let me suggest the following changes to the document: 1). Clarify that a one time SEARCH/SORT/THREAD must be exact. 2). Allow implementations to regenerate result once an hour when WITHIN is used in VFOLDER/CONTEXT. Possibly add some examples about how rounding can be done. Any objections? _______________________________________________ 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 Apr 26 13:27:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7l0-0001Kb-0k; Thu, 26 Apr 2007 13:27:50 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hh7ky-0001KT-Sd for lemonade-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7ky-0001KJ-Ir for lemonade@ietf.org; Thu, 26 Apr 2007 13:27:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7ky-0004dm-4d for lemonade@ietf.org; Thu, 26 Apr 2007 13:27:48 -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 l3QHRkIx031801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Apr 2007 10:27:47 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-35.qualcomm.com [10.50.16.35]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3QHRiqh028202; Thu, 26 Apr 2007 10:27:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <463078CD.9030002@isode.com> References: <463078CD.9030002@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 26 Apr 2007 10:24:58 -0700 To: Alexey Melnikov From: Randall Gellens Subject: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.txt 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: 827a2a57ca7ab0837847220f447e8d56 Cc: lemonade@ietf.org 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 11:02 AM +0100 4/26/07, Alexey Melnikov wrote: > Hi Randy, > Thank you for the review! I've made most of the changes you've suggested. > > I would like to discuss more significant issues. Below I've grouped > them by topic and named them. > > 1). IANA registry for parameters: > >> OLD: >> parameter names should be standardized >> >> NEW: >> parameter names are expected to be standardized >> >> (just a guess, but the "should" is confusing") >> >> Also, do we want to perhaps reference RFC 2912 here? > > I was just planning to establish a new IANA registry. Or we can > reuse an existing one. Suggestions are welcome. > > Having an informative reference to RFC 2912 would be fine. Sorry, I actually meant RFC 2506, which established an IANA registry for media features. I was wondering if this could be re-used for our purposes. > > 2). Support for default conversion: > >> OLD: >> the client can use a special marker NIL >> >> NEW: >> the client MAY use a special marker NIL > > I don't want to use MAY, as the server might not support the > special marker. More on this below: I think we can't make this optional. Either servers MUST support it, or we drop the feature. More on this below. >> Also, how does the client discover if the server provides such support? > > Currently the client has to try to use it. If it receives a tagged > NO response, then default conversion is not supported. I think that's a problem. The extra complexity this imposes on the client outweighs the benefit of the feature, I think. > >> I think that the only use in providing this default conversion is >> to support very simple clients. Thus, it doesn't make sense to >> make this an option for servers, since the very clients that might >> need it might also be too simple to have multiple code paths to >> handle it not being available, and anyway, what is the client to >> do? If we are going to include default conversions, I think they >> should be mandatory for servers. > > If we make it mandatory for servers, we need to define how it can > be implemented, at least in general purpose IMAP servers. I have no > idea what the choices are, especially which choices are good. So as > a server implementor I would need some guidance about implementing > this feature. Providing this guidance is good, but I think it is a harder problem then what we're trying to solve with this draft, so I'd say it should be done elsewhere. We could compromise and add some clearly non-normative text that makes general suggestions. For example, servers could keep a list of supported destination media subtypes. If these are ranked according to some guess as to how widespread client support is, or how difficult rendering is, then the server can choose as a default conversion, absent any information as to the client's specifics, the highest-ranked non-identity subtype. If the server has information as to what the client supports, it can pick the highest-ranked supported subtype, or the specific client support information can include a ranking. > >> How the server decides remains out of scope, and we aren't >> requiring the server to make good choices (that's a >> quality-of-implementation thing), but this can't be an option. > > We don't want to encourage bad choices either. It's subjective which default conversions are good versus bad choices. But it's objective that making default conversion optional for servers complicates clients. So we should either make this mandatory or drop it entirely. > >> It also doesn't seem to be any more of a burden to require the >> server to pick something if it is going to support something. > > > 3). Mandatory to implement conversion: > >> ---------- >> Section 6.1.1: >> >> Do we really want to say SHOULD for text/html to text/plain? > > I think we had this discussion before and I thought that consensus > was declared. > However I feel that many people are unhappy with the choice, so > maybe we don't actually have a consensus. > > Do you think charset conversion (ISO-8859-* to UTF-8) is better? Better and more useful, perhaps. > >> Is this actually useful for any mobile device that can support IMAP? > > It is useful for a desktop client that doesn't support HTML. But are there any clients that don't support HTML? > >> I wonder if text/plain to text/html wouldn't be just as useful? >> (it is easier to implement). > > It is easier, but I think it is pointless. Perhaps not. If a client has an HTML display engine, it is easier to use it than to reformat plain text to fit a small screen. As an example, Eudora for Palm makes use of the Qpopper x-mangle option to have plain text (both format=flowed and format=fixed) converted to HTMl to make rendering easier. > > 4). Handling of malformed MIME types: > >> OLD: >> malformed MIME types may also generate >> >> NEW: >> malformed MIME types MAY also generate > > The whole sentence was replaced with: > A syntactically invalid MIME media type SHOULD > generate a BAD tagged response from the server. An unrecognized MIME > media type generates a NO tagged response. > > Does this address your concern? Yes, thanks. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If you attack stupidity you attack an entrenched interest with friends in government and every walk of public life, and you will make small progress against it. --Samuel Marchbanks _______________________________________________ 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 Apr 26 15:50:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9zQ-00085D-9w; Thu, 26 Apr 2007 15:50:52 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hh9z8-0007Mn-F2 for lemonade-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 15:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9z8-0007MW-0e; Thu, 26 Apr 2007 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hh9z6-0003y8-Lu; Thu, 26 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 97103175A5; Thu, 26 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hh9yc-00069W-CE; Thu, 26 Apr 2007 15:50:02 -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: Thu, 26 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-04.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 : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-reconnect-client-04.txt Pages : 25 Date : 2007-4-26 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 that allows for a more compact representation for a list of expunged messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-04.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-reconnect-client-04.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-reconnect-client-04.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-4-26121632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-client-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-26121632.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 Apr 26 15:54:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhA2m-0006sf-Qy; Thu, 26 Apr 2007 15:54:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhA2l-0006sG-QB for lemonade-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 15:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhA2l-0006s4-FU for lemonade@ietf.org; Thu, 26 Apr 2007 15:54:19 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhA2b-0006nN-Cs for lemonade@ietf.org; Thu, 26 Apr 2007 15:54:19 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3QJs8Dv017546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Apr 2007 12:54:08 -0700 Received: from [76.102.225.135] (vpn-10-50-0-169.qualcomm.com [10.50.0.169]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3QJs6OP020608; Thu, 26 Apr 2007 12:54:07 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <463078CD.9030002@isode.com> Date: Thu, 26 Apr 2007 12:54:04 -0700 To: Randall Gellens , Alexey Melnikov From: Ted Hardie Subject: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: lemonade@ietf.org 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 10:24 AM -0700 4/26/07, Randall Gellens wrote: >> >> 1). IANA registry for parameters: >> >>> OLD: >>> parameter names should be standardized >>> >>> NEW: >>> parameter names are expected to be standardized >>> >>> (just a guess, but the "should" is confusing") >>> >>> Also, do we want to perhaps reference RFC 2912 here? >> >> I was just planning to establish a new IANA registry. Or we can reuse an existing one. Suggestions are welcome. >> >> Having an informative reference to RFC 2912 would be fine. > >Sorry, I actually meant RFC 2506, which established an IANA registry for media features. I was wondering if this could be re-used for our purposes. I thought that Section 6's statement on parameters put the OMA-specified names as guidelines: IMAP servers which support CONVERT MAY support additional transcoding parameters for each media type. All such servers MUST minally support recognition of charset for text/* MIME types, although they may decline to honor some requests. For media types other than text, it is beyond the scope of this document to define conversion parameters. In general however, CONVERT compliant servers MAY choose to support additional parameters, and if so, they SHOULD follow the OMA STI 1.0 spec [OMA-STI] adopting the same parameter names as defined in section 5.2.4 and above for the most popular image/*, video/*, and audio/* codecs One possibility would be to match the OMA terms to the RFC 2506 IETF registry terms either by adding terms or providing the alternate name (width & height becoming something like size-x and size-y). It would also be possible to use the OMA terms directly, using the RFC 2506 global tree (e.g. g.oma.SOMETHING). I am not entirely sure, however, whether this is the right way to go. I think some of the directives described (crop, stretch, aspect ratio) may be a little difficult to express. If this interoperability is desired, we can probably work it out, but we should have the larger conversation of whether it is the right direction. Perhaps we should have Larry Masinter, the current expert for the media feature registry have a look at the document? regards, Ted _______________________________________________ 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 Apr 27 06:18: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 1HhNXG-0003SM-HC; Fri, 27 Apr 2007 06:18:42 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhNXF-0003SG-P7 for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 06:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhNXE-0003S8-Ql for lemonade@ietf.org; Fri, 27 Apr 2007 06:18:41 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhNXD-0001lV-Ey for lemonade@ietf.org; Fri, 27 Apr 2007 06:18:40 -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, 27 Apr 2007 11:18:35 +0100 Message-ID: <4631B152.6000005@isode.com> Date: Fri, 27 Apr 2007 09:16:18 +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 MIME-Version: 1.0 To: Eric Burger Subject: Re: Passive Voice and Style (was RE: [lemonade] WGLC IMAP URL - update; comments) References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com><460CCF33.6040705@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA15743C211@esebe199.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org, 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 Eric Burger wrote: >The use of passive voice, or the construction past-tense verb>, is poor English when writing for technical topics. > >Consider the example below: >"Care must be taken when doing foo." > ^^^^^^^^ >The question is, WHO must take care? > > Ok, this is a good argument. I rewrote the sentence without passive voice. ("Clients must take care ...") _______________________________________________ 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 Apr 27 07:08:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOJ2-0006z1-PU; Fri, 27 Apr 2007 07:08:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhOJ1-0006yw-Go for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 07:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOJ1-0006ym-7I for lemonade@ietf.org; Fri, 27 Apr 2007 07:08:03 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOJ0-0007xx-IW for lemonade@ietf.org; Fri, 27 Apr 2007 07:08:03 -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, 27 Apr 2007 12:08:01 +0100 Message-ID: <4631D958.9070405@isode.com> Date: Fri, 27 Apr 2007 12:07:04 +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 MIME-Version: 1.0 To: Ted Hardie Subject: Re: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.txt References: <463078CD.9030002@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Randall Gellens , lemonade@ietf.org 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 Ted Hardie wrote: >At 10:24 AM -0700 4/26/07, Randall Gellens wrote: > > >>>1). IANA registry for parameters: >>> >>> >>>>OLD: >>>> parameter names should be standardized >>>> >>>>NEW: >>>> parameter names are expected to be standardized >>>> >>>>(just a guess, but the "should" is confusing") >>>> >>>>Also, do we want to perhaps reference RFC 2912 here? >>>> >>>> >>>I was just planning to establish a new IANA registry. Or we can reuse an existing one. Suggestions are welcome. >>> >>>Having an informative reference to RFC 2912 would be fine. >>> >>> >>Sorry, I actually meant RFC 2506, which established an IANA registry for media features. I was wondering if this could be re-used for our purposes. >> >> >I thought that Section 6's statement on parameters put the OMA-specified >names as guidelines: > > IMAP servers which support CONVERT MAY support additional transcoding > parameters for each media type. All such servers MUST minally support > recognition of charset for text/* MIME types, although they may > decline to honor some requests. For media types other than text, it > is beyond the scope of this document to define conversion parameters. > In general however, CONVERT compliant servers MAY choose to support > additional parameters, and if so, they SHOULD follow the OMA STI 1.0 > spec [OMA-STI] adopting the same parameter names as defined in > section 5.2.4 and above for the most popular image/*, video/*, and > audio/* codecs > >One possibility would be to match the OMA terms to the RFC 2506 >IETF registry terms either by adding terms or providing the alternate >name > I think this is reasonable. The existing registry seems to be a close fit for what we are trying to do. >(width & height becoming something like size-x and size-y). > > A side note: size-x and size-y are in inches, while width and height are supposed to be in pixels. >It would also be possible to use the OMA terms directly, using >the RFC 2506 global tree (e.g. g.oma.SOMETHING). > > Yes, this would work too. >I am not entirely sure, however, whether this is the right way to go. >I think some of the directives described (crop, stretch, aspect ratio) >may be a little difficult to express. > I would be interested in rationalizing these attributes once the base CONVERT is done. >If this interoperability is desired, >we can probably work it out, but we should have the larger conversation >of whether it is the right direction. Perhaps we should have Larry >Masinter, the current expert for the media feature registry have a look >at the document? > > Yes please! _______________________________________________ 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 Apr 27 07:10:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOLC-0007Eb-4L; Fri, 27 Apr 2007 07:10:18 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhOLB-0007EW-D4 for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 07:10:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOLB-0007EN-3c for lemonade@ietf.org; Fri, 27 Apr 2007 07:10:17 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOL9-0000yz-Qv for lemonade@ietf.org; Fri, 27 Apr 2007 07:10:17 -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, 27 Apr 2007 12:10:12 +0100 Message-ID: <4631D9DC.2050201@isode.com> Date: Fri, 27 Apr 2007 12:09:16 +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 MIME-Version: 1.0 To: Ted Hardie Subject: Re: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.txt References: <463078CD.9030002@isode.com> <4631D958.9070405@isode.com> In-Reply-To: <4631D958.9070405@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Randall Gellens , lemonade@ietf.org 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 Alexey Melnikov wrote: > Ted Hardie wrote: > >> One possibility would be to match the OMA terms to the RFC 2506 >> IETF registry terms either by adding terms or providing the alternate >> name > > I think this is reasonable. > The existing registry seems to be a close fit for what we are trying > to do. I would also note that the "charset" attribute used in the CONVERT document is already in the registry. _______________________________________________ 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 Apr 27 13:41:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUSA-00035m-Aj; Fri, 27 Apr 2007 13:41:54 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhUS9-00035h-TT for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 13:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUS9-00035Z-Js for lemonade@ietf.org; Fri, 27 Apr 2007 13:41:53 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUS7-0003X9-4J for lemonade@ietf.org; Fri, 27 Apr 2007 13:41:53 -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 l3RHfnNu031308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Apr 2007 10:41:50 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3RHfmZi022976; Fri, 27 Apr 2007 10:41:49 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4631D958.9070405@isode.com> References: <463078CD.9030002@isode.com> <4631D958.9070405@isode.com> Date: Fri, 27 Apr 2007 10:41:48 -0700 To: Alexey Melnikov From: Ted Hardie Subject: Re: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Randall Gellens , lemonade@ietf.org 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 12:07 PM +0100 4/27/07, Alexey Melnikov wrote: >I think this is reasonable. >The existing registry seems to be a close fit for what we are trying to do. > >>(width & height becoming something like size-x and size-y). >> >A side note: size-x and size-y are in inches, while width and height are supposed to be in pixels. The current registry's first enties are for pix-x and pix-y, so that is not a problem. >>It would also be possible to use the OMA terms directly, using >>the RFC 2506 global tree (e.g. g.oma.SOMETHING). >> >Yes, this would work too. > >>I am not entirely sure, however, whether this is the right way to go. >>I think some of the directives described (crop, stretch, aspect ratio) >>may be a little difficult to express. >> >I would be interested in rationalizing these attributes once the base CONVERT is done. > >>If this interoperability is desired, >>we can probably work it out, but we should have the larger conversation >>of whether it is the right direction. Perhaps we should have Larry >>Masinter, the current expert for the media feature registry have a look >>at the document? >> >Yes please! Okay, I'll drop a note to Larry, asking him to review it. regards, Ted _______________________________________________ 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 Apr 27 13:49: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 1HhUZN-0004XE-IV; Fri, 27 Apr 2007 13:49:21 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhUZM-0004X9-I2 for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 13:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUZM-0004X1-8N for lemonade@ietf.org; Fri, 27 Apr 2007 13:49:20 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUZK-00050S-UP for lemonade@ietf.org; Fri, 27 Apr 2007 13:49:20 -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 l3RHnAEA032262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Apr 2007 10:49:11 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3RHn83l026288; Fri, 27 Apr 2007 10:49:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Fri, 27 Apr 2007 10:49:08 -0700 To: LMM@acm.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org Subject: [lemonade] Review request for draft-ietf-lemonade-convert-06.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 Hi Larry, During some recent discussion of this draft within LEMONADE, the idea of harmonizing these IMAP convert parameters with the media features registry came up. There seem to be a couple of ways to do that. One would be to keep the current focus on OMA-derived terms, and add those to the registry under the global tree as g.oma.$value. Another would be to shift the IMAP usage to the IETF registered values where they already exist (e.g. moving width and height to pix-x and pix-y, since those are pixel values in the current document) and registering new values where they do not. There are a couple of potential parameters that might be a tricky (the resize directive's crop, for example), but it still seems like it migh work. If you can review the document and provide advice to the group, it would be much appreciated. thanks, Ted Hardie _______________________________________________ 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 Apr 27 15:50:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWSu-0003ZI-Hm; Fri, 27 Apr 2007 15:50:48 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhWSf-00031m-Hj for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWSf-000311-3W; Fri, 27 Apr 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhWSe-0002Lt-Mz; Fri, 27 Apr 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8EEAB2ACB0; Fri, 27 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HhWSA-0002QW-AT; Fri, 27 Apr 2007 15:50:02 -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: Fri, 27 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-08.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 : The IMAP COMPRESS Extension Author(s) : A. Gulbrandsen Filename : draft-ietf-lemonade-compress-08.txt Pages : 9 Date : 2007-4-27 The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-08.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-compress-08.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-compress-08.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-4-27112208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-compress-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-compress-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-27112208.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 Sun Apr 29 18:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiHxf-0005SR-4U; Sun, 29 Apr 2007 18:33:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhIYV-0006X8-Am for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 00:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhIYU-0006X0-VJ; Fri, 27 Apr 2007 00:59:38 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhIYT-0000Tn-K6; Fri, 27 Apr 2007 00:59:38 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Thu, 26 Apr 2007 23:59:38 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Thu, 26 Apr 2007 23:59:37 -0500 To: IETF-POP3EXT:;, IETF-IMAPEXT:;, IETF-SMTP:;, LEMONADE:;, IMA:; From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Sun, 29 Apr 2007 18:33:41 -0400 Subject: [lemonade] Fwd: draft-resnick-2822upd-01 posted 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 Please follow the discussion on ietf-822@imc.org. --- begin forwarded text Date: Thu, 26 Apr 2007 16:55:06 -0500 To: ietf-822@imc.org From: Pete Resnick Subject: draft-resnick-2822upd-01 posted You may have noticed that 2822upd-01 was posted. Also: To make rfcdiff work, I've put a copy of RFC 2822 on my web site with some of the later sections rearranged so that they're in the same order as the current draft. You can see the diffs between the two here: Though overall very few, there are real changes from 2822 in this document that need review. See the changes section at the bottom. I did *not* go whole hog and switch to Bruce's syntax, simply because I wanted to limit the number of changes and see if we can't get this thing to Draft along with 2821bis. But I did incorporate (hopefully all of) the corrections that you all have pointed out over the last couple of years. Please review with a fine toothed comb. If there are more than just a few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who have at assorted time offered assistance) to start an issues list. Thanks in advance for your assistance. pr --- end forwarded text -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ 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 Sun Apr 29 18:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiHxf-0005SR-4U; Sun, 29 Apr 2007 18:33:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhIYV-0006X8-Am for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 00:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhIYU-0006X0-VJ; Fri, 27 Apr 2007 00:59:38 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhIYT-0000Tn-K6; Fri, 27 Apr 2007 00:59:38 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Thu, 26 Apr 2007 23:59:38 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Thu, 26 Apr 2007 23:59:37 -0500 To: IETF-POP3EXT:;, IETF-IMAPEXT:;, IETF-SMTP:;, LEMONADE:;, IMA:; From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Sun, 29 Apr 2007 18:33:41 -0400 Subject: [lemonade] Fwd: draft-resnick-2822upd-01 posted 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 Please follow the discussion on ietf-822@imc.org. --- begin forwarded text Date: Thu, 26 Apr 2007 16:55:06 -0500 To: ietf-822@imc.org From: Pete Resnick Subject: draft-resnick-2822upd-01 posted You may have noticed that 2822upd-01 was posted. Also: To make rfcdiff work, I've put a copy of RFC 2822 on my web site with some of the later sections rearranged so that they're in the same order as the current draft. You can see the diffs between the two here: Though overall very few, there are real changes from 2822 in this document that need review. See the changes section at the bottom. I did *not* go whole hog and switch to Bruce's syntax, simply because I wanted to limit the number of changes and see if we can't get this thing to Draft along with 2821bis. But I did incorporate (hopefully all of) the corrections that you all have pointed out over the last couple of years. Please review with a fine toothed comb. If there are more than just a few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who have at assorted time offered assistance) to start an issues list. Thanks in advance for your assistance. pr --- end forwarded text -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ 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 Sun Apr 29 18:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiHxf-0005Se-8Z; Sun, 29 Apr 2007 18:33:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhcAI-0004QE-G5 for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 21:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhcAH-0004Px-FS for lemonade@ietf.org; Fri, 27 Apr 2007 21:55:57 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhcAF-0004MZ-4B for lemonade@ietf.org; Fri, 27 Apr 2007 21:55:57 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Apr 2007 18:55:49 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3S1tlSd006512; Fri, 27 Apr 2007 18:55:47 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3S1tk0c019139; Fri, 27 Apr 2007 18:55:47 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 18:55:45 -0700 Received: from masinterlap06 ([10.7.242.104]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 18:55:45 -0700 From: "Larry Masinter" To: "'Ted Hardie'" References: In-Reply-To: Date: Fri, 27 Apr 2007 18:55:45 -0700 Message-ID: <001d01c78938$55e9fb80$01bdf280$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceI9GFZIr6v11CVTg+bRNMOQkE+2gAP5elA Content-Language: en-us X-OriginalArrivalTime: 28 Apr 2007 01:55:45.0577 (UTC) FILETIME=[55E7B190:01C78938] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Sun, 29 Apr 2007 18:33:41 -0400 Cc: lemonade@ietf.org Subject: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.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 On the specific question of whether it is reasonable to re-use existing IETF registered values, well, I don't see any reason not to, if they're being used with the same meaning. But my broader concern is that the sets of values chosen don't really seem to match what's necessary to be effective. >From a content creation point of view, it seems like you need to know a lot more, and I'm not sure why content conversion would be different. At least, that seems to be the tone of W3C work in this area, e.g., http://www.w3.org/TR/DDR-requirements http://www.w3.org/2005/MWI/DDWG/ which is ongoing, and even of commercial products in this area (http://www.adobe.com/products/creativesuite/devicecentral/). In general, I think coordinating IMAP with web access mechanisms is a good idea, even if the web work isn't happening in the IETF. Larry _______________________________________________ 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 Sun Apr 29 18:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neu star.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiHxf-0005Se-8Z; Sun, 29 Apr 2007 18:33:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HhcAI-0004QE-G5 for lemonade-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 21:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhcAH-0004Px-FS for lemonade@ietf.org; Fri, 27 Apr 2007 21:55:57 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhcAF-0004MZ-4B for lemonade@ietf.org; Fri, 27 Apr 2007 21:55:57 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Apr 2007 18:55:49 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3S1tlSd006512; Fri, 27 Apr 2007 18:55:47 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3S1tk0c019139; Fri, 27 Apr 2007 18:55:47 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 18:55:45 -0700 Received: from masinterlap06 ([10.7.242.104]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 18:55:45 -0700 From: "Larry Masinter" To: "'Ted Hardie'" References: In-Reply-To: Date: Fri, 27 Apr 2007 18:55:45 -0700 Message-ID: <001d01c78938$55e9fb80$01bdf280$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceI9GFZIr6v11CVTg+bRNMOQkE+2gAP5elA Content-Language: en-us X-OriginalArrivalTime: 28 Apr 2007 01:55:45.0577 (UTC) FILETIME=[55E7B190:01C78938] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Sun, 29 Apr 2007 18:33:41 -0400 Cc: lemonade@ietf.org Subject: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.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 On the specific question of whether it is reasonable to re-use existing IETF registered values, well, I don't see any reason not to, if they're being used with the same meaning. But my broader concern is that the sets of values chosen don't really seem to match what's necessary to be effective. >From a content creation point of view, it seems like you need to know a lot more, and I'm not sure why content conversion would be different. At least, that seems to be the tone of W3C work in this area, e.g., http://www.w3.org/TR/DDR-requirements http://www.w3.org/2005/MWI/DDWG/ which is ongoing, and even of commercial products in this area (http://www.adobe.com/products/creativesuite/devicecentral/). In general, I think coordinating IMAP with web access mechanisms is a good idea, even if the web work isn't happening in the IETF. Larry _______________________________________________ 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 Apr 30 05:30:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSCr-0004WW-Bi; Mon, 30 Apr 2007 05:30:05 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiSCp-0004Vz-8h for lemonade-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 05:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSCo-0004Vr-Sf for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:02 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiSCm-00018h-Fd for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:02 -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 ; Mon, 30 Apr 2007 10:29:59 +0100 Message-ID: <46337280.3030503@isode.com> Date: Sat, 28 Apr 2007 17:12:48 +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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis) References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org 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 wrote: >23. Clarification needed in section 6.1.2 paragraph 4. What is "submit+", what is a "access identifier prefix" and what is a "userid" - these have not been mentioned before, and these are not in the ABNF either. > > Actually they are: access = ("submit+" enc-user) / ("user+" enc-user) / "authuser" / "anonymous" >Same question for "user+", "authuser" in the following paragraphs. > > I've changed "access" to "" in several places to make this clearer. [...] >25. General comment to section 6: an example or two would be nice. > Added. _______________________________________________ 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 Apr 30 05:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSD1-00051Z-HF; Mon, 30 Apr 2007 05:30:15 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiSD0-0004zm-Re for lemonade-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 05:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSD0-0004yY-GK for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiSD0-0001BP-4u for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:14 -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 ; Mon, 30 Apr 2007 10:30:09 +0100 Message-ID: <463380EB.4030204@isode.com> Date: Sat, 28 Apr 2007 18:14:19 +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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis) References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: lemonade@ietf.org 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 wrote: >9. Clarification needed in section 3.2 paragraph 3: Shouldn't this be moved in from the previous paragraph? That talks about what happens when there no user name, so it would seem logical to use the user name first, and then if there no user name, use anonymous instead. > The 3rd paragraph used to be a part of the 2nd paragraph in RFC 2192. As it summarizes what is described in subsequent paragraphs, I think the best thing is just to delete it. Otherwise it might be interpreted as conflicting with some of them. >10. Clarification needed in section 3.2 paragraph 5: "If no user name is specified, one SHOULD be obtained from the mechanism or requested from the user as appropriate." > >Is this really a SHOULD? When AUTH is used I would not expect anonymous to be used, therefore the user MUST have a user name. The next paragraph seems to give some more info on this, but not really: it looks like a client is allowed to send anonymous AUTH. > After talking to Chris, I've decided to change the last SHOULD to a MUST. You are right, a username must always be available. Either from the mechanism (for SASL EXTERNAL, GSSAPI or ANONYMOUS), or from user/configuration. [...] >14. Clarification needed in section 3.2 paragraph 9: "Note that user entry of the URL may or may not count as a trusted source, depending on the experience level of the user and site policy." >How can the "experience level of the user" govern whether the source is trusted? Sounds awfully wrong - things should be secure in any case. >How does one calculate the "experience level of the user" and what counts as a "safe" level? > This might be impossible to code, but the text is correct. I would not trust my mother to understand the difference between "user@pay-pal.com" and "user@paypal.com". >I thought bullet (3) would cover the user's mistakes. > > People automatically hit Ok button way too often, so explicit confirmation might help, but might not completely address the issue. [...] >17. Section 3.2 paragraph 10. > >I do not think that such authentication should be allowed. Why not force anonymous instead? > This is explained in the following text describing ;AUTH=*: If no user name is specified and no appropriate authentication mechanisms are available, the client SHOULD fall back to anonymous login as described above. This allows a URL which grants read-write access to authorized users, and read-only anonymous access to other users. >Well, at least this is hinted in the next paragraph with saying: "If a URL does not contain a user name or authentication mechanism, then only an anonymous connection may be re-used.", so which one is it? Allow omitting user name or force anonymous? I would prefer the latter. > Unless there is strong consensus from the WG to change the behavior described in RFC 2192, I would leave this text as is. _______________________________________________ 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 Apr 30 05:30: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 1HiSD5-00055j-7j; Mon, 30 Apr 2007 05:30:19 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiSD3-00055L-Kc for lemonade-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 05:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSD3-00054W-9O for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:17 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiSD2-0001D8-0X for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:17 -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 ; Mon, 30 Apr 2007 10:30:11 +0100 Message-ID: <463488C8.6080002@isode.com> Date: Sun, 29 Apr 2007 13:00:08 +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 MIME-Version: 1.0 To: Lemonade WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [lemonade] CONVERT: conversion between character sets 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 After thinking more about the issue of conversions between charsets when data loss occurs: I suggest we add a new parameters "replace-unknown-characters". When this parameter is not specified, textual conversions that would result in loss of characters would fail. But if this parameter is specified, then the conversion wouldn't fail and all characters that can't be represented in the target charset will be replaced with '?' or similar. Any objections? _______________________________________________ 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 Apr 30 05:30:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSD6-00058O-E6; Mon, 30 Apr 2007 05:30:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiSD5-00058J-Kf for lemonade-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 05:30:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSD4-00055i-LM for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:19 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiSD3-0001D8-C1 for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:18 -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 ; Mon, 30 Apr 2007 10:30:12 +0100 Message-ID: <46348B60.2080008@isode.com> Date: Sun, 29 Apr 2007 13:11:12 +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: Randall Gellens References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org Subject: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.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 Randall Gellens wrote: > Section 8: [...] > OLD: > NO response should be returned > > NEW: > NO response SHOULD be returned > But why is this a SHOULD? What are the server's other choices? The > next paragraph says to use NO for permanent errors. I agree it would > be helpful to let the client know if the error is permanent or > temporary, so the client knows to retry later or not. Something like > "NO [TEMPFAIL]", or an additional TEMPFAIL extension response code > later in the section? I've changed the text to say "MUST return NO [TEMPFAIL]". I also rewrote the text to show more examples on when TEMPFAIL should be returned. > ---------- > OLD: > Otherwise, the server should return an OK response > > NEW: > Otherwise, the server SHOULD return an OK response I think it would be better to rewrite the sentence to avoid SHOULD: Otherwise, the server returns an OK response. _______________________________________________ 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 Apr 30 05:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSDF-0005CE-Mn; Mon, 30 Apr 2007 05:30:29 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiSDE-0005C9-GN for lemonade-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 05:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSDE-0005C1-6L for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:28 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiSDC-0001EQ-To for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:28 -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 ; Mon, 30 Apr 2007 10:30:13 +0100 Message-ID: <463496C4.70805@isode.com> Date: Sun, 29 Apr 2007 13:59:48 +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: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] CONVERT: SERVEROVERRIDE response code 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 I removed the SERVEROVERRIDE response code: SERVEROVERRIDE the server overrode the request parameters because it determined it could substitute better ones based on preferences, device capability knowledge, or server policy. Firstly, I don't that think the server should do that, except for the case when the client requested default conversion. Secondly, I don't think the response code as written provides enough information for the client to figure out what was overridden and how to modify the request to avoid such condition. If you disagree, please speak up now. _______________________________________________ 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 Apr 30 05:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSDU-0005aP-VN; Mon, 30 Apr 2007 05:30:44 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiSDT-0005Ut-KR for lemonade-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 05:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSDT-0005Sd-8r for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:43 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiSDR-0001Kt-Vf for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:43 -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 ; Mon, 30 Apr 2007 10:30:41 +0100 Message-ID: <46349D8D.9070808@isode.com> Date: Sun, 29 Apr 2007 14:28:45 +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: Randall Gellens References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org Subject: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.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 Randall Gellens wrote: > Section 8: > > OLD: > the server can reply > > NEW: > the server MAY reply The full sentence reads: Some transcodings may require parameters. If a transcoding request with no parameters is sent for a format which requires parameters, the server MAY reply with a NO response. > Do we want to say what the other server choices are? Use some default > values of its choosing? I think the server MUST return the tagged NO response. (If the server can use a default value, this would mean that the parameter is not required.) In order to allow the server to signal which parameters are expected, I've added a new MISSINGPARAMETERS response code. _______________________________________________ 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 Apr 30 05:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSDd-0005dN-52; Mon, 30 Apr 2007 05:30:53 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiSDc-0005dI-1m for lemonade-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 05:30:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiSDb-0005d8-OI for lemonade@ietf.org; Mon, 30 Apr 2007 05:30:51 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiSDa-0001Pc-Fr for lemonade@ietf.org; Mon, 30 Apr 2007 05:30: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 ; Mon, 30 Apr 2007 10:30:49 +0100 Message-ID: <4634A134.6030508@isode.com> Date: Sun, 29 Apr 2007 14:44: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 MIME-Version: 1.0 To: Lemonade WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [lemonade] CONVERT: .STRICT specifier (again) 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 I am somewhat hesitating to remove .STRICT specifier. Are there any cases when the client would like to specify a transcoding parameter that can be ignored by the server? _______________________________________________ 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 Apr 30 06:27:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiT6r-0001AT-Oz; Mon, 30 Apr 2007 06:27:57 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiT6q-0001AO-E8 for lemonade-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 06:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiT6q-0001AF-4d for lemonade@ietf.org; Mon, 30 Apr 2007 06:27:56 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiT6p-0002Hz-Lw for lemonade@ietf.org; Mon, 30 Apr 2007 06:27:56 -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 ; Mon, 30 Apr 2007 11:27:54 +0100 Message-ID: <4635C470.7070506@isode.com> Date: Mon, 30 Apr 2007 11:26:56 +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: Randall Gellens Subject: Re: [lemonade] Re: Comments on draft-ietf-lemonade-convert-06.txt References: <463078CD.9030002@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: lemonade@ietf.org 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 Randall Gellens wrote: > At 11:02 AM +0100 4/26/07, Alexey Melnikov wrote: > >> 2). Support for default conversion: >> >>> OLD: >>> the client can use a special marker NIL >>> >>> NEW: >>> the client MAY use a special marker NIL >> >> I don't want to use MAY, as the server might not support the special >> marker. More on this below: > > I think we can't make this optional. Either servers MUST support it, > or we drop the feature. More on this below. I rather keep it as a MUST. >>> Also, how does the client discover if the server provides such >>> support? >> >> Currently the client has to try to use it. If it receives a tagged NO >> response, then default conversion is not supported. > > I think that's a problem. The extra complexity this imposes on the > client outweighs the benefit of the feature, I think. Do you expect many clients will request the default conversion? >>> I think that the only use in providing this default conversion is >>> to support very simple clients. Thus, it doesn't make sense to make >>> this an option for servers, since the very clients that might need >>> it might also be too simple to have multiple code paths to handle it >>> not being available, and anyway, what is the client to do? If we >>> are going to include default conversions, I think they should be >>> mandatory for servers. >> >> If we make it mandatory for servers, we need to define how it can be >> implemented, at least in general purpose IMAP servers. I have no idea >> what the choices are, especially which choices are good. So as a >> server implementor I would need some guidance about implementing this >> feature. > > Providing this guidance is good, but I think it is a harder problem > then what we're trying to solve with this draft, so I'd say it should > be done elsewhere. You just confirmed my fear ;-). That was the reason why I initially made this feature optional. > We could compromise and add some clearly non-normative text that makes > general suggestions. For example, servers could keep a list of > supported destination media subtypes. If these are ranked according > to some guess as to how widespread client support is, or how difficult > rendering is, then the server can choose as a default conversion, > absent any information as to the client's specifics, the > highest-ranked non-identity subtype. If the server has information as > to what the client supports, it can pick the highest-ranked supported > subtype, or the specific client support information can include a ranking. I would like to have an informative paragraph about this. Can I ask you to write one (some rewording of the above will do)? >>> How the server decides remains out of scope, and we aren't >>> requiring the server to make good choices (that's a >>> quality-of-implementation thing), but this can't be an option. >> >> We don't want to encourage bad choices either. > > It's subjective which default conversions are good versus bad > choices. But it's objective that making default conversion optional > for servers complicates clients. So we should either make this > mandatory or drop it entirely. Ok. >>> It also doesn't seem to be any more of a burden to require the >>> server to pick something if it is going to support something. >> _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade