From mailman-bounces@ietf.org Mon Nov 1 06:55:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20903 for ; Mon, 1 Nov 2004 06:55:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COb1F-0005Fi-3o for lemonade-web-archive@ietf.org; Mon, 01 Nov 2004 07:10:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZSy-0002r8-40 for lemonade-web-archive@ietf.org; Mon, 01 Nov 2004 05:31:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: lemonade-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:11:46 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for lemonade-web-archive@ietf.org: List Password // URL ---- -------- lemonade@ietf.org ewunaw https://www1.ietf.org/mailman/options/lemonade/lemonade-web-archive%40ietf.org From lemonade-bounces@ietf.org Mon Nov 1 16:53:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08631 for ; Mon, 1 Nov 2004 16:53:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkML-00058r-Cr for lemonade-web-archive@ietf.org; Mon, 01 Nov 2004 17:09:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COjdF-00086h-LZ; Mon, 01 Nov 2004 16:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COivV-000107-8L for lemonade@megatron.ietf.org; Mon, 01 Nov 2004 15:37:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28224 for ; Mon, 1 Nov 2004 15:37:14 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COjAS-0002Fn-NA for lemonade@ietf.org; Mon, 01 Nov 2004 15:52:45 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA1KSF3o023404; Mon, 1 Nov 2004 15:28:18 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Nov 2004 15:25:24 -0500 Message-ID: From: Eric Burger To: "Stephane H. Maes" Subject: RE: [lemonade] WG last call on Goals Date: Mon, 1 Nov 2004 15:23:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 At this point, my overarching thought is, "some good stuff here, but will it materially add value or change the goals". Keep in mind that the IETF does protocols. The goals document provides a framework and sets the stage for the protocol. However, it will have absolutely no impact on the protocol. We leave it to groups like OMA and 3GPP to promote mobile services, hack together conventions of IETF standards for non-Internet usage, and address non-protocol issues such as billing or payload DRM. What I'm saying here is that with no disrespect to Kue, unless there is something glaringly wrong with the document, I would much rather focus the work group intellectual resources on the protocol documents. The goals document will not change the world. The protocol documents will. On to the comments: I fully agree with using the term "mobile" instead of "wireless". I fully agree that if profiling an existing protocol will not meet our requirements, we will adapt an existing protocol or create a new one. Note that by "new protocol", I mean one that targets the problem at hand. I MUST EMPHASIZE, this work group is NOT chartered to replace SMTP or IMAP, or make next generation versions of same. In addition, we WILL NOT adapt an existing protocol such that the semantics of the protocol change (the "will not break existing protocols" mantra). I agree that we should acknowledge the existence of NAT and firewalls. We should state goals that say we should be able to coexist with them. However, making accommodation for non-Internet deployments is outside the scope of the IETF. That means that we will NOT make an attempt to work around Byzantine enterprise deployments. On the comments relating to mobile messaging. We have this thing called Internet Mail. Note there is no such thing as Mobile Mail in the IETF. Our charter is to make Internet Mail work for mobile devices. Our charter is NOT to make Mobile Mail. My recollection of the discussion at the Interim in Dallas was there was neither consensus nor disagreement on the P-IMAP goals. We took them as the goals of P-IMAP. Can you be specific as to which goals are missing from the work group document? On the client notifications issue, we are NOT CHARTERED to address it. That does not mean it will not be addressed. However, rather than the W3C approach of boiling the ocean, which requires everything to be done at once, we take the approach of working on digestible pieces. Since notifications are wholly orthogonal to the rest of our work, let's keep this off the charter until after we get some of the more pressing work done. Do keep the following in mind: - Billing, charging, DRM, etc. are for the most part out of scope for the IETF - Eliminating SMTP is not a goal - There is no concept of a corporate e-mail server or service provider e-mail server. This is the Internet, where there are e-mail servers. Either you are part of the infrastructure or you are not. This is part of the "Internet Mail" discussion above. - The IETF for the most part creates protocols that meet the end-to-end principal. One result of this is we try to create protocols that do not REQUIRE intermediaries. Of course, one is always free to insert intermediaries if you feel like it. However, the IETF rarely does architectures. A better place to build non-Internet protocols that require intermediaries is one of the industry fora. Four pages of comments is excellent! Good work. More in-line. > -----Original Message----- > From: Stephane H. Maes [mailto:stephane.maes@oracle.com] > Sent: Monday, October 25, 2004 11:12 PM > To: lemonade@ietf.org > Cc: Glenn Parsons; eburger@brooktrout.com > Subject: RE: [lemonade] WG last call on Goals > > > Please find attached comments to draft-ietf-lemonade-goals-04.txt. > > Sorry if long and sometimes repetitive... I think some aspect > still warrant more discussions. > > Thanks > > Stephane > > ------------ > > 1. Introduction - Motivation > > The draft draft-ietf-lemonade-goals-04.txt is in WG last call > status. The present document provides detailed comments. > 2. Mobile e-mail aspects > > Based on lessons learned with mobile e-mail we believe that > some additional discussion on mobile e-mail should be added. > These considerations were accumulated while working on actual > mobile e-mail deployments, analyzing the gamut of existing > solutions from different vendors, developing, implementing > and deploying P-IMAP (draft-smaes-lemonade-p-imap-05.txt) as > well as participating to the OMA (Open Mobile Alliance) > Mobile E-mail activity > (http://member.openmobilealliance.org/ftp/Public_documents/REL > /WP/Summary_WISPR_statusPage4.html). > > To that effect, I would like to suggest considering adding > material from the following: > - Discussion of mobile issues and use cases were > presented in the Dallas/Richardson intermediary Lemonade FTF > meeting (59.5): > http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-D raft_Overview_Draft.ppt (slide 2 to 5). > - More details on the challenges and mobile specific > issues that are presented in > draft-smaes-lemonade-mobile-email-01.txt. > > See also draft-smaes-lemonade-s2c-notification-reqs-00.txt. > > We believe that these use cases, requirements and issues > should be discussed in more details in the Lemonade goals draft. Which ones, specifically? > 3. Detailed comments > This section provides more specific comments section by section. > 3.1 Comments to the abstract section > > >> In particular, by clients on hosts not only operating in > environments > >> with high latency/bandwidth-limited unreliable links but also > >> constrained to limited resources. << > > While this is correct, I think that we should explicitly > recognize the other challenges met in mobile environment (see > for example draft-smaes-lemonade-mobile-email-01.txt). So I > would like to state: > > =>>... but also constrained to limited resources or > limitations imposed by mobile networks properties and > deployment models.<<= > > >> The enhanced mail must continue to support the existing service as > >> before. << > > This is an unclear statement. I would challenge that in some > cases there is no possible (open standard) service in some > cases / environment. It should be clarified to acknowledge > that fact and to explain that the statement is probably more > a statement in terms of interworking between new use and > existing mail services etc... Ummm. Isn't addressing what can't be done today the point of the work group? > >> The primary motivation for this effort is -- by making > Internet mail > protocols richer and more adaptable to varied media and > environments << > > It is not clear that extending the protocol is always > suitable (e.g. mobile). Instead we should rather state: > > =>> The primary motivation for this effort is to make > Internet mail protocols more adaptable and optimizable to > varied media and environments <<= A bit of politics here: we will never trade-off optimization for functionality. Stating a preference for optimization will raise flags that don't need to be raised. > >> ... to allow their use by handheld devices to wirelessly access > Internet mail without intermediation.<< > > I thought that Lemonade had a much broader scope than mobile > only. Should the text be changed accordingly to expand the scope > > I recommend changing wireless to mobile. Yes and yes. > I strongly disagree with the limitation implied by "without > intermediation". This is not something that has been > justified (yet t at least in my mind) and it is in > contradiction with most common current models (see > draft-smaes-lemonade-mobile-email-01.txt). It could also be > construed as contradicted by the voice mail solution later > described. These two words should be removed from the text. > > The goal document is a pre-requirement document. It can't > make such decisions in advance. I realize that we may have a > problem in the sense that we are designing solution before > completing appropriately use cases, requirements etc... But > in any case this restriction is too preliminary. See introductory comments. > 3.1.1 Last paragraph of Abstract > > This section seems outdated, at least based on the > discussions and work that I have seen taking place at > Lemonade in the last year. The size of the paragraph seems to > imply a much bigger role that what it has. I suggest updating > and reducing and adding a section on mobile e-mail; noting > that mobile messaging is not mobile e-mail. > > Also if voice mail and other cases are to be supported, they > should be mentioned in the Abstract... They are not. Sounds good. > > 3.2 Comments on introduction > > The introduction is missing a discussion on mobile e-mail: > - Existing demand (enterprises, operators and even > consumers), numerous technical solutions, growing adoption OK for OMA, 3GPP, 3GPP2, but irrelevant for IETF > - Challenges > - Need to offer an open standard solution that based on > enhanced internet mail or at least appropriately interworking with it. Open standard, INTERNET solution. If it won't work on the Internet (scale, interoperability, architecture, security assumptions), then the IETF isn't the right place to do the work. We believe we can achieve Internet robustness and still address the needs of users and operators. However, if we violate Internet principles, we won't get very far with the protocols. > While messaging clearly includes e-mail; when referring to > mobile messaging and when reading the draft so far, messaging > rather refers to alternate messaging methods like SMS, MMS > etc instead of e-mail. So wording to clarify this should be > added. But clearly, we would like to see also the text > discussing the need to provide open standard ways to address > the challenges of mobile e-mail (see > draft-smaes-lemonade-mobile-email-01.txt) and associated use > cases (see > http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-D raft_Overview_Draft.ppt (slide 2 to 5)). > > Similarly and to avoid confusion, instant messaging should be > positioned with respect to the Lemonade goals. sounds OK. which challenges in particular? > 3.2.1 Section on "This document [...] in other contexts" > > There may be some confusions and lack of clarities with the > concept of WUI, Mobile messaging Multi-modal and Mobile e-mail. > > - WUI is a client on a mobile / wireless device > > - WUI may differ for mobile messaging (SMS, MMS, IM, ...), > and mobile e-mail > > - Different agents (WUI, TUI, ...) may be involved in > multi-modal messaging. It is not a subset of WUI; but WUI may > be used to provide multi-modal messaging... > > - The multimodal messaging should refer to the multimodal and > multi-device work at OMA that explicitly address and explains > how agents are combined to provide that desired multimodal > effect and more. After all, this work better be consistent > with the OMA specifications on this... It may also be good to > refer to the W3C MMI work if multimodal messaging was t be > treated as a separately authored multimodal application. > > - The notion of mobile e-mail client / functionality should > be explicitly listed, where mobile e-mail is defined in > draft-smaes-lemonade-mobile-email-01.txt as: access to e-mail > while mobile. > > 3.2.2 Comments on Last bullet list > > Please add: > > - Issues related to mobile e-mail > > > [And a section should be added. This could be based on the > document discussed earlier (See section 2. Mobile e-mail aspects) > > 3.3 Comments to section 3 > 3.3.1 Comments to section 3.2.2 > > We believe that it is important to recognize and document the > notions of inband versus outband notifications. > > We also believe that it is important to recognize that while > the internet mail in general has not identified the need for > notifications. However, mobile e-mail as discussed in > draft-smaes-lemonade-mobile-email-01.txt) with associated use > cases (see > http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-D raft_Overview_Draft.ppt (slide 2 to 5)) and in > draft-smaes-lemonade-s2c-notification-reqs-00.txt. Therefore > the draft should identify to reconcile this difference > between "internet mail" and the need of mobile e-mail. > Addressing this is a goal of Lemonade... Out of scope for now. > 3.4 Comments to section 4 > > A problem that I think plague some of the discussion that we > are having for example around mobile e-mail is at the level > of what it means to: > - Define a profile of internet mail > - Extend internet mail to other environments. > > Among the confusion is the difference and confusion already > mentioned in these comments between: > - i) Using internet mail as is and adding capabilities > and > - ii) Extending internet mail and way it is used to allow > appropriate extension of capabilities and optimize use or > support use cases in the new environment. > > We recommend that the work and goals of Lemonade include ii) > and not just i). We believe that for example supporting > server to client notifications is needed in such a context > and may require accepting ii). The same holds for deployment > use cases. See discussion above. > 3.4.1 Comments to section 4.2.2 > > This is a repeat of the comments made in section 4.1.1. > (Comments to "This document [...] in other contexts"): > - The Multi-modal client should refer and state a goal to be > reconciled with the OMA multimodal and multi-device > specifications and the W3C MMI WG specifications (both sets > are currently consistent among each others). > > 3.4.2 Comments to section 4.2.3 > > As already discuss in section 4.1.1. (Comments to "This > document [...] in other contexts"), we should account for > different clients for the different functions that it must > perform. It is confusing and frankly not required nor > realistic considering the current state of mobile clients to > expect a unified client. > > We also recommend to change the name from wireless to mobile > [This is a general comment across the whole draft]. > > We would like to see a discussion of a mobile e-mail > functionality that is currently missing from the draft and > from the notion of WUI. > > 3.4.3 Additional comments on WUI / Multimodal figure > > Similarly, the figure that depicts the multimodal clients is > not consistent with the OMA multimodal and multi-device > enabler architecture document or the W3C architecture drafts: > it misses the functionality of interaction / multimodal > synchronization manager consistently identified by both > activities. We should re-think what we write it this section, > especially as no work seems to have really completed on this > at Lemonade. What would be affected? Sounds like a ton of work. Would it materially impact our work? If not, I'd leave it out / unsaid as being way out of our scope of work and our scope of expertise. > In addition, we believe that the figure may not be suitable > in general for mobile e-mail where the "logical" picture is > closer to what is discussed in > draft-smaes-lemonade-mobile-email-01.txt (see also the > presentation given in Vancouver intermediate Lemonade FTF > meeting (60.5): > http://www1.ietf.org/mail-archive/web/lemonade/current/pptdErK > weWZk5.ppt). Accordingly, IETF standard protocol may be > actually the mobile e-mail protocol as is RFC 822/MIME for > retrieval and submission. Notifications are also missing as > are notification. > > An option to progress is to keep section 4.2.3 as is (taking > account the comments of first 3.4.2 Comments to section 4.2.3 > and first paragraph above) and adding a section on mobile > e-mail client. > > 3.5 Comments to section 5 > > I am rather positive and comfortable with the principle > enumerated in section 5. However, I would like to see mobile > e-mail added to the list of the topic covered by the principle. > > 3.5.1 Comment to section 5.1.1 and 5.1.2 > > [Analysis rather comment - The editor may decide if this > should be further explained in the draft of > draft-ietf-lemonade-goals-0x.txt] It should be however that > when in section 5.1.2 we state that we will not break > existing protocols, this does not imply that only new > functionalities are added to existing protocols. New > protocols and interworking mechanisms are also within scope > if they can't be satisfied by existing protocols. > > 3.5.2 Comment to section 5.3 > > [Analysis rather comment - The editor may decide if this > should be further explained in the draft of > draft-ietf-lemonade-goals-0x.txt] > > I agree with the principle. However, again it must be clear > that this is not preventing new infrastructure when new > functionality is needed. > > It should also be clear that having all extensions backward > compatible may be achieved with a protocol that supports IMAP > and a different protocol provided that IMAP client can > interface with the system and new devices can exploit the > additional features. > > Intermediaries as discussed in > draft-smaes-lemonade-mobile-email-01.txt should be covered > and compatible with this principle. They provide a way to > support the backward compatibility and progressive support of > features. [End of analysis] If an intermediary is transparent to the protocol, we have nothing to say, positive or negative. Let's not say anything. If an intermediary is key to the protocol, then we need to examine the protocol closely. > > >>Messages created in an enhanced messaging context MUST NOT require > >>changes to existing mail clients.<< > > I agree with this and it should also apply to mobile e-mail. > But it is important to understand what it means. In the case > of mobile e-mail, email generate outside the mobile context > MUST be received / used by mobile e-mail client (by design) > and email generated by mobile clients MUST be received / used > by e-mail clients without any changes. > > The statement should be extended to email servers to state > that email server MUST be able to send, receive, handle > emails to and from mobile e-mail client without changes of > specifications. That does not mean however that it may not > involve intermediaries as discussed in > draft-smaes-lemonade-mobile-email-01.txt. And it will require intermediaries if the source isn't Internet mail, but something like SMS or MMS. > >> However, there may be a degradation in functionality in certain > >> circumstances.<< > > For mobile e-mail, we believe that this is not an appropriate > statement. Mobile e-mail does not call for degradation of > functionality but instead for full support of the > requirements / user cases / user experience expected. This > statement should be rephrased so that support across > different messaging context may imply degradation in > functionality BUT when it come to mobile e-mail, full support > of the mobile email functionalities (that differs from > internet mail as it is today). Keep in mind we're engineers and not marketing folks. We all can agree that today's mobile e-mail is *different* from Internet mail. I also think most of us can agree that today's mobile e-mail, because of the nature of mobile (low bandwidth, high latency, intermittent connectivity), isn't quite the service that Internet mail offers. Most people would call that service degradation. Tell your marketing folks that we are not bashing mobile messaging. All we're doing is explaining why we're undertaking this task in the first place. > 3.5.3 Additional comment > > A section should be added on mobile e-mail requirements > inspired from > http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-D raft_Overview_Draft.ppt (slide 2 to 5), draft-> smaes-lemonade-mobile-email-01.txt and > draft-smaes-lemonade-s2c-notification-reqs-00.txt. > > 3.6 Comments on section 7 > > The comment requiring extension of WUI to include mobile > e-mail applies. > > The recommendation to rename WUI to "mobile" UI still holds > > In general this should be run against > http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-D raft_Overview_Draft.ppt (slide 2 to 5), draft-> smaes-lemonade-mobile-email-01.txt and > draft-smaes-lemonade-s2c-notification-reqs-00.txt and > completed as needed. > > A section in the draft should address the need of enterprise. > > 3.6.1 Comments to section 7.1 > > Please add the other considerations on transport challenges > mentioned in draft-smaes-lemonade-mobile-email-01.txt section > 2.2 (and may be aspect of 2.3)(e.g. loss of IP address, loss > of sessions, control of exchanged data, .) > 3.6.1.1 Comments to section 7.1.3 > > Please add the other considerations on Wireless Bandwidth and > Network Utilization Considerations mentioned in > draft-smaes-lemonade-mobile-email-01.txt section 2.2/2.3 > (e.g. walled garden, regulation, firewalls,.) > > 3.6.2 Comment to sections 7.1.4.2 to 7.1.4.4 > Please add the other considerations on device limitations > mentioned in draft-smaes-lemonade-mobile-email-01.txt section > 2.1 (e.g. closed / controlled platform, .). > > Note that these sections are not about content display > considerations but about devices capabilities. It would be > less confusing if the title of 7.4 was changed to device capabilities. > > 3.6.3 Comments to section 7.2 > > The section should be renamed to "mobile e-mail". > > It should add all requirements discussed in > http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-D raft_Overview_Draft.ppt (slide 2 to 5), draft-> smaes-lemonade-mobile-email-01.txt and > draft-smaes-lemonade-s2c-notification-reqs-00.txt and > explicitly identify that it must address the challenges > identified in draft-smaes-lemonade-mobile-email-01.txt (by > providing at least supporting technologies) > > Example of missing discussion items: > - Need for notifications out of charter scope > - Need to support of firewalls acknowledge them and try to work with them > and associated sometimes very > conservative corporate policies way out of scope. We aren't in the business of codifying anti-Internet architectures. We will do our best to educate the corporate world the benefits of being part of the Internet. However, we will not break the Internet to satisfy the perceived needs of folks not fully implementing real security. > - Need to support mobile network limitations (e.g. no > session, often disconnected, no fixed IP, non-internet > features / capabilities / limitations) Yep > - Mobile deployment models > (http://www1.ietf.org/mail-archive/web/lemonade/current/pptdEr > KweWZk5.ppt and draft-smaes-lemonade-mobile-email-01.txt). > - ... > > 3.7 Comments to section 8 > > Again, this should include a discussion of mobile e-mail. It > should include a section that discuss a mobile e-mail > protocol as in > http://www1.ietf.org/mail-archive/web/lemonade/current/pptdErK > weWZk5.ppt and draft-smaes-lemonade-mobile-email-01.txt. > > 3.7.1 Comment to section 8.2 > > I do not agree with having sentence "Client-to-server > notification is not within the LEMONADE Charter" in the goals. > > 1) We need to discuss and agree on the fact that this would > not be a goal. It is a goal in my view as discussed earlier > 2) It is not clear that it is not within the charter. In > other words, the charter may be self contradictory if the > required extensions actually require notification. > 3) Goal and charter are not necessarily the same thing. If it > happens that Lemonade can not provide client to server > notification based on "charter issues" that may not be > resolvable, the goal of Lemonade is to provide a protocol > that can be used in conjunction with such notifications that > can be specified elsewhere. > > The sentence should be removed and we should state that > lemonade will analyze the need for client to server > notification and will either address them or interwork with them. Way too late for this. The charter is the charter. The work group chairs are not up to that battle at this time. We can re-address this issue once we make significant progress on our current document set. > > 3.8 Comment to section 8. > 3.8.1 Comments on section 8.4 > > Additional consideration are presented in section 2.2 of > draft-smaes-lemonade-mobile-email-01.txt (e.g. DRM, Charging, .) Out of scope. > The need and concerns of operators with respect to mobile > e-mail should be addressed somewhere in the draft. This > section solely focus on other mobile messaging. > > 3.9 Comments to security issues. > > Add the considerations presented in in terms of: > - intermediaries / proxies and end-to-end security > - intermediate storage > - deployment models > - spam Do you have text for these issues? Thanks again for your close look at this document! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 1 21:21:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04460 for ; Mon, 1 Nov 2004 21:21:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COoXt-00044v-CP for lemonade-web-archive@ietf.org; Mon, 01 Nov 2004 21:37:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COoET-0004LY-Q1; Mon, 01 Nov 2004 21:17:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnwS-0002mK-C1 for lemonade@megatron.ietf.org; Mon, 01 Nov 2004 20:58:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02765 for ; Mon, 1 Nov 2004 20:58:33 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COoBS-0003a4-Iq for lemonade@ietf.org; Mon, 01 Nov 2004 21:14:07 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iA21wWg3024091 for ; Mon, 1 Nov 2004 19:58:32 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <4M3FJN4A>; Mon, 1 Nov 2004 19:58:32 -0600 Message-ID: <54E40201497DF142B06B27255953F797050E522C@il0015exch007u.ih.lucent.com> From: "White, Gregory (Gregory)** CTR **" To: "'lemonade@ietf.org'" Subject: FW: [lemonade] WG last call on future delivery Date: Mon, 1 Nov 2004 19:58:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Hi all, Please accept my apologies for not responding to the list sooner... This letter responds to the issues raised in Arnt's posting on 10/25 = (attached to this letter): 1) I have read all of the commentary on the 1*9DIGIT vs 1*DIGIT, and = to be honest, I didn't put as much thought into it as everyone else = has. I picked 1*9DIGIT because that is how it is done in RFC 2852 = (Deliver By SMTP extension), which Greg V. instructed me to use as a = starting place for this draft. Both the by-value (value of BY parm on = the MAIL command) and min-by-time (value supplied with DELIVERBY = keyword in EHLO response) are 1*9DIGIT. Also, I note that RFC 3885 = (MTRK SMTP extension) defines mtrk-timeout (an optional part of the = MTRK parm of the MAIL command) as 1*9DIGIT. =20 So, my thought was to keep similiar things consistent across all of the = SMTP extensions. What I got from the the discussion was that is was OK = to leave the affected values in this draft as 1*9DIGIT; is this still = true? 2) I agree; however, my choice is "should not" (not CAPITIALIZED by = design). Note that there is no use of capitialized requirement = terminology in Section 3. My intent of this section is to describe, = in a "prose-y" way, how an SMTP session using FUTUREDELIVERY would = flow. The behavior section uses the capitialized terminology. I = believe that paragraph 1) of section 3.2.1 makes the same statement as = the first paragraph of section 3 (although 3.2.1.1 is written in terms = of MUST instead of MUST NOT).=20 How does this sound to everyone? 3) You are correct; the intention is that only authorized clients are = allowed to use future delivery, and I see your point re. anonymous = authorization. This was added at Greg V.'s behest, and the related = security concerns are the only reason I can think of, off the top of my = head, to have the requirement. I should defer to Greg V. on this issue....Greg, do we absolutely need = the AUTH extension? Greg White -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] Sent: Monday, October 25, 2004 9:16 AM To: lemonade@ietf.org Subject: Re: [lemonade] WG last call on future delivery Glenn Parsons writes: > Folks, > > A two week last call period is open until midnight EDT Nov 7th on: > > SMTP Submission Service Extension for Future Delivery > > > Please forward any comments on this document to the WG mailing list. Three points, all fairly minor. 1. Why 1*9DIGIT? Doesn't that mean that the delay is limited to=20 999999999 seconds? What makes this limit better than, say, 99999999 or=20 9999999999? I'd prefer not to have that limit unless there is a particular reason=20 for it, so I suggest changing to 1*DIGIT. 2. In section 3, first paragraph, the document says that =ABSMTP = clients=20 will not use Future Delivery on this MSA=BB. I suggest using SHOULD NOT = or MUST NOT. Either is fine with me. 3. The document apparently intends that only authenticated clients can=20 use future delivery. It doesn't say so. What it says is that the AUTH=20 command must succeed. But RFC2245 lists one way to have AUTH succeed=20 without really being authenticated, and (in theory) there may be other=20 ways in the future. One way to reword would be to talk about SASL authorization IDs. =ABThe = server SHOULD accept MAIL...AFTER only when the SMTP client has been=20 tied to a known SASL authorization ID.=BB But I wonder - why is this necessary? The document does not offer much=20 of a rationale for this requirement. The mentioned security concern=20 could be handled using a quota for anonymous/unauthenticated users. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 08:45:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20020 for ; Tue, 2 Nov 2004 08:45:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COzDQ-0001sU-OJ for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 09:00:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COyvA-0005GJ-Ur; Tue, 02 Nov 2004 08:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COyna-000256-VF for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 08:34:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19188 for ; Tue, 2 Nov 2004 08:34:09 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COz2i-0001bs-D8 for lemonade@ietf.org; Tue, 02 Nov 2004 08:49:48 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iA2DY8UK002197 for ; Tue, 2 Nov 2004 07:34:08 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <4M3FK2QR>; Tue, 2 Nov 2004 07:34:08 -0600 Message-ID: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: "White, Gregory (Gregory)** CTR **" , "'lemonade@ietf.org'" Subject: RE: [lemonade] WG last call on future delivery Date: Tue, 2 Nov 2004 07:34:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable On point 3, Future delivery is used only with the SMTP-Submit profile, = not general SMTP. The Submit profile is the place to address whether = authorization without authentication is sufficient for submission = services. I think it would be a diservice to have future delivery as a = extension available only in a sub-set of valid submission cases. My = take is that if submission is permitted, and future delivery is = advertized as supported, then future delivery should be permitted. Greg V. -----Original Message----- From: White, Gregory (Gregory)** CTR ** [mailto:gregwhite@lucent.com] Sent: Monday, November 01, 2004 8:58 PM To: 'lemonade@ietf.org' Subject: FW: [lemonade] WG last call on future delivery Hi all, Please accept my apologies for not responding to the list sooner... This letter responds to the issues raised in Arnt's posting on 10/25 = (attached to this letter): 1) I have read all of the commentary on the 1*9DIGIT vs 1*DIGIT, and = to be honest, I didn't put as much thought into it as everyone else = has. I picked 1*9DIGIT because that is how it is done in RFC 2852 = (Deliver By SMTP extension), which Greg V. instructed me to use as a = starting place for this draft. Both the by-value (value of BY parm on = the MAIL command) and min-by-time (value supplied with DELIVERBY = keyword in EHLO response) are 1*9DIGIT. Also, I note that RFC 3885 = (MTRK SMTP extension) defines mtrk-timeout (an optional part of the = MTRK parm of the MAIL command) as 1*9DIGIT. =20 So, my thought was to keep similiar things consistent across all of the = SMTP extensions. What I got from the the discussion was that is was OK = to leave the affected values in this draft as 1*9DIGIT; is this still = true? 2) I agree; however, my choice is "should not" (not CAPITIALIZED by = design). Note that there is no use of capitialized requirement = terminology in Section 3. My intent of this section is to describe, = in a "prose-y" way, how an SMTP session using FUTUREDELIVERY would = flow. The behavior section uses the capitialized terminology. I = believe that paragraph 1) of section 3.2.1 makes the same statement as = the first paragraph of section 3 (although 3.2.1.1 is written in terms = of MUST instead of MUST NOT).=20 How does this sound to everyone? 3) You are correct; the intention is that only authorized clients are = allowed to use future delivery, and I see your point re. anonymous = authorization. This was added at Greg V.'s behest, and the related = security concerns are the only reason I can think of, off the top of my = head, to have the requirement. I should defer to Greg V. on this issue....Greg, do we absolutely need = the AUTH extension? Greg White -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] Sent: Monday, October 25, 2004 9:16 AM To: lemonade@ietf.org Subject: Re: [lemonade] WG last call on future delivery Glenn Parsons writes: > Folks, > > A two week last call period is open until midnight EDT Nov 7th on: > > SMTP Submission Service Extension for Future Delivery > > > Please forward any comments on this document to the WG mailing list. Three points, all fairly minor. 1. Why 1*9DIGIT? Doesn't that mean that the delay is limited to=20 999999999 seconds? What makes this limit better than, say, 99999999 or=20 9999999999? I'd prefer not to have that limit unless there is a particular reason=20 for it, so I suggest changing to 1*DIGIT. 2. In section 3, first paragraph, the document says that =ABSMTP = clients=20 will not use Future Delivery on this MSA=BB. I suggest using SHOULD NOT = or MUST NOT. Either is fine with me. 3. The document apparently intends that only authenticated clients can=20 use future delivery. It doesn't say so. What it says is that the AUTH=20 command must succeed. But RFC2245 lists one way to have AUTH succeed without really being authenticated, and (in theory) there may be other=20 ways in the future. One way to reword would be to talk about SASL authorization IDs. =ABThe = server SHOULD accept MAIL...AFTER only when the SMTP client has been=20 tied to a known SASL authorization ID.=BB But I wonder - why is this necessary? The document does not offer much=20 of a rationale for this requirement. The mentioned security concern=20 could be handled using a quota for anonymous/unauthenticated users. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 09:22:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23585 for ; Tue, 2 Nov 2004 09:22:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COznc-0002iL-GP for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 09:38:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzXP-0005VQ-SA; Tue, 02 Nov 2004 09:21:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzOy-0001gX-12 for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 09:12:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22489 for ; Tue, 2 Nov 2004 09:12:46 -0500 (EST) Received: from libertango.oryx.com ([195.30.94.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COze0-0002Ux-B5 for lemonade@ietf.org; Tue, 02 Nov 2004 09:28:25 -0500 Message-Id: Date: Tue, 2 Nov 2004 15:15:12 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WG last call on future delivery References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.lucent.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c so, if I understand it correctly, 1) 1*9DIGIT stays. (Fine with me - I like consistency.) The special case 0 is then superfluous. It's the same as 999999999. 2) Is also OK. 3) The AUTH requirement goes. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 09:47:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25406 for ; Tue, 2 Nov 2004 09:47:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0Be-0003Eo-ID for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 10:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzkL-0002UC-Pf; Tue, 02 Nov 2004 09:34:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzhl-00010T-KB for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 09:32:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24330 for ; Tue, 2 Nov 2004 09:32:12 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COzwt-0002sE-CJ for lemonade@ietf.org; Tue, 02 Nov 2004 09:47:51 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 2 Nov 2004 14:31:32 +0000 Message-ID: <41879A42.2080404@isode.com> Date: Tue, 02 Nov 2004 14:31:30 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] WG last call on future delivery References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.lucent.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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Arnt Gulbrandsen wrote: > so, if I understand it correctly, > > 1) 1*9DIGIT stays. (Fine with me - I like consistency.) The special > case 0 is then superfluous. It's the same as 999999999. > > 2) Is also OK. The document must state that it is using RFC 2119. Just having it in the References section is not sufficient. > 3) The AUTH requirement goes. That is fine, as long there is a security consideration in the document stating that unauthenticated use of this feature must not be allowed. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 10:03:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27213 for ; Tue, 2 Nov 2004 10:03:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0R2-0003dq-3T for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 10:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP01f-0001i7-Ah; Tue, 02 Nov 2004 09:52:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzss-00051g-5U for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 09:43:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25094 for ; Tue, 2 Nov 2004 09:43:40 -0500 (EST) Received: from libertango.oryx.com ([195.30.94.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP07x-00037M-6E for lemonade@ietf.org; Tue, 02 Nov 2004 09:59:20 -0500 Message-Id: Date: Tue, 2 Nov 2004 15:46:13 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WG last call on future delivery References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.lucent.com> <41879A42.2080404@isode.com> In-Reply-To: <41879A42.2080404@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Alexey Melnikov writes: > Arnt Gulbrandsen wrote: >> 3) The AUTH requirement goes. > > That is fine, as long there is a security consideration in the > document stating that unauthenticated use of this feature must not be > allowed. I disagree. If unauthenticated submission is permitted (heaven forbid!), then unauthenticated submission with future delivery should also be. If not, then not. No additional "must not" is necessary. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 10:47:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02826 for ; Tue, 2 Nov 2004 10:47:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP18E-0004m9-Sr for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 11:03:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0i0-00081U-Nf; Tue, 02 Nov 2004 10:36:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0U1-00017N-3i for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 10:22:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00014 for ; Tue, 2 Nov 2004 10:22:03 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0j8-00041T-BP for lemonade@ietf.org; Tue, 02 Nov 2004 10:37:43 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iA2FLVXv012045 for ; Tue, 2 Nov 2004 09:21:31 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <4M3FKVW5>; Tue, 2 Nov 2004 09:21:31 -0600 Message-ID: <54E40201497DF142B06B27255953F79710AF5BF9@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Arnt Gulbrandsen , lemonade@ietf.org Subject: RE: [lemonade] WG last call on future delivery Date: Tue, 2 Nov 2004 09:21:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 That's my point as well.... the must not should be tagged to submission, not future delivery. I don't want the plethora of states that say "can submit, can't future delivery, can DSN, Can BURL, can't delivery-by if authorized but not authenticated" Greg V. -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] Sent: Tuesday, November 02, 2004 9:46 AM To: lemonade@ietf.org Subject: Re: [lemonade] WG last call on future delivery Alexey Melnikov writes: > Arnt Gulbrandsen wrote: >> 3) The AUTH requirement goes. > > That is fine, as long there is a security consideration in the > document stating that unauthenticated use of this feature must not be > allowed. I disagree. If unauthenticated submission is permitted (heaven forbid!), then unauthenticated submission with future delivery should also be. If not, then not. No additional "must not" is necessary. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 10:49:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03062 for ; Tue, 2 Nov 2004 10:49:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1A9-0004pD-1E for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 11:05:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0i8-00085a-I9; Tue, 02 Nov 2004 10:36:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0XR-0003VN-5V for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 10:25:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00238 for ; Tue, 2 Nov 2004 10:25:35 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0mY-00045I-DJ for lemonade@ietf.org; Tue, 02 Nov 2004 10:41:15 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 2 Nov 2004 15:24:59 +0000 Message-ID: <4187A6C9.9000105@isode.com> Date: Tue, 02 Nov 2004 15:24:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] WG last call on future delivery References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.lucent.com> <41879A42.2080404@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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> Arnt Gulbrandsen wrote: >> >>> 3) The AUTH requirement goes. >> >> That is fine, as long there is a security consideration in the >> document stating that unauthenticated use of this feature must not be >> allowed. > > I disagree. If unauthenticated submission is permitted (heaven forbid!), > then unauthenticated submission with future delivery should also be. If a feature is liable to abuse because of the lack of authentication, than the document must say so. When I say "authentication", I don't necessarily mean SMTP AUTH. IP verification is authentication as well. RFCs can't force implementations to comply, but it is important that they emphasize important issues. > If not, then not. No additional "must not" is necessary. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 11:06:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04500 for ; Tue, 2 Nov 2004 11:06:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1QV-0005DR-84 for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 11:22:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0yU-0007lg-Na; Tue, 02 Nov 2004 10:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0q5-0002l7-EC for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 10:44:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02480 for ; Tue, 2 Nov 2004 10:44:51 -0500 (EST) Received: from libertango.oryx.com ([195.30.94.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP15C-0004g1-Ud for lemonade@ietf.org; Tue, 02 Nov 2004 11:00:32 -0500 Message-Id: Date: Tue, 2 Nov 2004 16:47:26 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WG last call on future delivery References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.lucent.com> <41879A42.2080404@isode.com> <4187A6C9.9000105@isode.com> In-Reply-To: <4187A6C9.9000105@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Alexey Melnikov writes: > If a feature is liable to abuse because of the lack of authentication, > than the document must say so. Well, I don't see that it is open. I see that unauthenticated message submission is, of course. (I don't think every extension should repeat the base security considerations merely because the basic problems are still there when the extension is used.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 11:17:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05387 for ; Tue, 2 Nov 2004 11:17:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1aY-0005S4-1h for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 11:32:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP199-0003BM-3E; Tue, 02 Nov 2004 11:04:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0v9-0006oZ-Vo for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 10:50:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03095 for ; Tue, 2 Nov 2004 10:50:06 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1AH-0004pV-M8 for lemonade@ietf.org; Tue, 02 Nov 2004 11:05:46 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA2FemOb029820 for ; Tue, 2 Nov 2004 10:40:49 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Nov 2004 10:37:57 -0500 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Tue, 2 Nov 2004 10:36:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [lemonade] Meeting Schedule 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c MONDAY, November 8, 2004 1300-1500 Afternoon Sessions I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG WEDNESDAY, November 10, 2004 1530-1730 Afternoon Sessions II APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 12:06:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12330 for ; Tue, 2 Nov 2004 12:06:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2M5-00078s-Sg for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 12:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1nH-00067p-1X; Tue, 02 Nov 2004 11:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1W0-0003x4-Aj for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 11:28:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06739 for ; Tue, 2 Nov 2004 11:28:10 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1l6-0005nW-7f for lemonade@ietf.org; Tue, 02 Nov 2004 11:43:51 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2GS6e22548; Tue, 2 Nov 2004 18:28:06 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 18:25:04 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA2GP49a006293; Tue, 2 Nov 2004 18:25:04 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00tuv1V2; Tue, 02 Nov 2004 18:25:01 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2GOva07204; Tue, 2 Nov 2004 18:24:57 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 10:24:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Meeting Schedule Date: Tue, 2 Nov 2004 10:24:12 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB1D@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Meeting Schedule thread-index: AcTA96mUiaUJEPI9QFqgg2WK7aKUHwAAJ0BQ To: X-OriginalArrivalTime: 02 Nov 2004 16:24:13.0488 (UTC) FILETIME=[63F8AB00:01C4C0F8] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Why are there two? Mike > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Eric Burger > Sent: Tuesday, November 02, 2004 10:37 AM > To: lemonade@ietf.org > Subject: [lemonade] Meeting Schedule >=20 >=20 > MONDAY, November 8, 2004 > 1300-1500 Afternoon Sessions I > APP lemonade Enhancements to Internet email to Support=20 > Diverse Service > Environments WG >=20 >=20 > WEDNESDAY, November 10, 2004 > 1530-1730 Afternoon Sessions II > APP lemonade Enhancements to Internet email to Support=20 > Diverse Service > Environments WG >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade >=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 12:52:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17356 for ; Tue, 2 Nov 2004 12:52:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP357-0008TI-0G for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 13:08:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Wj-0006d0-Dw; Tue, 02 Nov 2004 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP28m-0008MF-Lj for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 12:08:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12716 for ; Tue, 2 Nov 2004 12:08:14 -0500 (EST) Received: from agminet02.oracle.com ([141.146.126.229]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2Nu-0007Cn-U3 for lemonade@ietf.org; Tue, 02 Nov 2004 12:23:56 -0500 Received: from agminet02.oracle.com (localhost [127.0.0.1]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA2H7dOK010061 for ; Tue, 2 Nov 2004 09:07:39 -0800 Received: from tdslnx101.oracleads.com (tdslnx101.oracleads.com [141.146.19.30]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA2H7baQ010018 for ; Tue, 2 Nov 2004 09:07:37 -0800 Received: from web69 (web69.oracle.com [148.87.122.101]) by tdslnx101.oracleads.com (8.11.6/8.11.6) with ESMTP id iA2GdFi14230 for ; Tue, 2 Nov 2004 10:39:19 -0600 Message-ID: <5590532.1099414376296.JavaMail.besadmin@web69> Date: Tue, 2 Nov 2004 09:52:47 -0700 From: Stephane Maes To: eburger@brooktrout.com, lemonade@ietf.org Subject: Re: [lemonade] Meeting Schedule MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Thread-Topic: [lemonade] Meeting Schedule Thread-Index: AcTA+t+b3YfyxFwZTJKG0X7/BsUVQgAAYH1/ X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Two sessions? I thought this was only on wednesday? I can't make Monday. Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM, Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: lemonade-bounces@ietf.org To: lemonade@ietf.org Sent: Tue Nov 02 08:36:55 2004 Subject: [lemonade] Meeting Schedule MONDAY, November 8, 2004 1300-1500 Afternoon Sessions I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG WEDNESDAY, November 10, 2004 1530-1730 Afternoon Sessions II APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 19:22:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05310 for ; Tue, 2 Nov 2004 19:22:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9Aj-0003Gr-9w for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 19:38:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8gY-0007bi-D3; Tue, 02 Nov 2004 19:07:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8Rq-0008WQ-UE for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 18:52:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02227 for ; Tue, 2 Nov 2004 18:52:20 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP8h3-0002KQ-TQ for lemonade@ietf.org; Tue, 02 Nov 2004 19:08:06 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iA2Npjon032746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Nov 2004 16:51:49 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Tue, 02 Nov 2004 15:51:42 -0800 From: Lyndon Nerenberg To: lemonade@ietf.org Subject: Re: [lemonade] WG last call on future delivery Message-ID: <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> In-Reply-To: References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.l ucent.com> <41879A42.2080404@isode.com> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit --On 2004-11-2 3:46 PM +0100 Arnt Gulbrandsen wrote: > I disagree. If unauthenticated submission is permitted (heaven > forbid!), then unauthenticated submission with future delivery should > also be. If not, then not. No additional "must not" is necessary. I can authorize without using AUTH. On my MSAs, any messages received via the loopback interface (127.0.0.1 and ::1) or through named sockets (/var/run/submission) are implicitly authorized by the nature of the injection mechanism. You cannot mandate AUTH as a pre-requisite to using AFTER. Instead we need to describe that MSA policy might require AUTH before allowing use of AFTER (e.g. to enforce a policy restricting AFTER to specific users), and describe how the client should deal with this scenario. We should be enumerating specific error status codes for the failure modes. I suggest the following: 530 5.7.8 Requested facility requires authentication Issued when the MSA requires explicit client authentication before permitting use of AFTER. The 530 reply is defined by RFC 2554. NOTE: 5.7.8 is a proposed new enhanced status code. It is issued when an SMTP command requests the use of an optional facility for which the server requires the session be authenticated. Specifically, it indicates the command should succeed (barring policy restrictions) if the client re-issues the command after a successful authentication. Alternatively, the client could re-issue the command without requesting the optional facility. (Of course its chances of knowing which facility to drop are marginal, unless only one facility was requested.) I believe this code is generally useful, therefore it should be defined in a way that makes it easy for other specifications to use normatively. I think this means updating RFC3463, or maybe just writing a one-page RFC to define the new code? 501 5.5.4 AFTER requested an interval greater than what the server advertised. 501 5.5.4 AFTER requested an interval greater than the associated DELIVERYBY time. 452 4.3.1 The number or size of messages queued on the server for future delivery has exceeded quota. Of these responses I believe the '530 5.7.8' is a MUST, and the rest are SHOULDs. Next, some silly-state issues. If is zero the server enforces no upper bound. But the protocol only allows the client to specify up to 999999999 seconds. The special semantics attached to zero should be removed. In this scenario the server should just advertise the maximum permitted by the protocol. Since a delivery interval of zero now makes no sense we should specify a minimum interval of one second. Advertising FUTUREDELIVERY without a doesn't make any sense to me. Surely the server knows this value. What purpose is served by not advertising it? What is a client supposed to do if the server reject the message due to the interval being too great? Guess? Advertising the maximum interval must be mandatory. Here's an updated grammar: after-parameter = "AFTER=" after-time after-time = %x31-39 *8DIGIT ; Integer in the range 1-999999999 futuredelivery-parameter = after-time In security considerations we need to mention another DOS scenario. A client might inject a large number of messages with a very low (say, one second), with the intent of causing the MSA to perform extra work by placing the message into a deferred queue, only to have to immediately move it to an active queue. For this reason the server might want to enforce an explicit minimum bound on the deferral time, or defer any further processing of a FUTUREDELIVERY message until the next regularly schedule queue run. The references need to be split into normative and informational sections. The reference to RFC2822 should be removed. The remaining references are -- I believe -- all normative. Some wordsmithing issues. Section 1, the second paragraph should read: This extension uses the SMTP submission protocol [3] to allow a client to submit a message for delivery at a future time. Section 3 discusses what I consider to be implementation-specific details: MSAs in receipt of a valid future- delivery-interval parameter are expected to convert the parameter into a locale-specific absolute time called the future-delivery-time. This is done by adding the future-delivery-interval to the locale- specific message receipt time. The MSA is expected to assume that the transmission time of the MAIL command is instantaneous. All we need to say is that the specifies a delay relative to the time the MSA received the message. Technically, this would be time the MSA issued the 2XX reply after completion of the DATA command, but I don't think we should call it out in this level of detail. If the MSA accepts a message with a future-delivery request, then the MSA delivers/relays the message after the MSA's system clock passes the future-delivery time. should be changed to: Upon receipt of a message with a future delivery request, the MSA MUST NOT forward or deliver the message until after the requested delay period has passed. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 2 20:07:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10076 for ; Tue, 2 Nov 2004 20:07:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9rO-0004MN-Kz for lemonade-web-archive@ietf.org; Tue, 02 Nov 2004 20:22:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP9S9-0007CT-Bh; Tue, 02 Nov 2004 19:56:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP9EN-0001IG-RV for lemonade@megatron.ietf.org; Tue, 02 Nov 2004 19:42:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07654 for ; Tue, 2 Nov 2004 19:42:28 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9Ta-0003nC-55 for lemonade@ietf.org; Tue, 02 Nov 2004 19:58:15 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iA30gKJU033006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Nov 2004 17:42:25 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Tue, 02 Nov 2004 16:42:17 -0800 From: Lyndon Nerenberg To: lemonade@ietf.org Subject: Re: [lemonade] WG last call on future delivery Message-ID: <819AF2EB693DE95D43B71A2D@peregrin.orthanc.ca> In-Reply-To: <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.l ucent.com> <41879A42.2080404@isode.com> <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit --On 2004-11-2 3:51 PM -0800 Lyndon Nerenberg wrote: > For this reason the server might want to > enforce an explicit minimum bound on the deferral time, or defer any > further processing of a FUTUREDELIVERY message until the next > regularly > schedule queue run. Let me clarify this. First, change 'explicit' to 'implicit'. And what I mean by enforcing a minimum bound is that the server might choose to silently enforce a minimum . I.e., if the client says AFTER=5 and the server has an implicit lower bound of 60 seconds, it would still accept the message, but defer forwarding for a minute. I think a more realistic scenario would have the minimum deferral time be bounded by the queue run interval. I.e. if the MSA processes the future delivery queue every five minutes, the implicit minimum bound will be a value between 0 and 300. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 00:54:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00082 for ; Wed, 3 Nov 2004 00:54:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPELk-0002CV-Sg for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 01:10:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPDul-0001NW-9T; Wed, 03 Nov 2004 00:42:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPDqy-0000fU-5R for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 00:38:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29118 for ; Wed, 3 Nov 2004 00:38:37 -0500 (EST) Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPE6E-0001rC-3S for lemonade@ietf.org; Wed, 03 Nov 2004 00:54:26 -0500 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by agminet01.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA35bp91013104; Tue, 2 Nov 2004 21:37:53 -0800 Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA35bow8009356; Tue, 2 Nov 2004 22:37:50 -0700 Received: from oracle-8qdrvd34 (dhcp-amer-csvpn-gw2-141-144-84-229.vpn.oracle.com [141.144.84.229]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA35bd7g009088; Tue, 2 Nov 2004 22:37:49 -0700 Message-Id: <200411030537.iA35bd7g009088@rgmgw2.us.oracle.com> From: "Stephane H. Maes" To: Eric Burger , lemonade@ietf.org Subject: RE: [lemonade] Meeting Schedule - Can we cancel Monday meeting? Date: Tue, 2 Nov 2004 21:37:22 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 50822 (10.0.4712) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Eric and all, As I did not get any answer yet, I must raise the issue. I think that it is inappropriate to have such significative change in the a= genda taking place so close before the meeting. This is making travel arran= gements impossible to make or to update. We need to have a more reasonable = process and deadlines for such changes. If they exist and were respected, I= am not aware of them, but in any way they would then be ridiculously way t= oo short and need to be questioned. No other standard body that I know woul= d accept such late agenda change! To the best that I know and understand how this goes, participation to lemo= nade does not imply nor require participation to any other IETF activities.= It is therefore not reasonable to expect participants to be able to attend= a meeting another day when the change occurs the week before (as far as I = noticed). In my case I carefully crafted an itinerary from SFO to Europe to DC that n= ow falls apart! In order to accommodate this issue, I would like to request that Lemonade m= eeting *only* takes place on Wednesday PM and that the Monday meeting be ca= nceled! = Thanks you in advance for your help in this matter. Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-6= 07-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Eric Burger Sent: Tuesday, November 02, 2004 7:37 AM To: lemonade@ietf.org Subject: [lemonade] Meeting Schedule MONDAY, November 8, 2004 1300-1500 Afternoon Sessions I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG WEDNESDAY, November 10, 2004 1530-1730 Afternoon Sessions II APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 01:15:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01449 for ; Wed, 3 Nov 2004 01:15:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPEfN-0002bn-Cd for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 01:30:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPEM1-00066o-4P; Wed, 03 Nov 2004 01:10:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPEFw-0002Kg-K6 for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 01:04:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00742 for ; Wed, 3 Nov 2004 01:04:27 -0500 (EST) Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPEV9-0002NG-EA for lemonade@ietf.org; Wed, 03 Nov 2004 01:20:15 -0500 Received: from maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id iA363rBX027272 for ; Wed, 3 Nov 2004 01:03:53 -0500 Received: from [135.210.128.30] (unknown[135.210.128.30](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20041103060512gw100gogcde> (Authid: tony); Wed, 3 Nov 2004 06:05:12 +0000 Message-ID: <418874C6.1060909@att.com> Date: Wed, 03 Nov 2004 01:03:50 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Maes Subject: Re: [lemonade] Meeting Schedule References: <5590532.1099414376296.JavaMail.besadmin@web69> In-Reply-To: <5590532.1099414376296.JavaMail.besadmin@web69> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, eburger@brooktrout.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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit How many people will be going to all or portions of the FTC Email Authentication Summit on Tuesday and Wednesday, and hence unable to attend on Wednesday? Tony Stephane Maes wrote: > Two sessions? I thought this was only on wednesday? > I can't make Monday. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 12:08:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27984 for ; Wed, 3 Nov 2004 12:08:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPOs1-0001gX-OQ for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 12:24:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPOOa-0000dL-13; Wed, 03 Nov 2004 11:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPODl-0006rR-Ns for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 11:42:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25178 for ; Wed, 3 Nov 2004 11:42:50 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPOT5-0000vV-Rn for lemonade@ietf.org; Wed, 03 Nov 2004 11:58:45 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id iA3GgGeD015014; Wed, 3 Nov 2004 08:42:16 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id iA3GgDHJ026854; Wed, 3 Nov 2004 08:42:14 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@m3.qualcomm.com Message-Id: In-Reply-To: <200411030537.iA35bd7g009088@rgmgw2.us.oracle.com> References: <200411030537.iA35bd7g009088@rgmgw2.us.oracle.com> Date: Wed, 3 Nov 2004 08:42:12 -0800 To: "Stephane H. Maes" , Eric Burger , lemonade@ietf.org From: Ted Hardie Subject: RE: [lemonade] Meeting Schedule - Can we cancel Monday meeting? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d At 9:37 PM -0800 11/2/04, Stephane H. Maes wrote: >In order to accommodate this issue, I would like to request that >Lemonade meeting *only* takes place on Wednesday PM and that the >Monday meeting be canceled! > In the working group discussion in Vancouver, I heard a very clear statement from the Chairs that the working group would need two meeting slots, and I approved those slots with the Secretariat when asked. Given the FTC email authentication summit on Tuesday and Wednesday, I am already concerned about attendance at e-mail related groups on those days. Cancelling a scheduled working group meeting to have a meeting only during that window is unwise, in my opinion. I understand your frustration with the agenda scheduling problem. It is perennial, with some updates even happening after the IETF week starts. This IETF week's problems are worse than usual because a late award of the hotel contract meant we have fewer rooms and thus less slack to use parallel scheduling. Getting contract awards back on track is one thing I hope will be resolved by the administrative restructuring process, so hopefully this problem will be less critical at future meetings. In the mean time, please remember that the IETF process requires that all decisions taken at meetings be confirmed on the mailing list, and that you will have a chance at the Wednesday slot for informal conversations about work done on Monday. While we would all be happier if active participants were available for the meeting slots and likely side discussions, we will all simply have to recognize that the process provides ways to make progress even when this is not so. Again, I am sorry for your frustration in this matter, regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 13:45:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06812 for ; Wed, 3 Nov 2004 13:45:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQNr-0004CY-QC for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 14:01:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPzP-0000Ky-NA; Wed, 03 Nov 2004 13:36:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPsH-0007tp-Fg for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 13:28:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05408 for ; Wed, 3 Nov 2004 13:28:46 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQ7d-0003i9-OR for lemonade@ietf.org; Wed, 03 Nov 2004 13:44:43 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3ISfl05449; Wed, 3 Nov 2004 20:28:41 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 20:28:44 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA3ISiFp024656; Wed, 3 Nov 2004 20:28:44 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00y5HpCA; Wed, 03 Nov 2004 20:28:43 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3IS6a26216; Wed, 3 Nov 2004 20:28:07 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 12:27:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Meeting Schedule - Can we cancel Monday meeting? Date: Wed, 3 Nov 2004 12:27:15 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB2E@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Meeting Schedule - Can we cancel Monday meeting? thread-index: AcTByL26aWN29/oDS1m//3irz973UwAA7IVQAAGGjCA= To: , X-OriginalArrivalTime: 03 Nov 2004 18:27:16.0375 (UTC) FILETIME=[BEED9270:01C4C1D2] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Ted Hardie > Sent: Wednesday, November 03, 2004 11:42 AM ... > In the working group discussion in Vancouver, I heard a very=20 > clear statement > from the Chairs that the working group would need two meeting=20 > slots, and It would have been nice if there had been something in the=20 minutes explaining: 1) That there would be two. 2) The purpose of each.=20 Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 14:06:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08894 for ; Wed, 3 Nov 2004 14:06:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQiA-0004hq-QD for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 14:22:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQJy-0007h2-4Y; Wed, 03 Nov 2004 13:57:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQC3-0003T5-2n for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 13:49:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07296 for ; Wed, 3 Nov 2004 13:49:13 -0500 (EST) Received: from agminet04.oracle.com ([141.146.126.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQRQ-0004If-1Z for lemonade@ietf.org; Wed, 03 Nov 2004 14:05:08 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA3ImWhl006659; Wed, 3 Nov 2004 10:48:32 -0800 Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA3ImVno020525; Wed, 3 Nov 2004 11:48:31 -0700 Received: from oracle-8qdrvd34 (dhcp-amer-vpn-rmdc-gw1-west-141-144-96-54.vpn.oracle.com [141.144.96.54]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA3ImJ5F020064; Wed, 3 Nov 2004 11:48:30 -0700 Message-Id: <200411031848.iA3ImJ5F020064@rgmgw1.us.oracle.com> From: "Stephane H. Maes" To: Ted Hardie , Eric Burger , lemonade@ietf.org Subject: RE: [lemonade] Meeting Schedule - Can we cancel Monday meeting? Date: Wed, 3 Nov 2004 10:46:44 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 50822 (10.0.4712) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Ted, Thanks for the explanation. I understand that this may be an exceptional si= tuation with unique circumstances that led to the change of schedule. Altho= ugh I had already left when it was discussed, I also agree that 2 slots wou= ld have been better than one and useful to accomplish enough work. The inte= ntion was good. However, this is where I think that a due process should be in place explic= itly in order to prevent that such situations when they occur simply imply = changes of schedule at the last moment. Again most standard / industry fora= have deadlines for meeting scheduling and changes in place. I would be sur= prised if the IETF does not; especially considering the large number of bud= get constrained IETF participants... So, acknowledging the good intent and that more slots are needed and that t= hey should be allocated for Lemonade in the future, I still believe that it= is unwise to have such a change at this time; independently of the good r= easons that have been enumerated. I believe that there must have been ample time to re-schedule early enough = e-mail related activities if there were concerns of overlap with other para= llel activities. It can't justify a late change. More troublesome even, I a= m now reading that because of the overlap the meeting expected to be the ma= in one (main attendance) would be the one on Monday, at the new slot? This = is not acceptable. Therefore, and in order to avoid protracted debate, I must firmly object to= the schedule changes and re-iterate my request to cancel the Monday meetin= g. Please note that it should be understood that this should not be conside= red as a request to "cancel a scheduled meeting" but rather as a rejection = of a change of schedule that occurred / was communicated way too late... Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-6= 07-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] = Sent: Wednesday, November 03, 2004 8:42 AM To: Stephane H. Maes; Eric Burger; lemonade@ietf.org Cc: Glenn Parsons Subject: RE: [lemonade] Meeting Schedule - Can we cancel Monday meeting? At 9:37 PM -0800 11/2/04, Stephane H. Maes wrote: >In order to accommodate this issue, I would like to request that >Lemonade meeting *only* takes place on Wednesday PM and that the = >Monday meeting be canceled! > In the working group discussion in Vancouver, I heard a very clear statemen= t from the Chairs that the working group would need two meeting slots, and I approved those slots with the Secretariat when asked. Given the FTC emai= l authentication summit on Tuesday and Wednesday, I am already concerned about attendance at e-mail related groups on those days. Cancelling = a scheduled working group meeting to have a meeting only during that window is unwise,= in my opinion. I understand your frustration with the agenda scheduling problem. It is perennial, with some updates even happening after the IETF week starts. Th= is IETF week's problems are worse than usual because a late award of the hotel= contract meant we have fewer rooms and thus less slack to use parallel scheduling. Getting contract awards back on track is one thing I hope will be resolved by the administrative restructuring process, so hopefully this problem will be less critical at future meetings. In the mean time, please remember that the IETF process requires that all decisions taken at meetings be confirmed on the mailing list, and that you will have a chance at the Wednesday slot for informal conversations about work done on Monday. While we would all be happier if active participants were available for the meeting slots and likely side discussio= ns, we will all simply have to recognize that the process provides ways to make= progress even when this is not so. Again, I am sorry for your frustration in this matter, regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 14:07:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09004 for ; Wed, 3 Nov 2004 14:07:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQjJ-0004jS-3Q for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 14:23:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQS7-0000Xr-Kz; Wed, 03 Nov 2004 14:05:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQEQ-0003kF-NM for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 13:51:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07594 for ; Wed, 3 Nov 2004 13:51:41 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQTn-0004MI-Ln for lemonade@ietf.org; Wed, 03 Nov 2004 14:07:36 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 3 Nov 2004 18:51:05 +0000 Message-ID: <41892897.40706@isode.com> Date: Wed, 03 Nov 2004 18:51:03 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] Meeting Schedule - Can we cancel Monday meeting? References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB2E@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB2E@daebe005.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Can we discuss agenda and try to split items so that they are convenient for people who can only attend one meeting or the other? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 14:35:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11517 for ; Wed, 3 Nov 2004 14:35:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPR9o-0005Ka-Gt for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 14:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQrd-0004PK-4W; Wed, 03 Nov 2004 14:32:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQi1-0003Oh-Rt for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 14:22:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10452 for ; Wed, 3 Nov 2004 14:22:16 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQxN-00053p-S0 for lemonade@ietf.org; Wed, 03 Nov 2004 14:38:11 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id iA3JLehP021693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Nov 2004 11:21:40 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id iA3JLbIj011796; Wed, 3 Nov 2004 11:21:38 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@m3.qualcomm.com Message-Id: In-Reply-To: <200411031848.iA3ImJ5F020064@rgmgw1.us.oracle.com> References: <200411031848.iA3ImJ5F020064@rgmgw1.us.oracle.com> Date: Wed, 3 Nov 2004 11:21:35 -0800 To: "Stephane H. Maes" , Eric Burger , lemonade@ietf.org From: Ted Hardie Subject: RE: [lemonade] Meeting Schedule - Can we cancel Monday meeting? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 At 10:46 AM -0800 11/3/04, Stephane H. Maes wrote: >However, this is where I think that a due process should be in place >explicitly in order to prevent that such situations when they occur >simply imply changes of schedule at the last moment. Again most >standard / industry fora have deadlines for meeting scheduling and >changes in place. I would be surprised if the IETF does not; >especially considering the large number of budget constrained IETF >participants... The last date at which requests could be made for slots (BoFs or working groups) was October 25th, 2004. All agendas prior to that point must be considered as subject to change, since the Secretariat cannot know what they may need to move to handle new requests. Even the agenda sent out by the Secretariat on Monday was marked draft, as there was new data indicating conflicts that still needed resolution. The dates for this are documented here: http://www.ietf.org/meetings/cutoff_dates_61.html Again, I am sorry that this is problematic, but the agenda on which you apparently based travel was marked as a draft agenda and subject to change. There are other discussions under way to discuss whether the IETF schedule has too large a presumption that participants are present for the whole week, but this isn't the right mailing list to hold that discussion. > >Therefore, and in order to avoid protracted debate, I must firmly >object to the schedule changes and re-iterate my request to cancel >the Monday meeting. Please note that it should be understood that >this should not be considered as a request to "cancel a scheduled >meeting" but rather as a rejection of a change of schedule that >occurred / was communicated way too late... > The effect of this is to cancel a scheduled meeting slot and reduce the total time available to the group. Given the other processes mentioned (the confirmation of decisions on the mailing list, summaries at the second meeting), I cannot see how losing this face-to-face time benefits the group. This does not mean I am not sympathetic, but I still must encourage the group to make the best use of all the time it has available. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 14:45:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12568 for ; Wed, 3 Nov 2004 14:45:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRJp-0005cc-HX for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 15:01:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQxg-0005Kp-Ph; Wed, 03 Nov 2004 14:38:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQsI-0004St-TA for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 14:32:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11249 for ; Wed, 3 Nov 2004 14:32:52 -0500 (EST) Received: from 206-169-2-196.gen.twtelecom.net ([206.169.2.196] helo=mail.optistreams.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPR7V-0005GL-MA for lemonade@ietf.org; Wed, 03 Nov 2004 14:48:48 -0500 Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id AB96C9E300B6; Wed, 03 Nov 2004 11:03:50 -0800 In-Reply-To: <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.l ucent.com> <41879A42.2080404@isode.com> <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <036A63D4-2DCF-11D9-9E39-000A9571873E@guppylake.com> Content-Transfer-Encoding: 7bit From: Nathaniel Borenstein Subject: Re: [lemonade] WG last call on future delivery Date: Wed, 3 Nov 2004 14:31:52 -0500 To: Lyndon Nerenberg X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Another technique that might in the future be acceptable as "authentication" in this context is payment, either by actual money or by computational challenges. That is, it might be acceptable/desirable for a future entrepreneur to offer anonymous email submission for cash, so long as the cash barrier is set high enough to deter true spammers. Similarly, it might be acceptable/desirable for a human rights organization to operate an anonymous submission service in which the client has to pay with computational cycles (enough to make it uneconomic for spammers) in order to obtain untraceable delivery of sensitive messages. Actually, I think the use of the term "authentication" should really be discouraged in this context (and at the upcoming FTC summit) in favor of something that doesn't preclude such alternatives -- perhaps "authorization" or "credentialing." -- Nathaniel On Nov 2, 2004, at 6:51 PM, Lyndon Nerenberg wrote: > --On 2004-11-2 3:46 PM +0100 Arnt Gulbrandsen > wrote: > >> I disagree. If unauthenticated submission is permitted (heaven >> forbid!), then unauthenticated submission with future delivery should >> also be. If not, then not. No additional "must not" is necessary. > > I can authorize without using AUTH. On my MSAs, any messages > received via the loopback interface (127.0.0.1 and ::1) or through > named sockets (/var/run/submission) are implicitly authorized > by the nature of the injection mechanism. You cannot mandate > AUTH as a pre-requisite to using AFTER. Instead we need to describe > that > MSA policy might require AUTH before allowing use of AFTER (e.g. to > enforce > a policy restricting AFTER to specific users), and describe how the > client > should deal with this scenario. > > We should be enumerating specific error status codes for the failure > modes. I suggest the following: > > 530 5.7.8 Requested facility requires authentication > > Issued when the MSA requires explicit client authentication before > permitting use of AFTER. > > The 530 reply is defined by RFC 2554. > > NOTE: > 5.7.8 is a proposed new enhanced status code. It is issued when an > SMTP > command requests the use of an optional facility for which the server > requires the session be authenticated. Specifically, it indicates the > command should succeed (barring policy restrictions) if the client > re-issues the command after a successful authentication. > Alternatively, the client could re-issue the command > without requesting the optional facility. (Of course its chances of > knowing which facility to drop are marginal, unless only one facility > was requested.) I believe this code is generally useful, therefore it > should be defined in a way that makes it easy for other specifications > to use normatively. I think this means updating RFC3463, or maybe > just writing a one-page RFC to define the new code? > > 501 5.5.4 > > AFTER requested an interval greater than what the server advertised. > > 501 5.5.4 > > AFTER requested an interval greater than the associated DELIVERYBY > time. > > 452 4.3.1 > > The number or size of messages queued on the server for future > delivery has > exceeded quota. > > Of these responses I believe the '530 5.7.8' is a MUST, and the > rest are SHOULDs. > > > Next, some silly-state issues. > > If is zero the server enforces no upper > bound. But the protocol only allows the client to specify up to > 999999999 > seconds. The special semantics attached to zero should be removed. In > this scenario the server should just advertise the maximum permitted by > the protocol. Since a delivery interval of zero now makes no sense we > should specify a minimum interval of one second. > > Advertising FUTUREDELIVERY without a > doesn't > make any sense to me. Surely the server knows this value. What purpose > is > served by not advertising it? What is a client supposed to do if the > server > reject the message due to the interval being too great? Guess? > Advertising > the maximum interval must be mandatory. > > Here's an updated grammar: > > after-parameter = "AFTER=" after-time > after-time = %x31-39 *8DIGIT > ; Integer in the range 1-999999999 > futuredelivery-parameter = after-time > > > In security considerations we need to mention another DOS scenario. A > client > might inject a large number of messages with a very low > (say, one second), with the intent of causing the MSA to perform extra > work > by placing the message into a deferred queue, only to have to > immediately > move it to an active queue. For this reason the server might want to > enforce an explicit minimum bound on the deferral time, or defer any > further processing of a FUTUREDELIVERY message until the next regularly > schedule queue run. > > > The references need to be split into normative and informational > sections. > > The reference to RFC2822 should be removed. > > The remaining references are -- I believe -- all normative. > > > Some wordsmithing issues. > > Section 1, the second paragraph should read: > > This extension uses the SMTP submission protocol [3] to allow > a client to submit a message for delivery at a future time. > > Section 3 discusses what I consider to be implementation-specific > details: > > MSAs in receipt of a valid future- > delivery-interval parameter are expected to convert the parameter > into a locale-specific absolute time called the future-delivery-time. > This is done by adding the future-delivery-interval to the locale- > specific message receipt time. The MSA is expected to assume that > the transmission time of the MAIL command is instantaneous. > > All we need to say is that the specifies a delay relative > to the time the MSA received the message. Technically, this would be > time the MSA issued the 2XX reply after completion of the DATA command, > but I don't think we should call it out in this level of detail. > > If the MSA accepts a message with a future-delivery request, then the > MSA delivers/relays the message after the MSA's system clock passes > the future-delivery time. > > should be changed to: > > Upon receipt of a message with a future delivery request, the MSA > MUST > NOT forward or deliver the message until after the requested delay > period has passed. > > > --lyndon > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 15:00:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13728 for ; Wed, 3 Nov 2004 15:00:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRY7-0005wt-MB for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 15:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPREe-0007mr-EG; Wed, 03 Nov 2004 14:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPRAX-0007Ai-V1 for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 14:51:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13027 for ; Wed, 3 Nov 2004 14:51:44 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRPv-0005km-MH for lemonade@ietf.org; Wed, 03 Nov 2004 15:07:40 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iA3JpX8C081122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2004 12:51:38 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 03 Nov 2004 11:51:30 -0800 From: Lyndon Nerenberg To: Nathaniel Borenstein Subject: Re: [lemonade] WG last call on future delivery Message-ID: <21492C6B72E4986F1E41AA9A@peregrin.orthanc.ca> In-Reply-To: <036A63D4-2DCF-11D9-9E39-000A9571873E@guppylake.com> References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.l ucent.com> <41879A42.2080404@isode.com> <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> <036A63D4-2DCF-11D9-9E39-000A9571873E@guppylake.com> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit --On 2004-11-3 2:31 PM -0500 Nathaniel Borenstein wrote: > Actually, I think the use of the term "authentication" should really > be discouraged in this context (and at the upcoming FTC summit) in > favor of something that doesn't preclude such alternatives -- perhaps > "authorization" or "credentialing." I'm glad you made this point. I wasn't very comfortable with using the term "authentication." I realized last night that what I really meant here was "authorization" and was planning to send out another clarification today, but you beat me to it. I do think the draft should be re-worded to use the term "authorization." AUTH would still be used as the example of the most common form of authorization. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 3 16:03:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19420 for ; Wed, 3 Nov 2004 16:03:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPSX2-0007VI-8V for lemonade-web-archive@ietf.org; Wed, 03 Nov 2004 16:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPSFQ-0005o7-IB; Wed, 03 Nov 2004 16:00:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPSEN-0004ys-Uh for lemonade@megatron.ietf.org; Wed, 03 Nov 2004 15:59:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19229 for ; Wed, 3 Nov 2004 15:59:46 -0500 (EST) Received: from 206-169-2-196.gen.twtelecom.net ([206.169.2.196] helo=mail.optistreams.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPSTl-0007Qg-Cj for lemonade@ietf.org; Wed, 03 Nov 2004 16:15:42 -0500 Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id AFFE2C31025A; Wed, 03 Nov 2004 12:30:54 -0800 In-Reply-To: <21492C6B72E4986F1E41AA9A@peregrin.orthanc.ca> References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.l ucent.com> <41879A42.2080404@isode.com> <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> <036A63D4-2DCF-11D9-9E39-000A9571873E@guppylake.com> <21492C6B72E4986F1E41AA9A@peregrin.orthanc.ca> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2DA51173-2DDB-11D9-9E39-000A9571873E@guppylake.com> Content-Transfer-Encoding: 7bit From: Nathaniel Borenstein Subject: Re: [lemonade] WG last call on future delivery Date: Wed, 3 Nov 2004 15:58:57 -0500 To: Lyndon Nerenberg X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit On Nov 3, 2004, at 2:51 PM, Lyndon Nerenberg wrote: > I do think the draft should be re-worded to use the term > "authorization." > AUTH would still be used as the example of the most common form of > authorization. Yes, it would be even better, IMHO, if it explicitly called out a few alternate possibilities for authorization. I think it important that we do what we can to make it clear that anonymity need not be sacrificed for spam control. -- Nathaniel _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 5 11:37:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26942 for ; Fri, 5 Nov 2004 11:37:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ7LZ-00074z-8q for lemonade-web-archive@ietf.org; Fri, 05 Nov 2004 11:53:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ70j-0006n2-Mm; Fri, 05 Nov 2004 11:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ6vo-0005Ij-Jt for lemonade@megatron.ietf.org; Fri, 05 Nov 2004 11:27:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25962 for ; Fri, 5 Nov 2004 11:27:18 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ7Ba-0006nG-0p for lemonade@ietf.org; Fri, 05 Nov 2004 11:43:38 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 5 Nov 2004 16:26:41 +0000 Message-ID: <418BA9BF.4060906@isode.com> Date: Fri, 05 Nov 2004 16:26:39 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG , lemonade@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [lemonade] Not being able to attend IMAPEXT/Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Due to little trick that UK Home Office has played on me, I am still not in possession of my passport. My flight is tomorrow at noon. So I will most likely miss the IMAPEXT and Lemonade meetings. I will try to participate in jabber. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 6 11:26:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18601 for ; Sat, 6 Nov 2004 11:26:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQTOM-0001Pw-0S for lemonade-web-archive@ietf.org; Sat, 06 Nov 2004 11:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQTKN-0004D9-0Y; Sat, 06 Nov 2004 11:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQTJC-00043S-NK for lemonade@megatron.ietf.org; Sat, 06 Nov 2004 11:20:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18393 for ; Sat, 6 Nov 2004 11:20:56 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQTJM-0001Kx-4v for lemonade@ietf.org; Sat, 06 Nov 2004 11:21:08 -0500 Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:20:12 +0000 Message-ID: <418CF99B.70300@isode.com> Date: Sat, 06 Nov 2004 16:19:39 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg Subject: Re: [lemonade] WG last call on future delivery References: <54E40201497DF142B06B27255953F79710AF5A3D@il0015exch007u.ih.l ucent.com> <41879A42.2080404@isode.com> <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> In-Reply-To: <30C5F9D7A4F3CB95EF75E909@peregrin.orthanc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Lyndon Nerenberg wrote: > 530 5.7.8 Requested facility requires authentication > > Issued when the MSA requires explicit client authentication before > permitting use of AFTER. > > The 530 reply is defined by RFC 2554. > > NOTE: > 5.7.8 is a proposed new enhanced status code. It is issued when an SMTP > command requests the use of an optional facility for which the server > requires the session be authenticated. Specifically, it indicates the > command should succeed (barring policy restrictions) if the client > re-issues the command after a successful authentication. > Alternatively, the client could re-issue the command > without requesting the optional facility. (Of course its chances of > knowing which facility to drop are marginal, unless only one facility > was requested.) I believe this code is generally useful, therefore it > should be defined in a way that makes it easy for other specifications > to use normatively. I think this means updating RFC3463, or maybe > just writing a one-page RFC to define the new code? Actually, section 5 of draft-siemborski-rfc2554bis-03.txt (SMTP AUTH revision) already has: 530 5.7.0 Authentication required This response SHOULD be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT when server policy requires authentication in order to perform the requested action and authentication is not currently in force. If you think a more specific enhanced status code is needed, than I think it still belongs to draft-siemborski-rfc2554bis. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 6 21:02:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25990 for ; Sat, 6 Nov 2004 21:02:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQcNn-0003xD-AG for lemonade-web-archive@ietf.org; Sat, 06 Nov 2004 21:02:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQcMJ-0001im-K7; Sat, 06 Nov 2004 21:00:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQcLs-0001aW-Bp for lemonade@megatron.ietf.org; Sat, 06 Nov 2004 21:00:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25939 for ; Sat, 6 Nov 2004 21:00:18 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQcM7-0003ur-2d for lemonade@ietf.org; Sat, 06 Nov 2004 21:00:35 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA71rFP8003598 for ; Sat, 6 Nov 2004 20:53:17 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Nov 2004 20:50:21 -0500 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Sat, 6 Nov 2004 20:49:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [lemonade] Agenda Theory 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Sorry for the delay in getting the agenda out. We've had a new addition to the work group. Glenn has a new son, John Wilson. If he wants some sleep, Glenn might even make a cameo this week :) We were going with the principle of one day for review & status, and one day for working. However, because of the late scheduling of the work group sessions, we've thrown that idea out of the window. It could be worse: when we asked for a second session after the interim, we got Monday, but *lost* Wednesday. We got that back on track, but only after learning that some folks cannot do Monday. Others cannot do Wednesday. Here is the deal: we really will follow the IETF protocol -- while we may discuss lots at the face-to-face, NO decisions will be final until they are taken to the list. In order to capture good meeting minutes and jabber log, we really, really need volunteers that are familiar with lemonade to take minutes. I would like to get two volunteers, NOW. See you Monday and Wednesday. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 6 21:05:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26085 for ; Sat, 6 Nov 2004 21:05:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQcRA-00040A-Mv for lemonade-web-archive@ietf.org; Sat, 06 Nov 2004 21:05:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQcPF-00028b-6E; Sat, 06 Nov 2004 21:03:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQcMc-0001jj-JD for lemonade@megatron.ietf.org; Sat, 06 Nov 2004 21:01:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25957; Sat, 6 Nov 2004 21:01:04 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQcMr-0003wM-0n; Sat, 06 Nov 2004 21:01:21 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA71rFP8003602; Sat, 6 Nov 2004 20:53:17 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Nov 2004 20:50:22 -0500 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Sat, 6 Nov 2004 20:49:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: agenda@ietf.org Subject: [lemonade] Lemonade Agenda 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Monday 1pm, Hemisphere Room --------------------------- Agenda Bashing Status Update Future Delivery (draft-ietf-lemonade-futuredelivery-00.txt) MMS Mapping (draft-ietf-lemonade-mms-mapping-01.txt) Mobile Sync (draft-wener-lemonade-checkpoint-00.txt ) IMAP4 extension for quick reconnect (draft-ietf-lemonade-reconnect-02.txt) IMAP4 extension for opening pipes for async communication (draft-wener-lemonade-clearidle-00.txt) Transcoding Discussion Wednesday 3:30pm, Hemisphere Room --------------------------------- Profile (draft-ietf-lemonade-profile-00.txt) Lemonade and Mobile E-Mail (draft-smaes-lemonade-mobile-email-01.txt) Goals (draft-ietf-lemonade-goals-04.txt) URLAUTH (draft-ietf-lemonade-urlauth-03.txt) BURL (draft-ietf-lemonade-burl-00.txt) CATENATE (draft-ietf-lemonade-catenate-02.txt) CHANNEL (draft-ietf-lemonade-imap-channel-02.txt) Message Filter (draft-wener-lemonade-msgfilter-00.txt) If there is something missing, please send me e-mail. If you are presenting, please send me the presentation, preferably before the session. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 6 21:33:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27175 for ; Sat, 6 Nov 2004 21:33:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQcsj-0004OA-AI for lemonade-web-archive@ietf.org; Sat, 06 Nov 2004 21:34:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQclV-00074h-SK; Sat, 06 Nov 2004 21:26:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQcis-0006ST-60 for lemonade@megatron.ietf.org; Sat, 06 Nov 2004 21:24:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26799 for ; Sat, 6 Nov 2004 21:24:03 -0500 (EST) Received: from inet-mail4.oracle.com ([148.87.2.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQcj4-0004F2-51 for lemonade@ietf.org; Sat, 06 Nov 2004 21:24:21 -0500 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA72HIg6000483; Sat, 6 Nov 2004 18:17:23 -0800 (PST) Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA72NHb1001119; Sat, 6 Nov 2004 19:23:17 -0700 Received: from oracle-8qdrvd34 (dhcp-amer-csvpn-gw2-141-144-81-162.vpn.oracle.com [141.144.81.162]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA72MusF000918; Sat, 6 Nov 2004 19:23:16 -0700 Message-Id: <200411070223.iA72MusF000918@rgmgw2.us.oracle.com> From: "Stephane H. Maes" To: Eric Burger , lemonade@ietf.org Subject: RE: [lemonade] Lemonade Agenda Date: Sat, 6 Nov 2004 18:22:23 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 50822 (10.0.4712) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Eric, Please allow revisiting some discussions topic of Monday on Wednesday. I th= ink this should be an explicit agenda item at the beginning of Wednesday. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-6= 07-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Eric Burger Sent: Saturday, November 06, 2004 5:50 PM To: lemonade@ietf.org Cc: agenda@ietf.org Subject: [lemonade] Lemonade Agenda Monday 1pm, Hemisphere Room --------------------------- Agenda Bashing Status Update Future Delivery (draft-ietf-lemonade-futuredelivery-00.txt) = MMS Mapping (draft-ietf-lemonade-mms-mapping-01.txt) = Mobile Sync (draft-wener-lemonade-checkpoint-00.txt ) IMAP4 extension for quick reconnect (draft-ietf-lemonade-reconnect-02.txt) = = IMAP4 extension for opening pipes for async communication (draft-wener-lemonade-clearidle-00.txt) Transcoding Discussion Wednesday 3:30pm, Hemisphere Room --------------------------------- Profile (draft-ietf-lemonade-profile-00.txt) Lemonade and Mobile E-Mail (draft-smaes-lemonade-mobile-email-01.txt) = Goals (draft-ietf-lemonade-goals-04.txt) = URLAUTH (draft-ietf-lemonade-urlauth-03.txt) = BURL (draft-ietf-lemonade-burl-00.txt) = CATENATE (draft-ietf-lemonade-catenate-02.txt) = CHANNEL (draft-ietf-lemonade-imap-channel-02.txt) = Message Filter (draft-wener-lemonade-msgfilter-00.txt) If there is something missing, please send me e-mail. If you are presenting, please send me the presentation, preferably before t= he session. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 01:25:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10356 for ; Sun, 7 Nov 2004 01:25:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQgUh-0008TI-Fq for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 01:25:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQgT1-00038p-GX; Sun, 07 Nov 2004 01:23:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQgSY-00030C-E3 for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 01:23:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10260 for ; Sun, 7 Nov 2004 01:23:29 -0500 (EST) Received: from inet-mail4.oracle.com ([148.87.2.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQgSp-0008R2-Gc for lemonade@ietf.org; Sun, 07 Nov 2004 01:23:48 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA76Gr2G006202 for ; Sat, 6 Nov 2004 22:16:56 -0800 (PST) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA76Mq6v030627 for ; Sat, 6 Nov 2004 23:22:52 -0700 Received: from oracle-8qdrvd34 (dhcp-amer-csvpn-gw1-141-144-64-124.vpn.oracle.com [141.144.64.124]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA76MfV6030528 for ; Sat, 6 Nov 2004 23:22:51 -0700 Message-Id: <200411070622.iA76MfV6030528@rgmgw1.us.oracle.com> From: "Stephane H. Maes" To: lemonade@ietf.org Date: Sat, 6 Nov 2004 22:21:27 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 50822 (10.0.4712) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Updated Lemonade and Mobile e-mail 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Based on some comments received on , I have put an intermediate update at h= ttp://www.essem.com/pub/2004/ietf/draft-smaes-lemonade-mobile-email-pre02.t= xt. I would like to use this version for discussion on Wednesday. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-6= 07-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 11:05:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29682 for ; Sun, 7 Nov 2004 11:05:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpYW-0005yn-Tp for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 11:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpWk-00027c-RP; Sun, 07 Nov 2004 11:04:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpLk-0000F5-OQ for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 10:53:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28600 for ; Sun, 7 Nov 2004 10:53:02 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpM6-0005dd-SR for lemonade@ietf.org; Sun, 07 Nov 2004 10:53:27 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 15:52:22 +0000 Message-ID: <418E44B4.7030004@isode.com> Date: Sun, 07 Nov 2004 15:52:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger Subject: Re: [lemonade] Lemonade Agenda 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Eric Burger wrote: >Monday 1pm, Hemisphere Room >--------------------------- >Agenda Bashing >Status Update >Future Delivery (draft-ietf-lemonade-futuredelivery-00.txt) > > My understanding that the document will need to have another revision to address the issues raised during Last Call. Am I correct? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 11:07:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29728 for ; Sun, 7 Nov 2004 11:07:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpZf-0005zo-WC for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 11:07:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpWp-0002B1-Le; Sun, 07 Nov 2004 11:04:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpNa-0000WU-Tg for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 10:54:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28726 for ; Sun, 7 Nov 2004 10:54:56 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpNx-0005gG-82 for lemonade@ietf.org; Sun, 07 Nov 2004 10:55:21 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 15:54:25 +0000 Message-ID: <418E4530.2060600@isode.com> Date: Sun, 07 Nov 2004 15:54:24 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger Subject: Re: [lemonade] Lemonade Agenda References: <200411070223.iA72MusF000918@rgmgw2.us.oracle.com> In-Reply-To: <200411070223.iA72MusF000918@rgmgw2.us.oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Stephane H. Maes wrote: >Eric, > >Please allow revisiting some discussions topic of Monday on Wednesday. I think this should be an explicit agenda item at the beginning of Wednesday. > > I think this is a reasonable suggestion. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 11:34:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02496 for ; Sun, 7 Nov 2004 11:34:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQq0f-0006eq-PT for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 11:35:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpuZ-0006Nm-GP; Sun, 07 Nov 2004 11:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpqs-0005fq-8q for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 11:25:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01457 for ; Sun, 7 Nov 2004 11:25:11 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQprD-0006Pw-LL for lemonade@ietf.org; Sun, 07 Nov 2004 11:25:37 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 16:24:06 +0000 Message-ID: <418E4C25.6090103@isode.com> Date: Sun, 07 Nov 2004 16:24:05 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Michael.Wener@nokia.com References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA94@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA94@daebe005.americas.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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org Subject: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues) 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Michael.Wener@nokia.com wrote: >I do not believe the current set of drafts address directly the primary mobile synchronization issues. I believe a full solution must cover: >1) Multi-Folder monitoring >2) Mitigate the N*M algorithm typically used at sync time. > > >3) Folder events >4) Expunge Events >5) New mail events >6) Smoothed connection loss caused by the carrier >7) Reduce the set of visible messages per folder > > >Below are the personal drafts that address these issues along with their abstracts. A goal of these drafts was to address the problem specifically with a minimum of variation from the current IMAP RFCs. Clearidle and Checkpoint address the first 6 above. > Does the CHECKPOINT extension try to address # 2. If it does - how? > Number 7 is addressed by Msgfilter. > >Clearidle (See attached) > The IMAPRev4 specification supports unsolicited responses being sent > to a client at any time. The IDLE specification defines a way for a > client to sit in an idle connection waiting to receive these > responses. This document clarifies and extends the set of responses > that a client may receive while in the idle state. The desire is to > allow a client to predict exactly what set of unsolicited responses > it can rely on receiving when listening on an idle connection. > I will send my comments on this document separately. > >http://www.ietf.org/internet-drafts/draft-wener-lemonade-checkpoint-00.txt > This document describes an IMAP extension that aids in allowing a > client to maintain mailbox synchronization without performing a deep > sync after each connection. The goal is to minimize, but not > eliminate, the need for deep synchronizations. The extension defines > a way for a client to receive and acknowledge state change responses > from the server. > I've tried to understand details of the CHECKPOINT extension, however I don't think I was very successful. (Hopefully I got the basic idea, correct me if I've misunderstood something). The main reason for that, IMHO, is because the document makes many assumptions about what the extension is trying to do, but those assumptions are not clearly stated anywhere in the document. And the assumptions look definitely different from my understanding of the IMAP model. For example, the extension assumes that unsolicited responses sent to multiple clients can be shared between all of them. I actually strongly disagree, a user Foo must not be allowed to get responses for the user Bar. If it was not your intent, the document must be clarified that only responses for the same user are shared. I also didn't like some syntactical constructs that you were using, but this is minor. The CHECKPOINT extension pretty much tries to do everything that the CONDSTORE extension can already do (with exception of notifying about expunged messages, which is addressed in the latest RECONNECT draft), although in a slightly different way. The CONDSTORE extension doesn't dictate how it can be implemented, one can use a queue of responses (as CHECKPOINT does). Now, CHECKPOINT requires that all sessions receive exactly the same responses. CONDSTORE is a bit more smart on this. For example, let's imagine that the \Seen flag was set on the message 4 and then later on the \Deleted flag was also set. The CHECKPOINT will send: S: * 4 FETCH (FLAGS (\Recent \Seen)) (1006) ... S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted)) (1054) The CONDSTORE only requires a single response: S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted) MODSEQ (1054)) (observe that "a CHECKPOINT response number" can be the same as CONDSTORE "modification sequence"). Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 11:37:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02922 for ; Sun, 7 Nov 2004 11:37:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQq3W-0006jp-CD for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 11:38:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQq2J-0007dV-Rj; Sun, 07 Nov 2004 11:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpvh-0006WA-B6 for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 11:30:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02044 for ; Sun, 7 Nov 2004 11:30:10 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpw0-0006Xe-KV for lemonade@ietf.org; Sun, 07 Nov 2004 11:30:35 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA7GPW0m009572; Sun, 7 Nov 2004 11:25:34 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Nov 2004 11:22:40 -0500 Message-ID: From: Eric Burger To: Alexey Melnikov , "Stephane Maes (E-mail)" Subject: RE: [lemonade] Lemonade Agenda Date: Sun, 7 Nov 2004 11:22:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Agreed and done. > -----Original Message----- > From: Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Sunday, November 07, 2004 10:54 AM > To: Eric Burger > Cc: lemonade@ietf.org > Subject: Re: [lemonade] Lemonade Agenda > > > Stephane H. Maes wrote: > > >Eric, > > > >Please allow revisiting some discussions topic of Monday on > Wednesday. I think this should be an explicit agenda item at > the beginning of Wednesday. > > > > > I think this is a reasonable suggestion. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 12:30:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06699 for ; Sun, 7 Nov 2004 12:30:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqsv-0007kl-VU for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 12:31:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqpV-0000FY-L6; Sun, 07 Nov 2004 12:27:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqh4-00070i-M7 for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 12:19:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05861 for ; Sun, 7 Nov 2004 12:19:07 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqhP-0007Ul-2t for lemonade@ietf.org; Sun, 07 Nov 2004 12:19:34 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 17:18:23 +0000 Message-ID: <418E58DE.4000401@isode.com> Date: Sun, 07 Nov 2004 17:18:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Michael.Wener@nokia.com References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA94@daebe005.americas.nokia.com> <418E4C25.6090103@isode.com> In-Reply-To: <418E4C25.6090103@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: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, IMAP Extensions WG Subject: [lemonade] Comments about CLEARIDLE 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit [Also crossposting this to IMAPEXT.] > Clearidle (See attached) > The IMAPRev4 specification supports unsolicited responses being sent > to a client at any time. The IDLE specification defines a way for a > client to sit in an idle connection waiting to receive these > responses. This document clarifies and extends the set of responses > that a client may receive while in the idle state. The desire is to > allow a client to predict exactly what set of unsolicited responses > it can rely on receiving when listening on an idle connection. One thing the needs discussing is whether the problem of receiving flag changes/new mail notifications for multiple mailboxes (over a single connection) is worth solving. I frankly don't know for sure. I will try to emphasize some specific technical issues with this document. >2.1 LIST Response > > Currently the LIST response occurs as the result of a LIST command. > This document modifies the syntax of a LIST response and also defines > it's occurrence as a legal unsolicited response that could be received > on IDLE connections associated with a user. > > Two new name attributes are defined: > > \Deleted > The mailbox has been deleted and no longer exists. After a LIST > response with this attribute is seen the server will no longer > show the named folder in any LIST commands. There MUST NOT be > any other name attributes sent along with this attribute. I suggest you review the LISTEXT extension (currently draft-ietf-imapext-list-extensions-10.txt). \Deleted is the same as \NonExistent. > \Renamed > The mailbox has been renamed. A second LIST response MUST > immediately follow indicating the new name. [...] > 3) If a folder is renamed two LIST responses are sent. The first > indicating the old name and a \Renamed attribute and a second > response MUST immediately follow the first indicating the new name. This might be less obvious for people not following IMAPEXT, but there was a proposal to have REFERRAL data returned in LIST responses. It serves exactly this purpose. See , item # 5. It also avoids the proposed hack (sorry, I can't find a better word) of tying two LIST responses together. >2.2 FETCH Response > > Currently the FETCH response occurs as the result of a FETCH command > or as an unsolicited response on an IDLE connection. This document > clarifies exactly what form of response should be sent when the > specified events occur on the server. [...] > New Message Arrival > An unsolicited FETCH response with envelope, body, flag and uid > data MUST be sent on all IDLE connections. > > Example: > S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODY (...)) Actually no, BODY must not be in this list, as it is potentially very big. You surely wouldn't want to push a 10Mb message to you cell phone. I also suggest to replace the ENVELOPE with the BODYSTRUCTURE. >3.1.1 Mailbox Identification Syntax > > While in the Authenticated state there is no way to implicitly > determine which mailbox the response applies to. While this is not a > problem for some responses such as the LIST response it does pose a > problem for responses that are mail message specific. [...] > Example: > S: * 22 EXISTS (imap://mail/inbox) Why can't we just you the STATUS response? S: * STATUS INBOX (MESSAGES 231 RECENT 7) Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 13:22:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10241 for ; Sun, 7 Nov 2004 13:22:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQrgM-0000Fe-5Z for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 13:22:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQrf6-0000tI-NV; Sun, 07 Nov 2004 13:21:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQrYJ-0008SW-M3 for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 13:14:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09803 for ; Sun, 7 Nov 2004 13:14:08 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQrYg-000078-7T for lemonade@ietf.org; Sun, 07 Nov 2004 13:14:35 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 18:13:32 +0000 Message-ID: <418E65CB.6040408@isode.com> Date: Sun, 07 Nov 2004 18:13:31 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael.Wener@nokia.com Subject: Re: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA03@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA03@daebe005.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, stephane.maes@oracle.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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Michael.Wener@nokia.com wrote: >>Isn't it [MSGFILTER] the mechanism proposed by XFILTER in P-IMAP? >> >> > >No. > > Actually, it seems that there is a lot of overlap between the [MSGFILTER] "FILTER SET" and the [P-IMAP] XFILTER/XPSEARCH commands. This also brings memories of long expired IMAPEXT VIEW extension. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 13:51:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12550 for ; Sun, 7 Nov 2004 13:51:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQs8M-0000rz-7v for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 13:51:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQs6N-0006Q0-1S; Sun, 07 Nov 2004 13:49:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQs1P-0005XK-Pr for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 13:44:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11980 for ; Sun, 7 Nov 2004 13:44:14 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQs1n-0000hG-CU for lemonade@ietf.org; Sun, 07 Nov 2004 13:44:40 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 18:43:37 +0000 Message-ID: <418E6CD8.90606@isode.com> Date: Sun, 07 Nov 2004 18:43:36 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Michael.Wener@nokia.com MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org Subject: [lemonade] Comments/questions about MSGFILTER 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit >2.1 FILTER SET Command > > Arguments: OPTIONAL Sub-Command with arguments. The allowed sub > commands are SEARCH,UID and TAG. The SEARCH command can > be followed by all associated SEARCH arguments. The TAG > command MUST be followed by an identifier. The UID sub > command MUST be followed by one or more numeric numbers. > > Responses: REQUIRED untagged responses: FILTER SET and EXISTS > [...] > A FILTER SET command will restrict the set of UIDs that are visible > to the client. The three forms allow the Filter Set to be changed > during the session. The total Filter Set is an accumulation of all > FILTER SET commands issued during the session. The accumulation is > not a simple UNION. [...] > A TAG Sub-Command will result in a set of UIDs that match some > external set of criteria. The argument pasted to the this Sub- > Command is a Filter Set Indentifier. I think the extension is lacking the ability to list available external filters. > Multiple FILTER SET commands may be issued during a single session. > The rules of accumulation are: > > 1) TAG Sub-Commands MUST replace ALL previous Sub-Commands, > including previous TAG Sub-Commands. > 2) New SEARCH sub-commands MUST replace a previous SEARCH > Sub-Command. New SEARCH sub-commands MUST union with previous > TAG commands. Just to clarify: is SEARCH performed only once (when the command is issued) or it is done every time a new message arrives? > 3) UID Sub-Commands are always cumulative. Multiple UID ADD > Sub-Commands will increase the Filter Set, while UID REMOVE > Sub-Commands will reduce the Filter Set if the specified UID > was already in the set. > > Filter Sets are transient. A Filter Set only lasts for the duration > of the Session. A new Session requires the re-establishment of the > Filter Set. > > An EXISTS response is sent as the first response in a Filter Set. It > represents the total number of messages visible after the > application of the latest FILTER SET. I suggest you define a new response instead. > Example: C: 1 SELECT INBOX > S: * 50 EXISTS [...] > S: 3 OK FILTER SET Completed > C: 4 FETCH The example seems to be truncated. >3.1 FILTERED Response > > While there are Filter Sets in effect in a session all normal IMAP > commands are still legal. A FILTERED response is returned when > issued to communicate to the client that the current set of > responses are representative of a Filter Set and not the total set > of messages that may have been returned had the Filter Set not been > in effect. > > The FILTERED response is returned when any command is issued in > the Selected state and the sequence or UID arguments are sets that > may include numbers not explicitly asked for by the client. Ok, you need to describe what would be the behavior of STORE/COPY commands, when a filter is in effect. I would presume that STORE/COPY are not affected. So effectively a filter only affects which FETCH responses are to be returned? What about SEARCH? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 14:27:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15267 for ; Sun, 7 Nov 2004 14:27:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQshu-0001fB-D2 for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 14:28:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsbY-00056n-DK; Sun, 07 Nov 2004 14:21:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsVp-0003xt-D3 for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 14:15:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14580 for ; Sun, 7 Nov 2004 14:15:39 -0500 (EST) Received: from agminet04.oracle.com ([141.146.126.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsWD-0001PW-DD for lemonade@ietf.org; Sun, 07 Nov 2004 14:16:05 -0500 Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JF9Hr025304 for ; Sun, 7 Nov 2004 11:15:09 -0800 Received: from web69 (web69.oracle.com [148.87.122.101]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JF89u025293 for ; Sun, 7 Nov 2004 11:15:08 -0800 Message-ID: <8475724.1099855735843.JavaMail.besadmin@web69> Date: Sun, 7 Nov 2004 12:28:55 -0700 From: Stephane Maes To: alexey.melnikov@isode.com Subject: Re: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Thread-Topic: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 Thread-Index: AcTE95jokYzb5jKrTNGPx0zujLVM4AACGxqz X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Agreed. In my view the difference is non persistence. There may be use case for that but for P-IMAP and its use case, the filter must be permanent or the concept of mobile repository and filters would not help and rather burden the user. Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM, Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: Alexey Melnikov To: michael.wener@nokia.com CC: Stephane Maes ; lemonade@ietf.org Sent: Sun Nov 07 11:13:31 2004 Subject: Re: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 Michael.Wener@nokia.com wrote: >>Isn't it [MSGFILTER] the mechanism proposed by XFILTER in P-IMAP? >> >> > >No. > > Actually, it seems that there is a lot of overlap between the [MSGFILTER] "FILTER SET" and the [P-IMAP] XFILTER/XPSEARCH commands. This also brings memories of long expired IMAPEXT VIEW extension. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 14:28:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15322 for ; Sun, 7 Nov 2004 14:28:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsim-0001g9-FI for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 14:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsbs-0005Lh-H3; Sun, 07 Nov 2004 14:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsZA-0004jR-TB for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 14:19:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14773 for ; Sun, 7 Nov 2004 14:19:07 -0500 (EST) Received: from agminet04.oracle.com ([141.146.126.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsZZ-0001Ta-2q for lemonade@ietf.org; Sun, 07 Nov 2004 14:19:33 -0500 Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JIbRW027899 for ; Sun, 7 Nov 2004 11:18:37 -0800 Received: from web69 (web69.oracle.com [148.87.122.101]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JIasf027880 for ; Sun, 7 Nov 2004 11:18:36 -0800 Message-ID: <1173979.1099855943921.JavaMail.besadmin@web69> Date: Sun, 7 Nov 2004 12:32:23 -0700 From: Stephane Maes To: alexey.melnikov@isode.com Subject: Re: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Thread-Topic: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues) Thread-Index: AcTE6dmR0w3kDZCxTXSBCVqn0zlamQAFqe9S X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit In my view CHECKPOINT + CLEARIDLE try to achieve the same as CONDSTORE but monitoring more changes. What is the status of CONDSTORE. Can't the additional diff items be added to CONDSTORE at IMAP Ext? Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM, Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: lemonade-bounces@ietf.org To: michael.wener@nokia.com CC: lemonade@ietf.org Sent: Sun Nov 07 09:24:05 2004 Subject: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues) Michael.Wener@nokia.com wrote: >I do not believe the current set of drafts address directly the primary mobile synchronization issues. I believe a full solution must cover: >1) Multi-Folder monitoring >2) Mitigate the N*M algorithm typically used at sync time. > > >3) Folder events >4) Expunge Events >5) New mail events >6) Smoothed connection loss caused by the carrier >7) Reduce the set of visible messages per folder > > >Below are the personal drafts that address these issues along with their abstracts. A goal of these drafts was to address the problem specifically with a minimum of variation from the current IMAP RFCs. Clearidle and Checkpoint address the first 6 above. > Does the CHECKPOINT extension try to address # 2. If it does - how? > Number 7 is addressed by Msgfilter. > >Clearidle (See attached) > The IMAPRev4 specification supports unsolicited responses being sent > to a client at any time. The IDLE specification defines a way for a > client to sit in an idle connection waiting to receive these > responses. This document clarifies and extends the set of responses > that a client may receive while in the idle state. The desire is to > allow a client to predict exactly what set of unsolicited responses > it can rely on receiving when listening on an idle connection. > I will send my comments on this document separately. > >http://www.ietf.org/internet-drafts/draft-wener-lemonade-checkpoint-00.txt > This document describes an IMAP extension that aids in allowing a > client to maintain mailbox synchronization without performing a deep > sync after each connection. The goal is to minimize, but not > eliminate, the need for deep synchronizations. The extension defines > a way for a client to receive and acknowledge state change responses > from the server. > I've tried to understand details of the CHECKPOINT extension, however I don't think I was very successful. (Hopefully I got the basic idea, correct me if I've misunderstood something). The main reason for that, IMHO, is because the document makes many assumptions about what the extension is trying to do, but those assumptions are not clearly stated anywhere in the document. And the assumptions look definitely different from my understanding of the IMAP model. For example, the extension assumes that unsolicited responses sent to multiple clients can be shared between all of them. I actually strongly disagree, a user Foo must not be allowed to get responses for the user Bar. If it was not your intent, the document must be clarified that only responses for the same user are shared. I also didn't like some syntactical constructs that you were using, but this is minor. The CHECKPOINT extension pretty much tries to do everything that the CONDSTORE extension can already do (with exception of notifying about expunged messages, which is addressed in the latest RECONNECT draft), although in a slightly different way. The CONDSTORE extension doesn't dictate how it can be implemented, one can use a queue of responses (as CHECKPOINT does). Now, CHECKPOINT requires that all sessions receive exactly the same responses. CONDSTORE is a bit more smart on this. For example, let's imagine that the \Seen flag was set on the message 4 and then later on the \Deleted flag was also set. The CHECKPOINT will send: S: * 4 FETCH (FLAGS (\Recent \Seen)) (1006) ... S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted)) (1054) The CONDSTORE only requires a single response: S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted) MODSEQ (1054)) (observe that "a CHECKPOINT response number" can be the same as CONDSTORE "modification sequence"). Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 14:29:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15397 for ; Sun, 7 Nov 2004 14:29:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsjm-0001hX-7L for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 14:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsbs-0005Lm-OZ; Sun, 07 Nov 2004 14:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsZT-0004jY-Se for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 14:19:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14798 for ; Sun, 7 Nov 2004 14:19:26 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsZr-0001Tj-0Y for lemonade@ietf.org; Sun, 07 Nov 2004 14:19:52 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 19:18:52 +0000 Message-ID: <418E751A.10101@isode.com> Date: Sun, 07 Nov 2004 19:18:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Maes Subject: Re: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 References: <12934746.1099855735906.JavaMail.besadmin@web69> In-Reply-To: <12934746.1099855735906.JavaMail.besadmin@web69> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Stephane Maes wrote: >Agreed. > >In my view the difference is non persistence. > > With FILTER SET TAG filters can be persistent, they just don't create a virtual mailbox as P-IMAP does. Anyway, I don't think we need two competing proposals. >There may be use case for that but for P-IMAP and its use case, the filter must be permanent or the concept of mobile repository and filters would not help and rather burden the user. > >Michael.Wener@nokia.com wrote: > > >>>Isn't it [MSGFILTER] the mechanism proposed by XFILTER in P-IMAP? >>> >>> >>No. >> >> >Actually, it seems that there is a lot of overlap between the >[MSGFILTER] "FILTER SET" and the [P-IMAP] XFILTER/XPSEARCH commands. >This also brings memories of long expired IMAPEXT VIEW extension. > >Alexey > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 14:33:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15667 for ; Sun, 7 Nov 2004 14:33:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsns-0001lS-Ch for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 14:34:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQskJ-0006hG-3b; Sun, 07 Nov 2004 14:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsdI-0005SZ-PW for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 14:23:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15076 for ; Sun, 7 Nov 2004 14:23:23 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsdf-0001aW-VI for lemonade@ietf.org; Sun, 07 Nov 2004 14:23:49 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 19:22:44 +0000 Message-ID: <418E7603.7030506@isode.com> Date: Sun, 07 Nov 2004 19:22:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Maes Subject: Re: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues) References: <539112.1099855943921.JavaMail.besadmin@web69> In-Reply-To: <539112.1099855943921.JavaMail.besadmin@web69> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Stephane Maes wrote: >In my view CHECKPOINT + CLEARIDLE try to achieve the same as CONDSTORE but monitoring more changes. > > Yes ("CONDSTORE + some bits of RECONNECT"). >What is the status of CONDSTORE. > It is an approved document (1 year now). However it depends on yet not finished document, that is why there is no RFC #. > Can't the additional diff items be added to CONDSTORE at IMAP Ext? > > We can always specify an extension. Under extreme circumstances, we can try to revise CONDSTORE before it gets published. What kind of addition are you thinking about. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 14:35:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15792 for ; Sun, 7 Nov 2004 14:35:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQspA-0001nT-2u for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 14:35:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQskK-0006i5-HC; Sun, 07 Nov 2004 14:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQseL-0005gP-Jg for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 14:24:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15128 for ; Sun, 7 Nov 2004 14:24:27 -0500 (EST) Received: from agminet04.oracle.com ([141.146.126.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsej-0001ba-UM for lemonade@ietf.org; Sun, 07 Nov 2004 14:24:54 -0500 Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JNwRD031434 for ; Sun, 7 Nov 2004 11:23:58 -0800 Received: from web69 (web69.oracle.com [148.87.122.101]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JNv4R031410 for ; Sun, 7 Nov 2004 11:23:57 -0800 Message-ID: <19989719.1099856264687.JavaMail.besadmin@web69> Date: Sun, 7 Nov 2004 12:37:44 -0700 From: Stephane Maes To: alexey.melnikov@isode.com Subject: Re: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Thread-Topic: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 Thread-Index: AcTFAMOFqsr1s+SdSbiUHsgz5cLzVQAAH0Bv X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Not sure about persistency in FILTERSET. Strong agreement of no need of competing proposal. Strong view that we need to enable the virtual mailbox of XFilter. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM, Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: Alexey Melnikov To: Stephane Maes CC: lemonade@ietf.org Sent: Sun Nov 07 12:18:50 2004 Subject: Re: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 Stephane Maes wrote: >Agreed. > >In my view the difference is non persistence. > > With FILTER SET TAG filters can be persistent, they just don't create a virtual mailbox as P-IMAP does. Anyway, I don't think we need two competing proposals. >There may be use case for that but for P-IMAP and its use case, the filter must be permanent or the concept of mobile repository and filters would not help and rather burden the user. > >Michael.Wener@nokia.com wrote: > > >>>Isn't it [MSGFILTER] the mechanism proposed by XFILTER in P-IMAP? >>> >>> >>No. >> >> >Actually, it seems that there is a lot of overlap between the >[MSGFILTER] "FILTER SET" and the [P-IMAP] XFILTER/XPSEARCH commands. >This also brings memories of long expired IMAPEXT VIEW extension. > >Alexey > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 14:36:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15926 for ; Sun, 7 Nov 2004 14:36:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsqH-0001pA-7o for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 14:36:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQskR-0006mK-A5; Sun, 07 Nov 2004 14:30:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsjD-0006Qk-1k for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 14:29:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15389 for ; Sun, 7 Nov 2004 14:29:29 -0500 (EST) Received: from agminet04.oracle.com ([141.146.126.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsjb-0001gn-EB for lemonade@ietf.org; Sun, 07 Nov 2004 14:29:55 -0500 Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JT0iC002719 for ; Sun, 7 Nov 2004 11:29:00 -0800 Received: from web69 (web69.oracle.com [148.87.122.101]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JSwCO002598 for ; Sun, 7 Nov 2004 11:28:59 -0800 Message-ID: <19237538.1099856566140.JavaMail.besadmin@web69> Date: Sun, 7 Nov 2004 12:42:45 -0700 From: Stephane Maes To: alexey.melnikov@isode.com Subject: Re: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Thread-Topic: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues) Thread-Index: AcTFAVoxrLe4GdZHR5GMA6mvkwBbXgAAJoDs X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Support the changed that Michael proposes the monitor in his drafts. Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM, Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: Alexey Melnikov To: Stephane Maes CC: lemonade@ietf.org Sent: Sun Nov 07 12:22:43 2004 Subject: Re: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues) Stephane Maes wrote: >In my view CHECKPOINT + CLEARIDLE try to achieve the same as CONDSTORE but monitoring more changes. > > Yes ("CONDSTORE + some bits of RECONNECT"). >What is the status of CONDSTORE. > It is an approved document (1 year now). However it depends on yet not finished document, that is why there is no RFC #. > Can't the additional diff items be added to CONDSTORE at IMAP Ext? > > We can always specify an extension. Under extreme circumstances, we can try to revise CONDSTORE before it gets published. What kind of addition are you thinking about. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 14:40:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16382 for ; Sun, 7 Nov 2004 14:40:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsug-0001wo-8J for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 14:41:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsqV-0007vw-R0; Sun, 07 Nov 2004 14:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsoy-0007dO-70 for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 14:35:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15844 for ; Sun, 7 Nov 2004 14:35:26 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQspL-0001nA-Gl for lemonade@ietf.org; Sun, 07 Nov 2004 14:35:52 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 19:34:52 +0000 Message-ID: <418E78DB.7040600@isode.com> Date: Sun, 07 Nov 2004 19:34:51 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Maes Subject: Re: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 References: <6489670.1099856264687.JavaMail.besadmin@web69> In-Reply-To: <6489670.1099856264687.JavaMail.besadmin@web69> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Stephane Maes wrote: >Strong view that we need to enable the virtual mailbox of XFilter. > > As far as I am concerned, this is just a detail. If I was a client writer I probably wouldn't care if I need to select a virtual mailbox or enable a filter on the current one. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 14:41:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16494 for ; Sun, 7 Nov 2004 14:41:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsvT-0001yJ-1l for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 14:42:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsqW-0007w7-2X; Sun, 07 Nov 2004 14:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQspD-0007ea-1j for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 14:35:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15847 for ; Sun, 7 Nov 2004 14:35:41 -0500 (EST) Received: from agminet04.oracle.com ([141.146.126.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQspb-0001nO-GT for lemonade@ietf.org; Sun, 07 Nov 2004 14:36:07 -0500 Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JZCvw006845 for ; Sun, 7 Nov 2004 11:35:12 -0800 Received: from web69 (web69.oracle.com [148.87.122.101]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA7JZBWe006826 for ; Sun, 7 Nov 2004 11:35:11 -0800 Message-ID: <29859976.1099856938296.JavaMail.besadmin@web69> Date: Sun, 7 Nov 2004 12:48:57 -0700 From: Stephane Maes To: lemonade@ietf.org Subject: Re: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Thread-Topic: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization Thread-Index: AcTFAtILOA1FII/0S+COhfNC/s2goA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit BTW, CLEARIDLE and CHECKPOINT are presented as alternate solution to mobile e-mail. I do not share that view. They are proposed improvement to IDLE. However IDLE poses significant problems for mobile e-mail: - client battery life and processing reqs - server scalability (open port per IDLE client! + queuing) - overall efficiency. We should not confuse improving IDLE vs addressimng the problem and use cases of mobile e-mail. I am less and less incline to using IDLE even as a sample option in P-IMAP. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM, Y!) or stephane_maes@hotmail.com (MSN Messenger) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 17:46:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06952 for ; Sun, 7 Nov 2004 17:46:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvog-00071f-3i for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 17:47:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvnB-000816-09; Sun, 07 Nov 2004 17:45:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvhf-0006PK-Pa for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 17:40:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06236 for ; Sun, 7 Nov 2004 17:40:04 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvi4-0006o5-Q5 for lemonade@ietf.org; Sun, 07 Nov 2004 17:40:34 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA7Md5v1028724 for ; Sun, 7 Nov 2004 17:39:07 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Nov 2004 17:36:12 -0500 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Sun, 7 Nov 2004 17:36:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [lemonade] Scribes for Wednesday 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed We have a scribe for Monday. We really, really need a volunteer for Wednesday. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 18:35:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10826 for ; Sun, 7 Nov 2004 18:35:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQwa9-0007xg-UY for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 18:36:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQwYw-0004RI-KL; Sun, 07 Nov 2004 18:35:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQwXs-0004B6-Gk for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 18:34:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10618 for ; Sun, 7 Nov 2004 18:34:01 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQwYI-0007tV-Lo for lemonade@ietf.org; Sun, 07 Nov 2004 18:34:31 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA7NXxE13493; Mon, 8 Nov 2004 01:33:59 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 01:33:44 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA7NXiuQ025511; Mon, 8 Nov 2004 01:33:44 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 008WFALS; Mon, 08 Nov 2004 01:33:42 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA7NWca10256; Mon, 8 Nov 2004 01:32:38 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 7 Nov 2004 17:32:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2004 17:32:36 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B6F@daebe005.americas.nokia.com> Thread-Topic: Comments about CHECKPOINT (was Re: Mobile synchronization issues) thread-index: AcTE5lnyhX1EAFclREqiSQ+y00uq9wAOPY/g To: X-OriginalArrivalTime: 07 Nov 2004 23:32:37.0891 (UTC) FILETIME=[110E0D30:01C4C522] X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org Subject: [lemonade] RE: Comments about CHECKPOINT (was Re: Mobile synchronization issues) 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Sunday, November 07, 2004 11:24 AM ... > >I do not believe the current set of drafts address directly=20 > the primary mobile synchronization issues. I believe a full=20 > solution must cover: > >1) Multi-Folder monitoring > >2) Mitigate the N*M algorithm typically used at sync time. ... > Does the CHECKPOINT extension try to address # 2. If it does - how? CHECKPOINT combined with CLEARIDLE addresses #2. An IDLE CHECKPOINT = command is issued in the authenticated state. The responses defined in = CLEARIDLE then include imap urls. This in effect does not require the N = SELECTs to visit each folder. Note that N*M based resyncs are stilled required at certain reconnects, = but they should be less frequent. ... > from my understanding of the IMAP model. For example, the extension=20 > assumes that unsolicited responses sent to multiple clients can be=20 > shared between all of them. I actually strongly disagree, a user Foo=20 > must not be allowed to get responses for the user Bar. If it was not=20 > your intent, the document must be clarified that only=20 > responses for the=20 > same user are shared. It allows responses with IMAPURLs to be shared. Correct me if I'm wrong = but an IMAPURL basically allows one to export information from one = session to another. Is this not what URLAUTH does when used with BURL. > The CHECKPOINT extension pretty much tries to do everything that the=20 > CONDSTORE extension can already do (with exception of notifying about=20 > expunged messages, which is addressed in the latest RECONNECT draft),=20 > although in a slightly different way. The main differences between CONDSTORE are: 1) Expunge support=20 2) Folder change support 3) It works from the authenticated state and therefore does not require = the folder SELECT iteration. ... > Now, CHECKPOINT requires that all sessions receive exactly the same=20 > responses. CONDSTORE is a bit more smart on this. For example, let's=20 > imagine that the \Seen flag was set on the message 4 and then=20 > later on=20 > the \Deleted flag was also set. The CHECKPOINT will send: >=20 > S: * 4 FETCH (FLAGS (\Recent \Seen)) (1006) > ... > S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted)) (1054) >=20 > The CONDSTORE only requires a single response: >=20 > S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted) MODSEQ (1054)) >=20 Here is the difference. CHECKPOINT sends responses quasi-real-time, = which means that one of it's goals is to maximize the response time at = the client. It is greedy in the sense that information is sent as soon = as it is available. When it is disconnected it may have the = characteristic you mention, but it does not need to An implementation = could perform the response aggregation you mention. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 19:04:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12752 for ; Sun, 7 Nov 2004 19:04:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQx28-0008Vn-Ot for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 19:05:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQx0o-0007at-KM; Sun, 07 Nov 2004 19:03:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQwxj-0006vB-3e for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 19:00:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12269 for ; Sun, 7 Nov 2004 19:00:43 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQwy6-0008O3-GW for lemonade@ietf.org; Sun, 07 Nov 2004 19:01:13 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA800el10218; Mon, 8 Nov 2004 02:00:40 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 01:59:47 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA7Nxl4O031941; Mon, 8 Nov 2004 01:59:47 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00uzaQRF; Mon, 08 Nov 2004 01:59:46 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA7NxjS27251; Mon, 8 Nov 2004 01:59:45 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 7 Nov 2004 17:59:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2004 17:59:43 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B70@daebe005.americas.nokia.com> Thread-Topic: Comments about CLEARIDLE thread-index: AcTE7gvuUMHVh4GPTnOCiiIhby0loQANGoVg To: X-OriginalArrivalTime: 07 Nov 2004 23:59:45.0167 (UTC) FILETIME=[DAFCA9F0:01C4C525] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, ietf-imapext@imc.org Subject: [lemonade] RE: Comments about CLEARIDLE 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Sunday, November 07, 2004 12:18 PM ... > One thing the needs discussing is whether the problem of=20 > receiving flag=20 > changes/new mail notifications for multiple mailboxes (over a single=20 > connection) is worth solving. I frankly don't know for sure. The sync algorithm for IMAP assumes multiple mailboxes so I=20 don't understand why it would not be of interest. > I suggest you review the LISTEXT extension (currently=20 > draft-ietf-imapext-list-extensions-10.txt). > \Deleted is the same as \NonExistent. Agreed. > This might be less obvious for people not following IMAPEXT,=20 > but there=20 > was a proposal to have REFERRAL data returned in LIST responses. It=20 > serves exactly this purpose. See=20 > ,=20 > item # 5. > It also avoids the proposed hack (sorry, I can't find a=20 > better word) of=20 > tying two LIST responses together. I did not like tying the two together either. I assume the semantics are that when a renamed folder is requested by the client via a LIST the server will send a referring url? For=20 how long does the server need to remember the reference? > > Example: > > S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE=20 > (...) BODY (...)) >=20 > Actually no, BODY must not be in this list, as it is potentially very=20 > big. You surely wouldn't want to push a 10Mb message to you=20 > cell phone. > I also suggest to replace the ENVELOPE with the BODYSTRUCTURE. I agree no MIME content is sent. That is why I used BODY and not BODY[]. BODYSTRUCTURE would do. > Why can't we just you the STATUS response? >=20 > S: * STATUS INBOX (MESSAGES 231 RECENT 7) Agreed. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 19:18:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13853 for ; Sun, 7 Nov 2004 19:18:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxFH-0000M7-Eq for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 19:18:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQx4U-0008JG-SE; Sun, 07 Nov 2004 19:07:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQx3e-0008CW-2e for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 19:06:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12899 for ; Sun, 7 Nov 2004 19:06:50 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQx43-00006g-Mj for lemonade@ietf.org; Sun, 07 Nov 2004 19:07:21 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA806kE14559; Mon, 8 Nov 2004 02:06:46 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 02:05:09 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA8059DM009784; Mon, 8 Nov 2004 02:05:09 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00MszIrP; Mon, 08 Nov 2004 02:05:08 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8057S29800; Mon, 8 Nov 2004 02:05:07 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 7 Nov 2004 18:05:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 Date: Sun, 7 Nov 2004 18:05:05 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB54@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Alternate Solution to Mobile MailSynchronizationOptimization - part 2 thread-index: AcTE9ZqnjhhVxTDYROKdhdZlgfN8SwAMIqoA To: X-OriginalArrivalTime: 08 Nov 2004 00:05:06.0803 (UTC) FILETIME=[9AB26C30:01C4C526] X-Spam-Score: 1.3 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, stephane.maes@oracle.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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Sunday, November 07, 2004 1:14 PM ... > This also brings memories of long expired IMAPEXT VIEW extension. I borrowed the syntax from the WINDOW draft because I thought=20 they were very clear. The semantics are different. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 19:37:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15473 for ; Sun, 7 Nov 2004 19:37:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxXT-0000nQ-Hz for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 19:37:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxNt-0002E7-Pd; Sun, 07 Nov 2004 19:27:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxIN-0001W2-TG for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 19:22:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14138 for ; Sun, 7 Nov 2004 19:22:04 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxIn-0000Rr-PS for lemonade@ietf.org; Sun, 07 Nov 2004 19:22:35 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA80M2321793; Mon, 8 Nov 2004 02:22:02 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 02:21:06 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA80L6QH023491; Mon, 8 Nov 2004 02:21:06 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00z8d4sI; Mon, 08 Nov 2004 02:21:06 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA80Ksa16081; Mon, 8 Nov 2004 02:20:54 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 7 Nov 2004 18:20:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Alternate Solution to MobileMailSynchronizationOptimization - part 2 Date: Sun, 7 Nov 2004 18:20:51 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B71@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Alternate Solution to MobileMailSynchronizationOptimization - part 2 thread-index: AcTE95jokYzb5jKrTNGPx0zujLVM4AACGxqzAAmrjnA= To: , X-OriginalArrivalTime: 08 Nov 2004 00:20:53.0029 (UTC) FILETIME=[CEB10D50:01C4C528] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Stephane Maes > Sent: Sunday, November 07, 2004 2:29 PM ... > Agreed. There is overlap. >=20 > In my view the difference is non persistence.=20 >=20 The differences are: 1) The filters are self-cleaning. There is no need for the client to do=20 anything to turn them off. Opaque filters are by thier nature=20 persistent, but there is no work on the clients part to maintain them. 2) Filters may be accumulated. 3) Filters are definitive. That is, once a session is in filtering mode = the=20 filter set is the only set available. So even if you issue a FETCH = command the criteria are applied to the response. The client will see a true = abstract folder for the duration of the filter.=20 P-IMAP has two types of filters: notification filters and view filters. = They can differ. In MSGFILTER they are intended to be the same. So the client = has a consistent view of what is on the server. 4) Supports opaque filter names. > There may be use case for that but for P-IMAP and its use=20 > case, the filter must be permanent or the concept of mobile=20 > repository and filters would not help and rather burden the user. On the contrary I believe P-IMAP shifts more responsibility to the=20 client. The client must know filter criteria in order to issue the first XFILTER command. The client must be a configurator. The TAG option of FILTER SET allows the client to use a name like=20 DEFAULT, which all clients know. So no client requires any knowledge=20 of criteria. FILTER SET also allows a knowledgeable client. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 19:41:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15813 for ; Sun, 7 Nov 2004 19:41:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxbq-0000tQ-6p for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 19:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxa2-0003qs-TJ; Sun, 07 Nov 2004 19:40:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxOm-0002T6-UF for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 19:28:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14580 for ; Sun, 7 Nov 2004 19:28:41 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxPD-0000Yu-PJ for lemonade@ietf.org; Sun, 07 Nov 2004 19:29:12 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iA80STOO079934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2004 17:28:31 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Sun, 07 Nov 2004 16:28:28 -0800 From: Lyndon Nerenberg To: lemonade@ietf.org, IMAP Extensions WG Message-ID: In-Reply-To: <418E58DE.4000401@isode.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA94@daebe005.americas.n okia.com> <418E4C25.6090103@isode.com> <418E58DE.4000401@isode.com> X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [lemonade] Re: Comments about CLEARIDLE 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit --On 2004-11-7 5:18 PM +0000 Alexey Melnikov wrote: > > One thing the needs discussing is whether the problem of receiving > flag changes/new mail notifications for multiple mailboxes (over a > single connection) is worth solving. I frankly don't know for sure. It has been brought up enough times over the last five years that I am convinced it is. I wrote a non-published draft a few years back that proposed a solution to the multiple-mailbox newmail notification problem. And since the issue has come up once again over the last few months I have updated the draft and will submit it after the IETF. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 19:48:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16704 for ; Sun, 7 Nov 2004 19:48:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxiJ-00014w-JX for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 19:48:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxaW-00043P-B8; Sun, 07 Nov 2004 19:40:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxYV-0003aQ-Jt for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 19:38:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15558 for ; Sun, 7 Nov 2004 19:38:44 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxYw-0000pE-Jf for lemonade@ietf.org; Sun, 07 Nov 2004 19:39:15 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA80cjE16177; Mon, 8 Nov 2004 02:38:45 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 02:37:53 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA80brAm007558; Mon, 8 Nov 2004 02:37:53 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 003fIYSq; Mon, 08 Nov 2004 02:37:51 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA80bpS16456; Mon, 8 Nov 2004 02:37:51 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 7 Nov 2004 18:37:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2004 18:37:34 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B72@daebe005.americas.nokia.com> Thread-Topic: Comments/questions about MSGFILTER thread-index: AcTE+dGlQ2/Y5DoiQ7S28WZiNmv+9gALy8ug To: X-OriginalArrivalTime: 08 Nov 2004 00:37:35.0591 (UTC) FILETIME=[2443DF70:01C4C52B] X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org Subject: [lemonade] RE: Comments/questions about MSGFILTER 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Sunday, November 07, 2004 1:44 PM ... > I think the extension is lacking the ability to list=20 > available external=20 > filters. Yes. It was intentional. Since the management of the filters, i.e. there = definition,=20 was opaque to the protocol I thought it better to be consistent. I could = see how it would be valuable to list them, though. Note that the logic of the = criteria in the=20 TAG filters is completely opaque to IMAP. ... > > The rules of accumulation are: > > > > 1) TAG Sub-Commands MUST replace ALL previous Sub-Commands, > > including previous TAG Sub-Commands. > > 2) New SEARCH sub-commands MUST replace a previous SEARCH > > Sub-Command. New SEARCH sub-commands MUST union=20 > with previous > > TAG commands. >=20 > Just to clarify: is SEARCH performed only once (when the command is=20 > issued) or it is done every time a new message arrives? I assume you are talking about the implementation. The semantics require = the criteria to be applied to each new message. This is not the same as = executing an entire new SEARCH command. In the case of accumulation each FILTER SET command would require the criteria to be applied to the entire folder. ... > > An EXISTS response is sent as the first response in a=20 > Filter Set. It > > represents the total number of messages visible after the > > application of the latest FILTER SET. >=20 > I suggest you define a new response instead. Why? One of my goals was to try and minimize the additions/modifications = to the protocol. >=20 > > Example: C: 1 SELECT INBOX > > S: * 50 EXISTS > [...] > > S: 3 OK FILTER SET Completed > > C: 4 FETCH >=20 > The example seems to be truncated. Yes. ... > > The FILTERED response is returned when any command is issued in > > the Selected state and the sequence or UID arguments=20 > are sets that > > may include numbers not explicitly asked for by the client. >=20 > Ok, you need to describe what would be the behavior of STORE/COPY=20 > commands, when a filter is in effect. I would presume that STORE/COPY=20 > are not affected. So effectively a filter only affects which FETCH=20 > responses are to be returned? What about SEARCH? The intent was to affect all commands that operate on messages. The = result=20 is that the client does not "see" excluded messages via any command = while=20 a FILTER SET is in effect. The reason is to reduce the burden on the client.=20 Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 19:53:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17271 for ; Sun, 7 Nov 2004 19:53:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxnC-0001Bn-95 for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 19:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxju-0005LR-04; Sun, 07 Nov 2004 19:50:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxaZ-00044P-8U for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 19:40:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15701 for ; Sun, 7 Nov 2004 19:40:51 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxaz-0000sI-BI for lemonade@ietf.org; Sun, 07 Nov 2004 19:41:22 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA80eel26220; Mon, 8 Nov 2004 02:40:40 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 02:40:03 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA80e3Oh032545; Mon, 8 Nov 2004 02:40:03 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00vXaqyF; Mon, 08 Nov 2004 02:40:02 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA80e0a29268; Mon, 8 Nov 2004 02:40:00 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 7 Nov 2004 18:39:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments about CHECKPOINT (was Re: Mobilesynchronization issues) Date: Sun, 7 Nov 2004 18:39:58 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB57@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Comments about CHECKPOINT (was Re: Mobilesynchronization issues) thread-index: AcTE6dmR0w3kDZCxTXSBCVqn0zlamQAFqe9SAAq2hSA= To: , X-OriginalArrivalTime: 08 Nov 2004 00:39:59.0966 (UTC) FILETIME=[7A51BFE0:01C4C52B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Stephane Maes ... > In my view CHECKPOINT + CLEARIDLE try to achieve the same as=20 > CONDSTORE but monitoring more changes. Not quite. See my response containing the differences. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 7 20:13:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18933 for ; Sun, 7 Nov 2004 20:13:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQy6b-0001cJ-6O for lemonade-web-archive@ietf.org; Sun, 07 Nov 2004 20:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQy3e-0008Ej-VS; Sun, 07 Nov 2004 20:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQy2M-0007n6-Lo for lemonade@megatron.ietf.org; Sun, 07 Nov 2004 20:09:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18517 for ; Sun, 7 Nov 2004 20:09:36 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQy2k-0001WL-Ut for lemonade@ietf.org; Sun, 07 Nov 2004 20:10:06 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA819Sl00854; Mon, 8 Nov 2004 03:09:28 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 03:10:20 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA81AKQf032354; Mon, 8 Nov 2004 03:10:20 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00K7zcuh; Mon, 08 Nov 2004 03:10:18 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8198a22910; Mon, 8 Nov 2004 03:09:08 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 7 Nov 2004 19:09:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Alternate Solution to MobileMailSynchronizationOptimization Date: Sun, 7 Nov 2004 19:09:06 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B73@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Alternate Solution to MobileMailSynchronizationOptimization thread-index: AcTFAtILOA1FII/0S+COhfNC/s2goAAKWAoQ To: , X-OriginalArrivalTime: 08 Nov 2004 01:09:07.0937 (UTC) FILETIME=[8C30F510:01C4C52F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Stephane Maes > Sent: Sunday, November 07, 2004 2:49 PM ... > I do not share that view. They are proposed improvement to=20 > IDLE. However IDLE poses significant problems for mobile e-mail: > - client battery life and processing reqs Please provide more detail here. I can not take this at face value until I understand the details. CHECKPOINT/CLEARIDLE can support a disconnected model as well as=20 a highly connected model. In the end the only way you will get "quasi-real-time" response=20 behavior at the client is to have a highly connected model. > - server scalability (open port per IDLE client! + queuing) I don't see the port consumption as an issue. Please explain why you think this is a problem? I agree the queuing is something that should be discussed. The draft goes to great pains to allow queues to be short-lived and "self-cleaning". The server queues are only a problem if=20 statistically they reach a certain level that differs for each server. I would appreciate comments from others on this. In general, the scalability answer for IMAP is to split into multiple IMAP servers. No?=20 > - overall efficiency. Please explain? >=20 > We should not confuse improving IDLE vs addressimng the=20 > problem and use cases of mobile e-mail. I am less and less=20 > incline to using IDLE even as a sample option in P-IMAP. The alternates to IDLE in P-IMAP are "in-response" and "out-band".=20 The first is just what we have today. The second is moved out side the scope of IMAP, which basically means we are not solving the problem. This is not adequate for my needs. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 00:40:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08799 for ; Mon, 8 Nov 2004 00:40:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR2HK-0006pU-69 for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 00:41:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR2FK-0006PU-SN; Mon, 08 Nov 2004 00:39:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR2DW-0005fx-5S for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 00:37:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08266 for ; Mon, 8 Nov 2004 00:37:22 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR2Dz-0006jR-Ie for lemonade@ietf.org; Mon, 08 Nov 2004 00:37:55 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iA85bNPE027832; Sun, 7 Nov 2004 21:37:23 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iA85bNRf017481; Sun, 7 Nov 2004 21:37:23 -0800 Date: Sun, 7 Nov 2004 21:37:23 -0800 (PST) From: Mark Crispin To: Michael.Wener@nokia.com Subject: RE: [lemonade] Alternate Solution to MobileMailSynchronizationOptimization In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B73@daebe005.americas.nokia.com> Message-ID: References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B73@daebe005.americas.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, stephane.maes@oracle.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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Sun, 7 Nov 2004 Michael.Wener@nokia.com wrote: >> - server scalability (open port per IDLE client! + queuing) > I don't see the port consumption as an issue. Please explain > why you think this is a problem? As a server developer, I don't see port consumption as an issue; nor has it been an issue since TCP replaced NCP in 1983. -- 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 From lemonade-bounces@ietf.org Mon Nov 8 07:00:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25568 for ; Mon, 8 Nov 2004 07:00:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR8Cb-0006Gb-VE for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 07:00:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8Ar-0004Sm-Ua; Mon, 08 Nov 2004 06:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR854-0003nq-Ix for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 06:53:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24999 for ; Mon, 8 Nov 2004 06:53:03 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR85b-000670-Dr for lemonade@ietf.org; Mon, 08 Nov 2004 06:53:40 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 11:52:03 +0000 Message-ID: <418F5DE2.9000903@isode.com> Date: Mon, 08 Nov 2004 11:52:02 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael.Wener@nokia.com Subject: Re: [lemonade] RE: Comments about CLEARIDLE References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B70@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B70@daebe005.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Michael.Wener@nokia.com wrote: >>One thing the needs discussing is whether the problem of >>receiving flag >>changes/new mail notifications for multiple mailboxes (over a single >>connection) is worth solving. I frankly don't know for sure. >> >> > >The sync algorithm for IMAP assumes multiple mailboxes so I >don't understand why it would not be of interest. > > What is the percentage of users that gets there mail delivered to anything other than INBOX? > [...] > >>This might be less obvious for people not following IMAPEXT, >>but there >>was a proposal to have REFERRAL data returned in LIST responses. It >>serves exactly this purpose. See >>, >>item # 5. >>It also avoids the proposed hack (sorry, I can't find a >>better word) of >>tying two LIST responses together. >> >> > >I did not like tying the two together either. > >I assume the semantics are that when a renamed folder is requested >by the client via a LIST the server will send a referring url? > Yes. >For how long does the server need to remember the reference? > > This is implementation specific. >> > Example: >> > S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE >>(...) BODY (...)) >> >>Actually no, BODY must not be in this list, as it is potentially very >>big. You surely wouldn't want to push a 10Mb message to you >>cell phone. >>I also suggest to replace the ENVELOPE with the BODYSTRUCTURE. >> >> > >I agree no MIME content is sent. That is why I used BODY and not BODY[]. > > My mistake. >BODYSTRUCTURE would do. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 07:51:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00096 for ; Mon, 8 Nov 2004 07:51:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR8zp-0007U7-4a for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 07:51:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8ui-0001UF-I0; Mon, 08 Nov 2004 07:46:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8kx-0000Wb-M1 for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 07:36:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28681 for ; Mon, 8 Nov 2004 07:36:22 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR8lU-00075Z-O9 for lemonade@ietf.org; Mon, 08 Nov 2004 07:36:57 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 12:35:48 +0000 Message-ID: <418F6823.9010403@isode.com> Date: Mon, 08 Nov 2004 12:35:47 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael.Wener@nokia.com Subject: Re: [lemonade] RE: Comments about CHECKPOINT (was Re: Mobile synchronization issues) References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B6F@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B6F@daebe005.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Michael.Wener@nokia.com wrote: >>> <>I do not believe the current set of drafts address directly the >>> primary mobile synchronization issues. I believe a full >>> solution must cover: >> >>>1) Multi-Folder monitoring >>>2) Mitigate the N*M algorithm typically used at sync time. >>> >>> >... > > >>Does the CHECKPOINT extension try to address # 2. If it does - how? >> >> > >CHECKPOINT combined with CLEARIDLE addresses #2. An IDLE CHECKPOINT command is issued in the authenticated state. The responses defined in CLEARIDLE then include imap urls. This in effect does not require the N SELECTs to visit each folder. > > Which is #1. It doesn't affect N*M (actually M1+M2+...MN), because if there are changes to Mi messages in mailbox i, one has to fetch/process Mi responses anyway. >Note that N*M based resyncs are stilled required at certain reconnects, but they should be less frequent. > >... > > >>from my understanding of the IMAP model. For example, the extension >>assumes that unsolicited responses sent to multiple clients can be >>shared between all of them. I actually strongly disagree, a user Foo >>must not be allowed to get responses for the user Bar. If it was not >>your intent, the document must be clarified that only >>responses for the >>same user are shared. >> >> > >It allows responses with IMAPURLs to be shared. Correct me if I'm wrong but an IMAPURL basically allows one to export information from one session to another. Is this not what URLAUTH does when used with BURL. > > Yes, but the person who generates an URLAUTH *authorizes* somebody else to use it. The draft as written may give an impression that all users are notified about all messages arriving for all users. Basically what you are proposing is even worse from security standpoint than the URLAUTH. An URLAUTH URL just gives information about message existence. CLEARIDLE FETCH replies might also contain messages subject and other sensitive information. >>The CHECKPOINT extension pretty much tries to do everything that the >>CONDSTORE extension can already do (with exception of notifying about >>expunged messages, which is addressed in the latest RECONNECT draft), >>although in a slightly different way. >> >> > >The main differences between CONDSTORE are: >1) Expunge support >2) Folder change support >3) It works from the authenticated state and therefore does not require the folder SELECT iteration. > > (CLEARIDLE is needed to address # 3. I was comparing only CONDSTORE and CHECKPOINT) I might agree that 2 and 3 are worth solving, but this is not a job for CONDSTORE or CHECKPOINT (it seems to belong to CLEARIDLE). As I mentioned before, #1 is already addressed in RECONNECT, although arguable it should be a separate extension to the CONDSTORE extension. >... > > >>Now, CHECKPOINT requires that all sessions receive exactly the same >>responses. CONDSTORE is a bit more smart on this. For example, let's >>imagine that the \Seen flag was set on the message 4 and then >>later on >>the \Deleted flag was also set. The CHECKPOINT will send: >> >> S: * 4 FETCH (FLAGS (\Recent \Seen)) (1006) >> ... >> S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted)) (1054) >> >>The CONDSTORE only requires a single response: >> >> S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted) MODSEQ (1054)) >> >> > >Here is the difference. CHECKPOINT sends responses quasi-real-time, which means that one of it's goals is to maximize the response time at the client. It is greedy in the sense that information is sent as soon as it is available. When it is disconnected it may have the characteristic you mention, but it does not need to. An implementation could perform the response aggregation you mention. > > This is not clear from you document, if I understood the CHECKPOINT properly, the server is not allowed to skip responses. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 08:05:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02276 for ; Mon, 8 Nov 2004 08:05:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR9Dw-00082r-SF for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 08:06:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR97c-0003kG-UW; Mon, 08 Nov 2004 07:59:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8xq-0001tb-C6 for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 07:49:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29849 for ; Mon, 8 Nov 2004 07:49:41 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR8yN-0007Op-JC for lemonade@ietf.org; Mon, 08 Nov 2004 07:50:16 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 12:49:07 +0000 Message-ID: <418F6B42.2030802@isode.com> Date: Mon, 08 Nov 2004 12:49:06 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael.Wener@nokia.com Subject: Re: [lemonade] RE: Comments/questions about MSGFILTER References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B72@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B72@daebe005.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Michael.Wener@nokia.com wrote: >>-----Original Message----- >>From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] >>Sent: Sunday, November 07, 2004 1:44 PM >> >> >... > > >>I think the extension is lacking the ability to list >>available external filters. >> >> > >Yes. It was intentional. Since the management of the filters, i.e. there definition, >was opaque to the protocol I thought it better to be consistent. I could see how >it would be valuable to list them, though. Note that the logic of the criteria in the >TAG filters is completely opaque to IMAP. > > If you want any kind of interoperability between multiple clients, you either need a command to list named filters, or there should be an official registry of filter names. You've already mentioned a filter tag "DEFAULT". I think the document should at least mention it. >... > > >> > The rules of accumulation are: >> > >> > 1) TAG Sub-Commands MUST replace ALL previous Sub-Commands, >> > including previous TAG Sub-Commands. >> > 2) New SEARCH sub-commands MUST replace a previous SEARCH >> > Sub-Command. New SEARCH sub-commands MUST union >>with previous >> > TAG commands. >> >>Just to clarify: is SEARCH performed only once (when the command is >>issued) or it is done every time a new message arrives? >> >> > >I assume you are talking about the implementation. > No, I was actually asking if the FILTER SET SEARCH is static or dynamic. Dynamic means that any new message is evaluated against filter criteria and existing messages can drop out of the filter, for example if the filter search criteria depends on some flags that change. > The semantics require the >criteria to be applied to each new message. This is not the same as executing >an entire new SEARCH command. > > I agree. >In the case of accumulation each FILTER SET command would require the >criteria to be applied to the entire folder. > >... > > >> > An EXISTS response is sent as the first response in a >>Filter Set. It >> > represents the total number of messages visible after the >> > application of the latest FILTER SET. >> >>I suggest you define a new response instead. >> >> > >Why? One of my goals was to try and minimize the additions/modifications >to the protocol. > I prefer not to overload existing responses. Do you want the client to be notified about new message arrivals, even if the corresponding messages are filtered out? >... > > >> > The FILTERED response is returned when any command is issued in >> > the Selected state and the sequence or UID arguments >>are sets that >> > may include numbers not explicitly asked for by the client. >> >>Ok, you need to describe what would be the behavior of STORE/COPY >>commands, when a filter is in effect. I would presume that STORE/COPY >>are not affected. So effectively a filter only affects which FETCH >>responses are to be returned? What about SEARCH? >> >> > >The intent was to affect all commands that operate on messages. The result >is that the client does not "see" excluded messages via any command while >a FILTER SET is in effect. > > The document must say so. I frankly see no point of restricting STORE/COPY (especially UID STORE/COPY). This also means that SEARCH would have to intersect the specified search criteria with the current filter? >The reason is to reduce the burden on the client. > > One more question: Does the filter go away when the selected mailbox is closed? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 09:00:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09097 for ; Mon, 8 Nov 2004 09:00:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRA4U-0001Q2-75 for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 09:00:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9ri-0003bP-5y; Mon, 08 Nov 2004 08:47:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9eX-0000PI-KV for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 08:33:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05582 for ; Mon, 8 Nov 2004 08:33:47 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR9f5-0000Sy-Gn for lemonade@ietf.org; Mon, 08 Nov 2004 08:34:23 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8DXkv17596; Mon, 8 Nov 2004 15:33:46 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 15:31:04 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA8DV4SG008064; Mon, 8 Nov 2004 15:31:04 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00VS15g3; Mon, 08 Nov 2004 15:30:18 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8DU7S22791; Mon, 8 Nov 2004 15:30:07 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 07:29:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] RE: Comments about CLEARIDLE Date: Mon, 8 Nov 2004 07:29:34 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B74@daebe005.americas.nokia.com> Thread-Topic: [lemonade] RE: Comments about CLEARIDLE thread-index: AcTFihf+JS0kwNz0SZGKP85iWu/SvwACsN4w To: X-OriginalArrivalTime: 08 Nov 2004 13:29:35.0893 (UTC) FILETIME=[FD510C50:01C4C596] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Monday, November 08, 2004 6:52 AM ... > >>One thing the needs discussing is whether the problem of=20 > >>receiving flag=20 > >>changes/new mail notifications for multiple mailboxes (over=20 > a single=20 > >>connection) is worth solving. I frankly don't know for sure. > >> =20 > >> > > > >The sync algorithm for IMAP assumes multiple mailboxes so I=20 > >don't understand why it would not be of interest. > > =20 > > > What is the percentage of users that gets there mail delivered to=20 > anything other than INBOX? So the distinction is not so much one vs multiple it is between=20 INBOX and other folders. I think a more interesting question is can non INBOX folder state=20 change for a client either while connected or disconnected. The=20 answer is yes. The messages may not be "delivered" in the sense that it is delivered to an INBOX, but messages can certainly appear. For example it could be a shared folder. I would agree that a more common use case is the use case for conventional delivery to the inbox, but if a solution can be had=20 for an arbitrary folder why not use it. At the very least the asymmetry of the solution bothers me. Yes, I know this is subjective. > >>This might be less obvious for people not following IMAPEXT,=20 > >>but there=20 > >>was a proposal to have REFERRAL data returned in LIST responses. It=20 > >>serves exactly this purpose. See=20 > >>,=20 > >>item # 5. ... > >For how long does the server need to remember the reference? > > =20 > > > This is implementation specific. I can see it working, but why not use something like \Renamed=20 (Sent once)? You have to admit Referral was targeted at solving=20 a slightly different problem. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 09:01:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09362 for ; Mon, 8 Nov 2004 09:01:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRA6E-0001VG-IG for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 09:02:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9sW-0004Df-Oe; Mon, 08 Nov 2004 08:48:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9l0-0001vf-RV for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 08:40:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06350 for ; Mon, 8 Nov 2004 08:40:29 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR9lX-0000gp-Ow for lemonade@ietf.org; Mon, 08 Nov 2004 08:41:05 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 13:39:52 +0000 Message-ID: <418F7727.8090007@isode.com> Date: Mon, 08 Nov 2004 13:39:51 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael.Wener@nokia.com Subject: Re: [lemonade] RE: Comments about CLEARIDLE References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B74@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B74@daebe005.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Michael.Wener@nokia.com wrote: >>What is the percentage of users that gets there mail delivered to >>anything other than INBOX? >> >> >So the distinction is not so much one vs multiple it is between >INBOX and other folders. > >I think a more interesting question is can non INBOX folder state >change for a client either while connected or disconnected. The >answer is yes. The messages may not be "delivered" in the sense >that it is delivered to an INBOX, but messages can certainly >appear. For example it could be a shared folder. > >I would agree that a more common use case is the use case for >conventional delivery to the inbox, but if a solution can be had >for an arbitrary folder why not use it. > > Speaking as a server implementor: the choice of allowing notifications from multiple mailboxes has deep impact on server implementations. The proposed solution is much easier for the clients then for the servers. >At the very least the asymmetry of the solution bothers me. Yes, I >know this is subjective. > > >>>>This might be less obvious for people not following IMAPEXT, >>>>but there was a proposal to have REFERRAL data returned in LIST responses. It >>>>serves exactly this purpose. See >>>>, >>>>item # 5. >>>> >>>> >... > > >>>For how long does the server need to remember the reference? >>> >>> >>This is implementation specific. >> >> >I can see it working, but why not use something like \Renamed >(Sent once)? You have to admit Referral was targeted at solving >a slightly different problem. > > I think you are assuming how this is implemented. Referrals can be kept in memory and can be sent only once. So, apart from the syntax, there is no difference between your \Renamed proposal and my REFERRAL proposal. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 09:47:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14504 for ; Mon, 8 Nov 2004 09:47:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAoY-0002sx-DI for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 09:48:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRASP-0004Rb-0R; Mon, 08 Nov 2004 09:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAHP-0001T0-QA for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 09:13:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10543 for ; Mon, 8 Nov 2004 09:13:57 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAHx-0001qh-QW for lemonade@ietf.org; Mon, 08 Nov 2004 09:14:34 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8EDuv25648; Mon, 8 Nov 2004 16:13:56 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 16:10:48 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA8EAmFT007136; Mon, 8 Nov 2004 16:10:48 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00pSs9Fm; Mon, 08 Nov 2004 16:10:48 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8EAlS25513; Mon, 8 Nov 2004 16:10:47 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 08:10:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] RE: Comments about CHECKPOINT (was Re: Mobile synchronization issues) Date: Mon, 8 Nov 2004 08:10:11 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB5D@daebe005.americas.nokia.com> Thread-Topic: [lemonade] RE: Comments about CHECKPOINT (was Re: Mobile synchronization issues) thread-index: AcTFj5pjxpsfWJWFToWab2EifiO8wgACDUjA To: X-OriginalArrivalTime: 08 Nov 2004 14:10:12.0445 (UTC) FILETIME=[A99D60D0:01C4C59C] X-Spam-Score: 1.3 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Monday, November 08, 2004 7:36 AM ... > >>>2) Mitigate the N*M algorithm typically used at sync time. ... > >>Does the CHECKPOINT extension try to address # 2. If it does - how? > >> =20 > >> > > > >CHECKPOINT combined with CLEARIDLE addresses #2. An IDLE=20 > CHECKPOINT command is issued in the authenticated state. The=20 > responses defined in CLEARIDLE then include imap urls. This=20 > in effect does not require the N SELECTs to visit each folder. > > =20 > > > Which is #1. It doesn't affect N*M (actually M1+M2+...MN), because if=20 > there are changes to Mi messages in mailbox i, one has to=20 > fetch/process=20 > Mi responses anyway. This is why I use the word "mitigate". I agree with your point=20 that if there are N folders and each has Mn messages then the algorithm is still driven by N*Mn, but the cost of N is reduced with CHECKPOINT/CLEARIDLE. ... > >It allows responses with IMAPURLs to be shared. Correct me=20 > if I'm wrong but an IMAPURL basically allows one to export=20 > information from one session to another. Is this not what=20 > URLAUTH does when used with BURL. > > =20 > > > Yes, but the person who generates an URLAUTH *authorizes*=20 > somebody else=20 > to use it. The draft as written may give an impression that all users=20 > are notified about all messages arriving for all users.=20 The draft does state that the queueing is associated with an=20 authenticated session. I could be clearer. > Basically what=20 > you are proposing is even worse from security standpoint than the=20 > URLAUTH. An URLAUTH URL just gives information about message=20 > existence.=20 > CLEARIDLE FETCH replies might also contain messages subject and other=20 > sensitive information. I don't think so. The plain IMAPURL URLs are used because authenticated sessions are only allowed. So the protocol does not allow responses to be "leaked" from one session to another. It is the clients responsibility to share between sessions. The assumption is that=20 the client does the right thing. ... > (CLEARIDLE is needed to address # 3. I was comparing only=20 > CONDSTORE and=20 > CHECKPOINT) ... I tend to consider CHECKPOINT/CLEARIDLE as a combined solution. > >>Now, CHECKPOINT requires that all sessions receive exactly the same=20 > >>responses. CONDSTORE is a bit more smart on this. For=20 > example, let's=20 > >>imagine that the \Seen flag was set on the message 4 and then=20 > >>later on=20 > >>the \Deleted flag was also set. The CHECKPOINT will send: > >> > >> S: * 4 FETCH (FLAGS (\Recent \Seen)) (1006) > >> ... > >> S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted)) (1054) > >> > >>The CONDSTORE only requires a single response: > >> > >> S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted) MODSEQ (1054)) > >> =20 > >> > > > >Here is the difference. CHECKPOINT sends responses=20 > quasi-real-time, which means that one of it's goals is to=20 > maximize the response time at the client. It is greedy in the=20 > sense that information is sent as soon as it is available.=20 > When it is disconnected it may have the characteristic you=20 > mention, but it does not need to. An implementation could=20 > perform the response aggregation you mention. > > =20 > > > This is not clear from you document, if I understood the CHECKPOINT=20 > properly, the server is not allowed to skip responses. It can not skip response numbers. It is allowed to aggregate reponses if no information is lost.=20 I agree there are several areas I could be clearer. I'll produce a 01 rev and take into account many of your clarification comments. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 09:54:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15193 for ; Mon, 8 Nov 2004 09:54:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAv2-00036Z-AH for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 09:54:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRApX-0001AI-6C; Mon, 08 Nov 2004 09:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRASp-0004ds-AX for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 09:25:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11723 for ; Mon, 8 Nov 2004 09:25:45 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRATK-0002Bj-LH for lemonade@ietf.org; Mon, 08 Nov 2004 09:26:22 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8EPgW28880; Mon, 8 Nov 2004 16:25:42 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 16:24:59 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA8EOxSZ023336; Mon, 8 Nov 2004 16:24:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00lNcOym; Mon, 08 Nov 2004 16:24:56 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8ENma01943; Mon, 8 Nov 2004 16:23:48 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 08:23:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] RE: Comments/questions about MSGFILTER Date: Mon, 8 Nov 2004 08:23:42 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B76@daebe005.americas.nokia.com> Thread-Topic: [lemonade] RE: Comments/questions about MSGFILTER thread-index: AcTFkc5JdBRSY5H4Qvy2YpiyAq4YjQACvUkg To: X-OriginalArrivalTime: 08 Nov 2004 14:23:45.0293 (UTC) FILETIME=[8E1C23D0:01C4C59E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Monday, November 08, 2004 7:49 AM ... > >>I think the extension is lacking the ability to list=20 > >>available external filters. > >> =20 > >> > > > >Yes. It was intentional. Since the management of the=20 > filters, i.e. there definition,=20 > >was opaque to the protocol I thought it better to be=20 > consistent. I could see how > >it would be valuable to list them, though. Note that the=20 > logic of the criteria in the=20 > >TAG filters is completely opaque to IMAP. > > =20 > > > If you want any kind of interoperability between multiple=20 > clients, you=20 > either need a command to list named filters, or there should be an=20 I can see a use for this. > official registry of filter names. >=20 > You've already mentioned a filter tag "DEFAULT". I think the document=20 > should at least mention it. Agreed. ... > >> > An EXISTS response is sent as the first response in a=20 > >>Filter Set. It > >> > represents the total number of messages visible after the > >> > application of the latest FILTER SET. > >> > >>I suggest you define a new response instead. > >> =20 > >> > > > >Why? One of my goals was to try and minimize the=20 > additions/modifications=20 > >to the protocol. > > > I prefer not to overload existing responses. But it is not overloading. I'm attaching the same meaning. >=20 > Do you want the client to be notified about new message=20 > arrivals, even=20 > if the corresponding messages are filtered out? No. This is one difference between XFILTER and FILTER SET. > This also means that SEARCH would have to intersect the=20 > specified search=20 > criteria with the current filter? Yes. > One more question: > Does the filter go away when the selected mailbox is closed? The Filter Set always does. Non-TAG Filters also do. The Filter Set being the UIDs that result from the application=20 of the criteria. The Filter being the criteria them selves. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 09:56:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15347 for ; Mon, 8 Nov 2004 09:56:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAxB-00039S-GW for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 09:57:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRApi-0001OA-1g; Mon, 08 Nov 2004 09:49:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAV3-0005LQ-Vi for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 09:28:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12045 for ; Mon, 8 Nov 2004 09:28:04 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAVb-0002Ff-Bd for lemonade@ietf.org; Mon, 08 Nov 2004 09:28:40 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 14:27:31 +0000 Message-ID: <418F8252.6050205@isode.com> Date: Mon, 08 Nov 2004 14:27:30 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael.Wener@nokia.com Subject: Re: [lemonade] RE: Comments about CHECKPOINT (was Re: Mobile synchronization issues) References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB5D@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAB5D@daebe005.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.0 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Michael.Wener@nokia.com wrote: >>> <>It allows responses with IMAPURLs to be shared. Correct me if I'm >>> wrong but an IMAPURL basically allows one to export >>> information from one session to another. Is this not what >>> URLAUTH does when used with BURL. >> >>Yes, but the person who generates an URLAUTH *authorizes* >>somebody else >>to use it. The draft as written may give an impression that all users >>are notified about all messages arriving for all users. >> >> > >The draft does state that the queueing is associated with an >authenticated session. > > The term "authenticated session" is what causes the most confusion for me. What does it mean? >I could be clearer. > > >>Basically what >>you are proposing is even worse from security standpoint than the >>URLAUTH. An URLAUTH URL just gives information about message >>existence. >>CLEARIDLE FETCH replies might also contain messages subject and other >>sensitive information. >> >> > >I don't think so. The plain IMAPURL URLs are used because authenticated >sessions are only allowed. So the protocol does not allow responses >to be "leaked" from one session to another. It is the clients >responsibility to share between sessions. The assumption is that >the client does the right thing. > > See above. >... > > >>(CLEARIDLE is needed to address # 3. I was comparing only >>CONDSTORE and >>CHECKPOINT) >> >> >... > >I tend to consider CHECKPOINT/CLEARIDLE as a combined solution. > > I see a value of having them separate (e.g. I don't see why CONDSTORE can't be used with CLEARIDLE), however the boundary between the two must be more explicit. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 10:01:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15893 for ; Mon, 8 Nov 2004 10:01:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRB1g-0003HL-CT for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 10:01:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAqE-0001dc-SC; Mon, 08 Nov 2004 09:49:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAaj-0006Gj-1g for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 09:33:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12855 for ; Mon, 8 Nov 2004 09:33:55 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAbG-0002TD-H3 for lemonade@ietf.org; Mon, 08 Nov 2004 09:34:31 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8EXrE22156; Mon, 8 Nov 2004 16:33:53 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 16:32:08 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA8EW8fL031612; Mon, 8 Nov 2004 16:32:08 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Anm64Q; Mon, 08 Nov 2004 16:32:06 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8EW0S10954; Mon, 8 Nov 2004 16:32:00 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 08:31:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] RE: Comments about CLEARIDLE Date: Mon, 8 Nov 2004 08:31:44 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B77@daebe005.americas.nokia.com> Thread-Topic: [lemonade] RE: Comments about CLEARIDLE thread-index: AcTFmMrqTTUdgxTAT0CfzAvWeR5YHQABiFjw To: X-OriginalArrivalTime: 08 Nov 2004 14:31:46.0047 (UTC) FILETIME=[ACA960F0:01C4C59F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Monday, November 08, 2004 8:40 AM ... > Speaking as a server implementor: the choice of allowing=20 > notifications=20 > from multiple mailboxes has deep impact on server implementations. Why? ... > So, apart from the syntax, there is no difference between=20 > your \Renamed=20 > proposal and my REFERRAL proposal. Agreed Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 10:39:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21198 for ; Mon, 8 Nov 2004 10:39:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBcZ-0004RH-M7 for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 10:39:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBEd-0004xw-N7; Mon, 08 Nov 2004 10:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRB6G-0000SU-1p for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 10:06:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16397 for ; Mon, 8 Nov 2004 10:06:29 -0500 (EST) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRB6m-0003QF-L8 for lemonade@ietf.org; Mon, 08 Nov 2004 10:07:07 -0500 Received: from [192.168.1.13] (vpn-10-50-0-49.qualcomm.com [10.50.0.49]) by warlock.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id iA8F5esc026128; Mon, 8 Nov 2004 07:05:43 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <4173F175.6020309@isode.com> References: <416DB4DD.6050302@isode.com> <4173F175.6020309@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora for safety: Date: Mon, 8 Nov 2004 07:04:22 -0800 To: Alexey Melnikov , Pete Resnick From: Randall Gellens Subject: Re: [lemonade] Comments about CATENATE-02 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b27 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 At 5:38 PM +0100 10/18/04, Alexey Melnikov wrote: > Pete Resnick wrote: > >> On 10/14/04 at 12:06 AM +0100, Alexey Melnikov wrote: >> >>> >4. Response Codes >>> >>>> When a CATENATE command fails it may return a response code that >>>> describes a reason for the failure. >>> >>> I think this should be changed to: >>> >>> When a CATENATE command fails it SHOULD return a response code that >>> describes a reason for the failure. Two possible response >>> codes are described below, >>> however other response codes are also possible. >>> >>> i.e. we want to encourage detailed error reporting. >> >> You will note that I have avoided citing RFC 2119 up to this >> point. RFC 2119 imperatives are *not* to be used to "encourage" >> anything that does not affect interoperability. I'd really prefer >> to leave it as-is. > > More precise error reporting simplifies debugging and error > handling. It doesn't affect interoperability directly. More precise error reporting can affect (and can improve) interoperability if it gives advice to the client on how to respond to an error. Especially if the error is transitory or permanent and if the error can be corrected by the client and/or user. E.g., with TOOBIG, does the size exceed a policy limit or the amount of disk currently available? Is it the entire resulting message that is too big, or a chunk of it? > > When I see "SHOULD" in a document I usually think "this is pretty > important, I better implement it". Otherwise I am more likely to > ignore it. > I guess this is just me. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is always an easy solution to every human problem -- neat, plausible, and wrong. --H.L. Mencken _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 10:53:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23292 for ; Mon, 8 Nov 2004 10:53:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBqJ-0004wu-7O for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 10:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBdL-0005YH-NI; Mon, 08 Nov 2004 10:40:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBOg-0000NH-AD for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 10:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18913 for ; Mon, 8 Nov 2004 10:25:31 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBPD-0003xx-VG for lemonade@ietf.org; Mon, 08 Nov 2004 10:26:09 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 15:24:50 +0000 Message-ID: <418F8FC1.40603@isode.com> Date: Mon, 08 Nov 2004 15:24:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] Comments about CATENATE-02 References: <416DB4DD.6050302@isode.com> <4173F175.6020309@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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Randall Gellens wrote: >>> You will note that I have avoided citing RFC 2119 up to this point. >>> RFC 2119 imperatives are *not* to be used to "encourage" anything >>> that does not affect interoperability. I'd really prefer to leave it >>> as-is. >> >> More precise error reporting simplifies debugging and error >> handling. It doesn't affect interoperability directly. > > More precise error reporting can affect (and can improve) > interoperability if it gives advice to the client on how to respond to > an error. Yes. > Especially if the error is transitory or permanent and if the error > can be corrected by the client and/or user. E.g., with TOOBIG, does > the size exceed a policy limit or the amount of disk currently available? Ok, so may be we need multiple separate response codes. Maybe "TOOBIG" SP
> Is it the entire resulting message that is too big, or a chunk of it? Does it matter? >> When I see "SHOULD" in a document I usually think "this is pretty >> important, I better implement it". Otherwise I am more likely to >> ignore it. >> I guess this is just me. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 11:31:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27461 for ; Mon, 8 Nov 2004 11:31:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCQq-00065D-BX for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 11:31:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRC7h-0005TY-VJ; Mon, 08 Nov 2004 11:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBpN-0000f2-DI for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 10:53:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23261 for ; Mon, 8 Nov 2004 10:53:06 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBpv-0004vW-Dg for lemonade@ietf.org; Mon, 08 Nov 2004 10:53:44 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 15:52:33 +0000 Message-ID: <418F9640.3030305@isode.com> Date: Mon, 08 Nov 2004 15:52:32 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael.Wener@nokia.com Subject: Re: [lemonade] RE: Comments about CLEARIDLE References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B77@daebe005.americas.nokia.com> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B77@daebe005.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Michael.Wener@nokia.com wrote: >>Speaking as a server implementor: the choice of allowing >>notifications from multiple mailboxes has deep impact on server implementations. >> >> >Why? > > I think I need to correct myself: "the choice of allowing notifications has deep impact on server implementations." I.e. it might not trivial to add IDLE support to a server, as this requires addition of notification infrastructure (for example additional thread(s) to poll for changes; additional data structures to store and report notifications). Adding support for multimailbox notifications once the IDLE is implemented should be much simpler. BTW, how many servers implement IDLE? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 11:47:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29571 for ; Mon, 8 Nov 2004 11:47:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCgx-0006bs-TC for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 11:48:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCTS-0004Sy-1s; Mon, 08 Nov 2004 11:34:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCAu-00008C-Ba for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 11:15:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25737 for ; Mon, 8 Nov 2004 11:15:21 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCBS-0005cy-Tl for lemonade@ietf.org; Mon, 08 Nov 2004 11:16:00 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA8GE7ma004846 for ; Mon, 8 Nov 2004 11:14:11 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Nov 2004 11:11:14 -0500 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Mon, 8 Nov 2004 11:11:12 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Subject: [lemonade] UPDATED Agenda 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable MONDAY =3D=3D=3D=3D=3D=3D 1PM, Hemisphere Room Agenda Bash Chairs 10 min Status Update Chairs 5 min Work Group Items: MMS Mapping Randy Gellens 10 min Future Delivery Greg Vaudreuil 10 min URLAUTH Chris Newman 10 min BURL Chris Newman 5 min CATENATE Pete Resnick 5 min Quick Reconnect Corby Wilson 20 min Non-Work Group Items: Mobile Sync Michael Wener 10 min Message Filter Michael Wener 10 min ClearIdle Michael Wener 10 min WEDNESDAY =3D=3D=3D=3D=3D=3D=3D=3D=3D 3:30pm, Hemisphere Room Recap (not revisit) Monday Chairs 10 min Profile & Goals: Lemonade & Mobile E-Mail (Non-WG) St=E9phane Maes 20 min Goals Kue Wong 20 min Profile St=E9phane Maes 20 min Transcoding Discussion/CHANNEL 20 min Next Steps Chairs 15 min _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 12:44:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05991 for ; Mon, 8 Nov 2004 12:44:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRDa9-0008JG-Fb for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 12:45:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRDRu-0000Lm-MM; Mon, 08 Nov 2004 12:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRDFB-0005wg-8I for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 12:23:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03709 for ; Mon, 8 Nov 2004 12:23:50 -0500 (EST) Received: from inet-mail4.oracle.com ([148.87.2.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRDFl-0007iJ-5J for lemonade@ietf.org; Mon, 08 Nov 2004 12:24:29 -0500 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8HHGJr014245 for ; Mon, 8 Nov 2004 09:17:16 -0800 (PST) Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8HNGMe007756 for ; Mon, 8 Nov 2004 10:23:16 -0700 Received: from oracle-8qdrvd34 (dhcp-emea-vpn-gw2-uk-141-144-129-69.vpn.oracle.com [141.144.129.69]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8HNAaq007399 for ; Mon, 8 Nov 2004 10:23:15 -0700 Message-Id: <200411081723.iA8HNAaq007399@rgmgw3.us.oracle.com> From: "Stephane H. Maes" To: lemonade@ietf.org Subject: RE: [lemonade] RE: Comments about CLEARIDLE Date: Mon, 8 Nov 2004 09:22:23 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 50822 (10.0.4712) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable > = BTW, how many servers implement IDLE? < Good question. It would help to know as well as if the implement IDLE, how = many concurrent client session are they typically able to support? Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-6= 07-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Alexey Melnikov Sent: Monday, November 08, 2004 7:53 AM To: Michael.Wener@nokia.com Cc: lemonade@ietf.org Subject: Re: [lemonade] RE: Comments about CLEARIDLE Michael.Wener@nokia.com wrote: >>Speaking as a server implementor: the choice of allowing >>notifications from multiple mailboxes has deep impact on server implement= ations. >> = >> >Why? > = > I think I need to correct myself: "the choice of allowing notifications = has deep impact on server implementations." I.e. it might not trivial to = add IDLE support to a server, as this requires addition of notification = infrastructure (for example additional thread(s) to poll for changes; = additional data structures to store and report notifications). Adding = support for multimailbox notifications once the IDLE is implemented = should be much simpler. BTW, how many servers implement IDLE? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 14:44:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19663 for ; Mon, 8 Nov 2004 14:44:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFSH-0003HP-3u for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 14:45:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRF38-0007tV-3L; Mon, 08 Nov 2004 14:19:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREzz-00061N-55 for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 14:16:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16348 for ; Mon, 8 Nov 2004 14:16:17 -0500 (EST) Received: from agminet02.oracle.com ([141.146.126.229]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRF0Y-0002M1-No for lemonade@ietf.org; Mon, 08 Nov 2004 14:16:56 -0500 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8JAjfC001927; Mon, 8 Nov 2004 11:10:45 -0800 Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8JAiOw014871; Mon, 8 Nov 2004 12:10:44 -0700 Received: from oracle-8qdrvd34 (dhcp-emea-vpn-gw2-uk-141-144-129-120.vpn.oracle.com [141.144.129.120]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8JAX6A014218; Mon, 8 Nov 2004 12:10:43 -0700 Message-Id: <200411081910.iA8JAX6A014218@rgmgw3.us.oracle.com> From: "Stephane H. Maes" To: Eric Burger , lemonade@ietf.org Subject: RE: [lemonade] UPDATED Agenda Date: Mon, 8 Nov 2004 11:09:40 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 50822 (10.0.4712) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable One more comments. On Wedn, we should do S2C notification reqs... (before p= rofile) Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-6= 07-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Eric Burger Sent: Monday, November 08, 2004 8:11 AM To: lemonade@ietf.org Subject: [lemonade] UPDATED Agenda Importance: High MONDAY =3D=3D=3D=3D=3D=3D 1PM, Hemisphere Room Agenda Bash Chairs 10 min Status Update Chairs 5 min Work Group Items: MMS Mapping Randy Gellens 10 min Future Delivery Greg Vaudreuil 10 min URLAUTH Chris Newman 10 min BURL Chris Newman 5 min CATENATE Pete Resnick 5 min Quick Reconnect Corby Wilson 20 min Non-Work Group Items: Mobile Sync Michael Wener 10 min Message Filter Michael Wener 10 min ClearIdle Michael Wener 10 min WEDNESDAY =3D=3D=3D=3D=3D=3D=3D=3D=3D 3:30pm, Hemisphere Room Recap (not revisit) Monday Chairs 10 min Profile & Goals: Lemonade & Mobile E-Mail (Non-WG) St=E9phane Maes 20 min Goals Kue Wong 20 min Profile St=E9phane Maes 20 min Transcoding Discussion/CHANNEL 20 min Next Steps Chairs 15 min _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 15:12:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24408 for ; Mon, 8 Nov 2004 15:12:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFsp-0004Dk-PQ for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 15:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFkK-0004xL-HB; Mon, 08 Nov 2004 15:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFPK-0004j4-K5 for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 14:42:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19399 for ; Mon, 8 Nov 2004 14:42:28 -0500 (EST) Received: from agminet04.oracle.com ([141.146.126.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFPv-0003BH-Pm for lemonade@ietf.org; Mon, 08 Nov 2004 14:43:08 -0500 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8JfufI021276; Mon, 8 Nov 2004 11:41:57 -0800 Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8JfuQT018915; Mon, 8 Nov 2004 12:41:56 -0700 Received: from oracle-8qdrvd34 (dhcp-emea-vpn-gw2-uk-141-144-129-120.vpn.oracle.com [141.144.129.120]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iA8Jfid7018511; Mon, 8 Nov 2004 12:41:54 -0700 Message-Id: <200411081941.iA8Jfid7018511@rgmgw2.us.oracle.com> From: "Stephane H. Maes" To: Eric Burger , lemonade@ietf.org Subject: RE: [lemonade] UPDATED Agenda Date: Mon, 8 Nov 2004 11:41:02 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 50822 (10.0.4712) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Please add also an update on p-imap 05 on Wednesday. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-6= 07-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Eric Burger Sent: Monday, November 08, 2004 8:11 AM To: lemonade@ietf.org Subject: [lemonade] UPDATED Agenda Importance: High MONDAY =3D=3D=3D=3D=3D=3D 1PM, Hemisphere Room Agenda Bash Chairs 10 min Status Update Chairs 5 min Work Group Items: MMS Mapping Randy Gellens 10 min Future Delivery Greg Vaudreuil 10 min URLAUTH Chris Newman 10 min BURL Chris Newman 5 min CATENATE Pete Resnick 5 min Quick Reconnect Corby Wilson 20 min Non-Work Group Items: Mobile Sync Michael Wener 10 min Message Filter Michael Wener 10 min ClearIdle Michael Wener 10 min WEDNESDAY =3D=3D=3D=3D=3D=3D=3D=3D=3D 3:30pm, Hemisphere Room Recap (not revisit) Monday Chairs 10 min Profile & Goals: Lemonade & Mobile E-Mail (Non-WG) St=E9phane Maes 20 min Goals Kue Wong 20 min Profile St=E9phane Maes 20 min Transcoding Discussion/CHANNEL 20 min Next Steps Chairs 15 min _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 18:00:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14194 for ; Mon, 8 Nov 2004 18:00:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRIVM-0000dI-B0 for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 18:00:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRIMM-00082e-WA; Mon, 08 Nov 2004 17:51:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRI6a-00043t-8e for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 17:35:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11132 for ; Mon, 8 Nov 2004 17:35:17 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRI7D-0008Kx-5P for lemonade@ietf.org; Mon, 08 Nov 2004 17:35:59 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iA8MYlus027846 for ; Mon, 8 Nov 2004 16:34:47 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <4M3F5RG5>; Mon, 8 Nov 2004 16:34:47 -0600 Message-ID: <54E40201497DF142B06B27255953F797050E523F@il0015exch007u.ih.lucent.com> From: "White, Gregory (Gregory)** CTR **" To: "'lemonade@ietf.org'" Subject: RE: [lemonade] Lemonade Agenda Date: Mon, 8 Nov 2004 16:34:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Yes, I believe we definitely need another revision to address all the issues.... Greg W. -----Original Message----- From: Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] Sent: Sunday, November 07, 2004 9:52 AM To: Eric Burger Cc: lemonade@ietf.org Subject: Re: [lemonade] Lemonade Agenda Eric Burger wrote: >Monday 1pm, Hemisphere Room >--------------------------- >Agenda Bashing >Status Update >Future Delivery (draft-ietf-lemonade-futuredelivery-00.txt) > > My understanding that the document will need to have another revision to address the issues raised during Last Call. Am I correct? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 20:09:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26743 for ; Mon, 8 Nov 2004 20:09:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKWG-0003rn-7M for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 20:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKMM-0003P6-An; Mon, 08 Nov 2004 19:59:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKD5-0000St-VD for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 19:50:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24926 for ; Mon, 8 Nov 2004 19:50:08 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKDj-0003Ht-C4 for lemonade@ietf.org; Mon, 08 Nov 2004 19:50:52 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA90o9W25427; Tue, 9 Nov 2004 02:50:09 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 02:48:54 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA90msAZ028739; Tue, 9 Nov 2004 02:48:54 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00i6nGIO; Tue, 09 Nov 2004 02:48:52 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA90mpS21212; Tue, 9 Nov 2004 02:48:51 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 18:48:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] RE: Comments about CHECKPOINT (was Re: Mobile synchronization issues) Date: Mon, 8 Nov 2004 18:48:24 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B7B@daebe005.americas.nokia.com> Thread-Topic: [lemonade] RE: Comments about CHECKPOINT (was Re: Mobile synchronization issues) thread-index: AcTF52RXWOmPnqKVTMOv7FcqkiowegADaH+A To: X-OriginalArrivalTime: 09 Nov 2004 00:48:24.0926 (UTC) FILETIME=[D1B647E0:01C4C5F5] X-Spam-Score: 1.3 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Monday, November 08, 2004 9:28 AM ... > > > >The draft does state that the queueing is associated with an=20 > >authenticated session. > > =20 > > > The term "authenticated session" is what causes the most=20 > confusion for=20 > me. What does it mean? It is a poor way of saying the queue is associated with an=20 authenticated user. I'll clarify. .. > >I tend to consider CHECKPOINT/CLEARIDLE as a combined solution. > > =20 > > > I see a value of having them separate (e.g. I don't see why CONDSTORE=20 > can't be used with CLEARIDLE), however the boundary between=20 > the two must=20 > be more explicit. I also saw value in having them separate. I would restate to say the relationship needs to be clarified.=20 Both their distinctions, and how they compliment each other. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 8 23:33:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24779 for ; Mon, 8 Nov 2004 23:33:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRNhd-00084J-5r for lemonade-web-archive@ietf.org; Mon, 08 Nov 2004 23:33:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRNds-0008Cv-CY; Mon, 08 Nov 2004 23:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRNZ5-0007e0-FB for lemonade@megatron.ietf.org; Mon, 08 Nov 2004 23:25:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24151 for ; Mon, 8 Nov 2004 23:25:04 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRNZk-0007ti-Oc for lemonade@ietf.org; Mon, 08 Nov 2004 23:25:49 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA94LvbF002140 for ; Mon, 8 Nov 2004 23:21:58 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Nov 2004 23:19:03 -0500 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Mon, 8 Nov 2004 23:19:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Subject: [lemonade] Draft Meeting Minutes for Monday 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Given the folks coming on Wednesday that missed Monday, here is a more raw form of the minutes. Thanks to Tony for running the Jabber log and cleaning them up for the minutes. Slides are at http://flyingfox.snowshore.com/i-d/lemonade/slides61/index.html Agenda Bashing (Chairs) 5 min [12:04:57] agenda was modified to accommodate those who could be here on Monday, not on wed, and vice versa [12:06:09] today: mms mapping, future deliv, urlauth, burl, catenate, quick reconect; nonWG: mobile sync, clearidle, message filter [12:06:28] bash: please move quick reconnect to wed [12:07:00] wed agenda: Mon recap, profile & goals, quick reconnect, transcoding discussion (channel) [12:07:14] sold Charter & Liaisons (Chairs) 5 min [12:07:18] status update: [12:08:27] charter review: goals, imap ext for vm playback, submit extensions for forwarding, exts for diverse endpoints, server to server notif. protocol (not server to client), translation to/from other messaging systems [12:08:38] summary of deliverables [12:10:20] recap of interim meeting in Vancouver [12:11:54] objectives: various drafts have moved forward, and some gone to LC, hopefully rest to WGLC before next ietf [12:13:04] WGLC status: server to server notif reqts: closed; mms mapping: issues to be resolved; future delivery: discussed today; goals: discussed on Wed MMS Mapping (Randy) 10 min [12:13:33] randy gellens: mms/email mapping [12:14:15] 01 includes explicit vpim support vs. 00 [12:15:22] open issue: specifies the use of precedence: Bulk header; do we need it? Do we keep it? Standardize it? [12:19:16] discussion pro & con, mild support both ways [12:24:57] resolution of 'precedence: bulk' was to leave it since it is in the registry [12:21:18] open issue #2: sender address hiding using x-anonymous extension to MAIL FROM [12:22:53] support for standardizing the anon facility separately [12:23:58] resolution: remove it, for possible future standardization Future Delivery (Greg) [12:24:37] Greg Vaudreuil: future delivery [12:24:57] issues: 1*9digit; resolution leave it [12:25:51] issue #2: auth reqt is redundant [12:27:56] resolution: leave it to smtp-submit to move forward and remove from this doc, change smtp-submit reference to new doc (currently in queues) [12:28:12] issue #3: fix reference to rfc 2119 language [12:28:32] issue #4: is there a minimum futuredeliver time? does the server need to announce it? [12:29:26] no, doesn't add any real value [12:30:16] issue #6: add DOS wording to security reqts. Chris Newman is volunteering to review it closely [12:30:35] issue #5: odd cases in max delivery interval; 0, 9999999999 [12:31:12] resolution: require the advertisement [12:31:28] various nits [12:31:23] Randy: why require advertisement? Answer: consistency [12:34:40] new drafts for mms and future delivery will come out soon (next week) Pull Documents URLAUTH (Chris) 5 min [12:34:59] chris newman: urlauth, burl, catenate [12:36:30] is urlauth ready for wglc? no, there were some comments on the list that haven't yet been resolved [12:37:03] plus the "anonymous" issue Pull Documents BURL (Chris) 10 min [12:37:34] burl: issue: need a rev for reference updates [12:37:45] then last call [12:38:29] Glenn to Ted: any issues on urlauth? there has been a draft since his comments were sent [12:38:48] Glenn will ping mark Pull Documents CATENATE (Pete) 5 min [12:38:54] pete resnick: catenate [12:39:17] needs examples, plus something on what to do with response codes [12:40:39] 2119 language? pete says 2119 language isn't necessarily needed [12:41:40] randy & chris: need it for interop [12:42:56] alexi melnikov: I agree with Randy & Chris [12:45:26] discussion on i18n problems with text [12:45:31] chris -- fine as is [12:46:12] on to examples: how to deal w/ drafts? other use cases [12:46:59] clarification to pete on what examples go in catenate vs. profile doc [12:49:49] greg: why do we have catenate at all? don't urlauth and burl cover it? [12:51:10] chris: catenate allows you to put copy into sent folder and send it [12:51:42] pete: different algorithms if you have annotations, and don't [12:52:16] amelnikov: Catenate also allows to strip attachments and edit a draft multiple times [12:52:18] chris: forward without download as well as saving file copy [12:52:49] greg: two ways to do same thing? bothers him. catenate using burl, vs. bdat, bdat, burl [12:53:16] chris/pete: lemonade will require catenate, but not bdat [12:53:33] greg: figured bdat WOULD be required [12:55:02] chris/randy: yes, there will be more than one way to do the same thing [12:55:48] philip g.: another complexity is alexey's draft to request email address for a particular folder [12:56:14] michael wener: <> [12:56:50] pete: wordsmithed document in real time [12:58:29] greg: what's preferred way to do fcc? catenate with burl? [12:58:33] chris: yes [12:59:30] greg: if do future delivery submission, is burl resolved now or then? [13:03:16] chris: the URL was resolved before the submit server sends an error response. [13:01:27] pete: will go back to editing for next draft [13:02:05] pete: call for examples to provide for the doc [13:03:04] amelnikov: I can write some examples for Pete [13:03:23] send them to pete [13:04:24] pete: profile will say: here's how to use catenate to forward w/o download. and that use of annotation would make forward w/o download more efficient, but it is not required by the profile, and may describe how to do so. [13:04:51] sub use case of editing drafts can be made more efficient with annotations Non-Working Group Items: checkpoint / clearidle (Michael) [13:05:22] next: non-work group items [13:05:57] michael wener: checkpoint/clearidle [13:06:52] goal: provide quasi-real-time reception of server state change; minimize client costs of full sync; minimize protocol changes; obviates RECONNECT, and server-to-client-notifications [13:07:53] current drafts don't provide clear description on how to use two together -- need both, and how play together could part of lemonade profile [13:08:43] checkpoint: ack'd delivery of imap responses, extends idle, subsumes reconnect [13:09:23] resync avoidance: avoid missed events; uses account based queuing [13:10:11] defines a 2-session access scenario for imap client; sessions are mutually aware [13:10:46] uses imapurl to export uid state between sessions [13:11:46] checkpoint: supports both highly connected & lightly connected [13:12:23] idle context is a way of scoping both: queue life (queue is self cleaning) & responses w/ new syntax [13:13:39] pete: questions where costs of connection are? mike: both tcp level and tls level [13:15:27] randy: questions highly vs. lightly connectedness. mike: means how often have active connection [13:17:38] clearidle: provide unsolicited responses during IDLE (when in auth state) -- uses IMAPURL used to identify folders & uids -- allows multiple folders to be reviewed covers all state change need to avoid a full sync at reconnect -- all folders, folder state, mail state, expunges [13:18:41] the two combined improves mobile mail experience: checkpoing/clearidle: user perceived smoothing of mail reception; msgfilter: focusing on what mail is of interest to user [13:19:47] cyrus: can you limit updates to "folders of interest"? [13:20:45] mike: it's a problem with no magic wand, can use aggregation -- needs some work [13:22:01] discussion genericizing to general server-to-client notification [13:22:19] comments about xmpp doing it, reference to jep #60 [13:23:52] clamor [13:25:41] eric: discussion of inband vs. out-of-band models; sip vs. xmpp; imap was not built to do it; we should use the right kind of connection to do notification and not mix it in to imap [13:26:34] dave crocker: notification has 2 pieces -- object and transfer -- we need to specify the object to be sent and now how it's sent [13:27:10] glen: we want reqts of what needs to be transferred from server to client [13:27:27] mike: clearidle specifies content [13:28:42] greg: still interested specifically in imapish events since last connect or checkpoint Non-Working Group Items: msgfilter (Michael) [13:29:34] on to msgfilter [13:29:58] goal is to constrain what events are seen [13:30:15] or, what messages are seen [13:30:44] use case #1: mail after a certain date; #2 only mail from *@customer.com [13:31:43] some syntax borrowed from old window/view drafts [13:32:13] command: FILTER SET; response: FILTER SET; response code: FILTERED [13:33:57] transient mode: specify criteria via SEARCH, UID ADD/REMOVE; easy cleanup: self cleaning; filters are definitive [13:34:42] non-transient mode: protocol opaque tag [13:36:04] filters build dynamically (incrementally); rules have precedence TAG, SEARCH, UID ADD/REMOVE [13:37:18] cyrus: window had scalability problems [13:37:35] mike: same scalability problems as search command [13:39:11] cyrus: serious problems with redefining sequence numbers on the fly [13:40:36] mike: burden of maintaining state borne by server, but mitigated by trancience [13:43:54] corby: what happens with collected state changes with msgfilter vis-a-vis checkpoint [13:44:01] mike: a problem Next Steps & Milestones 10 min [13:44:13] eric: what's next [13:44:46] updated drafts by December 1 (profile, reconnect); wglc for pull trio [13:45:13] we're done for the day -- to be continued on Wednesday _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 9 00:34:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00382 for ; Tue, 9 Nov 2004 00:34:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CROeX-00016G-1K for lemonade-web-archive@ietf.org; Tue, 09 Nov 2004 00:34:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRObi-00036I-89; Tue, 09 Nov 2004 00:31:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CROPt-0001U0-TE for lemonade@megatron.ietf.org; Tue, 09 Nov 2004 00:19:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29501 for ; Tue, 9 Nov 2004 00:19:37 -0500 (EST) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CROQV-0000q9-6I for lemonade@ietf.org; Tue, 09 Nov 2004 00:20:23 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iA95EYpS006127; Mon, 8 Nov 2004 21:14:34 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iA95EYlj001750; Mon, 8 Nov 2004 21:14:34 -0800 Date: Mon, 8 Nov 2004 21:14:34 -0800 (PST) From: Mark Crispin To: Eric Burger Subject: Re: [lemonade] Draft Meeting Minutes for Monday In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Mon, 8 Nov 2004, Eric Burger wrote: > [12:36:30] is urlauth ready for wglc? no, there were some comments on > the list that haven't yet been resolved > [12:37:03] plus the "anonymous" issue Could someone elaborate on this? I thought that I had dealt with all pending issues from the WG; AFAIK the only remaining question was whether it would be alright for me to include anonymous and authuser again. If there is something else that needs my attention prior to WGLC, I'd appreciate a reminder as to what it is, since I apparently have totally forgotten about it. Thanks. -- 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 From lemonade-bounces@ietf.org Tue Nov 9 09:56:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04470 for ; Tue, 9 Nov 2004 09:56:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXRL-0005eQ-CA for lemonade-web-archive@ietf.org; Tue, 09 Nov 2004 09:57:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXKc-0003O1-Qb; Tue, 09 Nov 2004 09:50:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXBi-0001CJ-RX for lemonade@megatron.ietf.org; Tue, 09 Nov 2004 09:41:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02753 for ; Tue, 9 Nov 2004 09:41:36 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXCR-0005GZ-5s for lemonade@ietf.org; Tue, 09 Nov 2004 09:42:26 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA9Eexu24385; Tue, 9 Nov 2004 09:40:59 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Nov 2004 09:40:59 -0500 Message-ID: <538A9E90-325D-11D9-9764-00306577589E@americasm01.nt.com> From: "Glenn Parsons" To: Mark Crispin Subject: Re: [lemonade] Draft Meeting Minutes for Monday Date: Tue, 9 Nov 2004 09:40:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 1.9 (+) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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: , Content-Type: multipart/mixed; boundary="===============0974120535==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0974120535== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C66A.18820561" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C66A.18820561 Content-Type: text/plain; charset="iso-8859-1" Mark, The issue was whether there was anything else besides anonymous. You have confirmed that there are none. We did not discuss anonymous. However, my opinion would be to leave it out and add this functionality as a simple extension. If we leave it out, do you need to upissue the draft? I would like to WGLC the forward w/o download trio in the next week or so. Cheers, Glenn. On Nov 9, 2004, at 12:14 AM, Mark Crispin wrote: > On Mon, 8 Nov 2004, Eric Burger wrote: >> [12:36:30] is urlauth ready for wglc? no, there were some comments >> on >> the list that haven't yet been resolved >> [12:37:03] plus the "anonymous" issue > > Could someone elaborate on this? I thought that I had dealt with all > pending issues from the WG; AFAIK the only remaining question was > whether it would be alright for me to include anonymous and authuser > again. > > If there is something else that needs my attention prior to WGLC, I'd > appreciate a reminder as to what it is, since I apparently have > totally forgotten about it. Thanks. > > -- 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 > ------_=_NextPart_001_01C4C66A.18820561 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [lemonade] Draft Meeting Minutes for Monday

Mark,

The issue was whether there was anything else besides = anonymous.  You
have confirmed that there are none.

We did not discuss anonymous.

However, my opinion would be to leave it out and add = this functionality
as a simple extension.

If we leave it out, do you need to upissue the = draft?

I would like to WGLC the forward w/o download trio in = the next week or
so.

Cheers,
Glenn.

On Nov 9, 2004, at 12:14 AM, Mark Crispin = wrote:

> On Mon, 8 Nov 2004, Eric Burger wrote:
>> [12:36:30]    is urlauth ready = for wglc? no, there were some comments
>> on
>> the list that haven't yet been = resolved
>> [12:37:03]    plus the = "anonymous" issue
>
> Could someone elaborate on this?  I = thought that I had dealt with all
> pending issues from the WG; AFAIK the only = remaining question was
> whether it would be alright for me to include = anonymous and authuser
> again.
>
> If there is something else that needs my = attention prior to WGLC, I'd
> appreciate a reminder as to what it is, since I = apparently have
> totally forgotten about it.  = Thanks.
>
> -- 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
>

------_=_NextPart_001_01C4C66A.18820561-- --===============0974120535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0974120535==-- From lemonade-bounces@ietf.org Tue Nov 9 10:23:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08518 for ; Tue, 9 Nov 2004 10:23:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXqo-0006Jj-00 for lemonade-web-archive@ietf.org; Tue, 09 Nov 2004 10:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXiB-0004s5-HC; Tue, 09 Nov 2004 10:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXak-0001Xf-Bo for lemonade@megatron.ietf.org; Tue, 09 Nov 2004 10:07:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05930 for ; Tue, 9 Nov 2004 10:07:28 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXbV-0005uv-K1 for lemonade@ietf.org; Tue, 09 Nov 2004 10:08:18 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 9 Nov 2004 15:06:38 +0000 Message-ID: <4190DCFC.4050407@isode.com> Date: Tue, 09 Nov 2004 15:06:36 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Glenn Parsons Subject: Re: [lemonade] Draft Meeting Minutes for Monday References: <538A9E90-325D-11D9-9764-00306577589E@americasm01.nt.com> In-Reply-To: <538A9E90-325D-11D9-9764-00306577589E@americasm01.nt.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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Glenn Parsons wrote: > Mark, > > The issue was whether there was anything else besides anonymous. You > have confirmed that there are none. > > We did not discuss anonymous. > > However, my opinion would be to leave it out and add this functionality > as a simple extension. > I think we already have a problem with too many IMAP extensions and extensions to extensions to extensions. I think the URLAUTH document should just define "anonymous" and "authuser". All policy statement (like "MUST NOT use "anonymous" in BURL URLs) applicable to Lemonade can be stated in the Lemonade profile document. > If we leave it out, do you need to upissue the draft? > > I would like to WGLC the forward w/o download trio in the next week or > so. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 9 10:50:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12198 for ; Tue, 9 Nov 2004 10:50:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRYHU-000755-OB for lemonade-web-archive@ietf.org; Tue, 09 Nov 2004 10:51:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYDG-0005tw-NY; Tue, 09 Nov 2004 10:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRY2G-0003Eo-Uc for lemonade@megatron.ietf.org; Tue, 09 Nov 2004 10:35:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10160 for ; Tue, 9 Nov 2004 10:35:54 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRY31-0006ec-6E for lemonade@ietf.org; Tue, 09 Nov 2004 10:36:44 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iA9FSTbj013241; Tue, 9 Nov 2004 10:28:32 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Nov 2004 10:25:35 -0500 Message-ID: From: Eric Burger To: Mark Crispin Subject: RE: [lemonade] Draft Meeting Minutes for Monday Date: Tue, 9 Nov 2004 10:25:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa That was exactly it (does anonymous and authuser come back). Feeling (not strong enough to call consensus) was let the sleeping dog lie. What are your thoughts? > -----Original Message----- > From: Mark Crispin [mailto:mrc@CAC.Washington.EDU] > Sent: Tuesday, November 09, 2004 12:15 AM > To: Eric Burger > Cc: lemonade@ietf.org > Subject: Re: [lemonade] Draft Meeting Minutes for Monday > > > On Mon, 8 Nov 2004, Eric Burger wrote: > > [12:36:30] is urlauth ready for wglc? no, there were some > comments on > > the list that haven't yet been resolved > > [12:37:03] plus the "anonymous" issue > > Could someone elaborate on this? I thought that I had dealt with all > pending issues from the WG; AFAIK the only remaining question > was whether > it would be alright for me to include anonymous and authuser again. > > If there is something else that needs my attention prior to WGLC, I'd > appreciate a reminder as to what it is, since I apparently > have totally > forgotten about it. Thanks. > > -- 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 > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 9 11:42:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17940 for ; Tue, 9 Nov 2004 11:42:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZ5l-000093-IC for lemonade-web-archive@ietf.org; Tue, 09 Nov 2004 11:43:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYxr-0001bg-7V; Tue, 09 Nov 2004 11:35:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYmu-0008Ku-1G for lemonade@megatron.ietf.org; Tue, 09 Nov 2004 11:24:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15864 for ; Tue, 9 Nov 2004 11:24:03 -0500 (EST) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRYne-00082a-7A for lemonade@ietf.org; Tue, 09 Nov 2004 11:24:54 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iA9GO3xw027115; Tue, 9 Nov 2004 08:24:03 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iA9GO3cN016170; Tue, 9 Nov 2004 08:24:03 -0800 Date: Tue, 9 Nov 2004 08:24:03 -0800 (PST) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Draft Meeting Minutes for Monday In-Reply-To: <4190DCFC.4050407@isode.com> Message-ID: References: <538A9E90-325D-11D9-9764-00306577589E@americasm01.nt.com> <4190DCFC.4050407@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: lemonade@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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Tue, 9 Nov 2004, Alexey Melnikov wrote: > I think the URLAUTH document should just define "anonymous" and "authuser". > All policy statement (like "MUST NOT use "anonymous" in BURL URLs) applicable > to Lemonade can be stated in the Lemonade profile document. This is my position as well. -- 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 From lemonade-bounces@ietf.org Wed Nov 10 03:02:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04889 for ; Wed, 10 Nov 2004 03:02:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRnRW-00037D-1e for lemonade-web-archive@ietf.org; Wed, 10 Nov 2004 03:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRnPa-0001Kx-53; Wed, 10 Nov 2004 03:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRnOc-0001E7-HR for lemonade@megatron.ietf.org; Wed, 10 Nov 2004 03:00:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04795 for ; Wed, 10 Nov 2004 03:00:00 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRnPX-00034j-3O for lemonade@ietf.org; Wed, 10 Nov 2004 03:00:59 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAA7xqIY043579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Nov 2004 00:59:55 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Tue, 09 Nov 2004 23:59:51 -0800 From: Lyndon Nerenberg To: lemonade@ietf.org Message-ID: X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-SdV-Metrics: orthanc.ca 1179; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL, UPPERCASE_25_50 autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.4 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Subject: [lemonade] Channel updates for content conversion 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Folks, sorry for being so late with this. I've been dealing with electrical problems on the boat, which took priority. I wasn't able to do the update to the draft, but here is a description of how I'm planning to add support for content conversion. A new CHANNELCONVERSIONS command is added. It takes the form tag CHANNELCONVERSIONS nstring This command returns a list of supported conversion target mime types. If the nstring is NIL the full list of conversion targets is returned. If the string is non-nil it contains space separated list of top-level MIME types to restrict the response list to. The CHANNELCONVERSIONS response takes the form * CHANNELCONVERSIONS astring where the astring contains the MIME type. There is one untagged response for each matching type. E.g. 1 CHANNELCONVERSIONS NIL * CHANNELCONVERSIONS "image/gif" * CHANNELCONVERSIONS "image/jpeg" * CHANNELCONVERSIONS "audio/gsm" * CHANNELCONVERSIONS "audio/g723" * CHANNELCONVERSIONS "audio/basic" * CHANNELCONVERSIONS "application/pdf" * CHANNELCONVERSIONS "application/postscript" * CHANNELCONVERSIONS "application/x-gzip" 1 OK CHANNELCONVERSIONS completed 2 CHANNELCONVERSIONS "audio" * CHANNELCONVERSIONS "audio/gsm" * CHANNELCONVERSIONS "audio/g723" * CHANNELCONVERSIONS "audio/basic" 2 OK CHANNELCONVERSIONS completed 3 CHANNELCONVERSIONS "image audio foo" * CHANNELCONVERSIONS "audio/gsm" * CHANNELCONVERSIONS "audio/g723" * CHANNELCONVERSIONS "audio/basic" * CHANNELCONVERSIONS "image/gif" * CHANNELCONVERSIONS "image/jpeg" 3 OK CHANNELCONVERSIONS completed 4 CHANNELCONVERSIONS "foo" 4 OK CHANNELCONVERSIONS completed The CHANNEL command is extended by adding a new parameter that specifies a conversion: tag CHANNEL channel-uri-list SP channel-set SP conversion-spec conversion-spec is an nstring that specifies a single MIME type to convert the content to. If NIL, no conversion is performed. If the conversion cannot be performed, a NIL response is returned for that item (the same behaviour as if the requested scheme failed). 5 CHANNEL (rtsp) (1 2) audio/mpeg * 1 CHANNEL 2 NIL 5 OK done but nothing was sent because audio/mpeg is not a valid target I'm still working out issues with IMAPURL. Also, the syntax here gives the general sense, but the details will change when the grammar gets an overhaul. I'm also working on the syntax and semantics for how to specify the data is to be returned in-band. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 10 04:28:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14104 for ; Wed, 10 Nov 2004 04:28:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRonE-00055z-OU for lemonade-web-archive@ietf.org; Wed, 10 Nov 2004 04:29:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRokk-0003PF-St; Wed, 10 Nov 2004 04:26:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRokH-0003KA-VT for lemonade@megatron.ietf.org; Wed, 10 Nov 2004 04:26:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13858 for ; Wed, 10 Nov 2004 04:26:27 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRolC-00053I-H3 for lemonade@ietf.org; Wed, 10 Nov 2004 04:27:27 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAA9QLNU043971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2004 02:26:24 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 10 Nov 2004 01:26:21 -0800 From: Lyndon Nerenberg To: "Stephane H. Maes" , lemonade@ietf.org Subject: RE: [lemonade] RE: Comments about CLEARIDLE Message-ID: In-Reply-To: <200411081723.iA8HNAaq007399@rgmgw3.us.oracle.com> References: <200411081723.iA8HNAaq007399@rgmgw3.us.oracle.com> X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-SdV-Metrics: orthanc.ca 1179; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit --On 2004-11-8 9:22 AM -0800 "Stephane H. Maes" wrote: > Good question. It would help to know as well as if the implement > IDLE, how many concurrent client session are they typically able to > support? I'm a bit fuzzy about what you're asking for here. Are you looking for a comparison of how many connections I can handle in SELECTed state vs. how many I can handle in IDLE state? (For my server, there's no difference.) --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 10 14:52:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19152 for ; Wed, 10 Nov 2004 14:52:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRyWf-0003O5-J7 for lemonade-web-archive@ietf.org; Wed, 10 Nov 2004 14:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRyPs-0000GJ-6L; Wed, 10 Nov 2004 14:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRyLg-0008DO-Sm for lemonade@megatron.ietf.org; Wed, 10 Nov 2004 14:41:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18165 for ; Wed, 10 Nov 2004 14:41:43 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRyMh-00037B-UQ for lemonade@ietf.org; Wed, 10 Nov 2004 14:42:48 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iAAJRR1P028336; Wed, 10 Nov 2004 14:27:31 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 14:24:33 -0500 Message-ID: From: Eric Burger To: Lyndon Nerenberg Subject: RE: [lemonade] Channel updates for content conversion Date: Wed, 10 Nov 2004 14:24:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 This assumes the IMAP server does the conversions. I'll yield judgment of the wisdom of that to the IMAP server folks. This does not really help for the real-time media types. For example, there are many parameters of G.726, H.263, etc. that are not _normally_ (but I suppose can be) conveyed as MIME parameters. Where does the content go? Is the result of CHANNEL a URLAUTH? Should the functionality be part of URLAUTH and not CHANNEL? Thoughts from the Peanut Gallery? > -----Original Message----- > From: Lyndon Nerenberg [mailto:lyndon@orthanc.ca] > Sent: Wednesday, November 10, 2004 3:00 AM > To: lemonade@ietf.org > Subject: [lemonade] Channel updates for content conversion > > > Folks, sorry for being so late with this. I've been dealing with > electrical problems on the boat, which took priority. I wasn't able > to do the update to the draft, but here is a description of how I'm > planning to add support for content conversion. > > A new CHANNELCONVERSIONS command is added. It takes the form > > tag CHANNELCONVERSIONS nstring > > This command returns a list of > supported conversion target mime types. If the nstring is NIL > the full list of conversion targets is returned. If the string > is non-nil it contains space separated list of top-level MIME > types to restrict the response list to. > > > The CHANNELCONVERSIONS response takes the form > > * CHANNELCONVERSIONS astring > > where the astring contains the MIME type. There is one untagged > response for each matching type. E.g. > > 1 CHANNELCONVERSIONS NIL > * CHANNELCONVERSIONS "image/gif" > * CHANNELCONVERSIONS "image/jpeg" > * CHANNELCONVERSIONS "audio/gsm" > * CHANNELCONVERSIONS "audio/g723" > * CHANNELCONVERSIONS "audio/basic" > * CHANNELCONVERSIONS "application/pdf" > * CHANNELCONVERSIONS "application/postscript" > * CHANNELCONVERSIONS "application/x-gzip" > 1 OK CHANNELCONVERSIONS completed > > 2 CHANNELCONVERSIONS "audio" > * CHANNELCONVERSIONS "audio/gsm" > * CHANNELCONVERSIONS "audio/g723" > * CHANNELCONVERSIONS "audio/basic" > 2 OK CHANNELCONVERSIONS completed > > 3 CHANNELCONVERSIONS "image audio foo" > * CHANNELCONVERSIONS "audio/gsm" > * CHANNELCONVERSIONS "audio/g723" > * CHANNELCONVERSIONS "audio/basic" > * CHANNELCONVERSIONS "image/gif" > * CHANNELCONVERSIONS "image/jpeg" > 3 OK CHANNELCONVERSIONS completed > > 4 CHANNELCONVERSIONS "foo" > 4 OK CHANNELCONVERSIONS completed > > The CHANNEL command is extended by adding a new parameter > that specifies > a conversion: > > tag CHANNEL channel-uri-list SP channel-set SP conversion-spec > > conversion-spec is an nstring that specifies a single MIME type to > convert the content to. If NIL, no conversion is performed. > > If the conversion cannot be performed, a NIL response is returned for > that item (the same behaviour as if the requested scheme failed). > > 5 CHANNEL (rtsp) (1 2) audio/mpeg > * 1 CHANNEL 2 NIL > 5 OK done but nothing was sent because audio/mpeg is not a valid > target > > > I'm still working out issues with IMAPURL. Also, the syntax here > gives the general sense, but the details will change when the grammar > gets an overhaul. I'm also working on the syntax and semantics for > how to specify the data is to be returned in-band. > > --lyndon > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 10 17:39:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13026 for ; Wed, 10 Nov 2004 17:39:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS192-00018o-6y for lemonade-web-archive@ietf.org; Wed, 10 Nov 2004 17:40:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS136-0003pS-6B; Wed, 10 Nov 2004 17:34:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0ti-00023o-J6 for lemonade@megatron.ietf.org; Wed, 10 Nov 2004 17:25:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11952 for ; Wed, 10 Nov 2004 17:24:59 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0uk-0000pZ-Rb for lemonade@ietf.org; Wed, 10 Nov 2004 17:26:07 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAAMOpcE092012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2004 15:24:55 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 10 Nov 2004 14:24:50 -0800 From: Lyndon Nerenberg To: Eric Burger Subject: RE: [lemonade] Channel updates for content conversion Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit --On 2004-11-10 2:24 PM -0500 Eric Burger wrote: > This assumes the IMAP server does the conversions. I'll yield > judgment of the wisdom of that to the IMAP server folks. Where else would you do it? Is there another model you're thinking of? > This does not really help for the real-time media types. For > example, there are many parameters of G.726, H.263, etc. that are not > _normally_ (but I suppose can be) conveyed as MIME parameters. I considered this but decided to ignore it unless it was going to be a real issue. I think we can deal with it easily enough by allowing the final parameter of the CHANNEL command to incorporate the full syntax of the value part of the MIME Content-Type header. E.g. 1 CHANNEL (foo) (1 2) "application/x-gzip; level=9 (an example)" > Where does the content go? Is the result of CHANNEL a URLAUTH? The content goes wherever the client specifies, according to the command. The syntax will be extended to allow CHANNEL to send data in-band by specifying a NIL scheme. E.g. 2 CHANNEL NIL (1 1) application/pdf I'm still working out the protocol syntax for the response (with the data). > Should the functionality be part of URLAUTH and not CHANNEL? I thought we decided in Vancouver that URLAUTH would have it's own scheme for doing conversion (through RTSP, wasn't it?). --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 10 21:17:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02010 for ; Wed, 10 Nov 2004 21:17:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4XK-0005b3-KP for lemonade-web-archive@ietf.org; Wed, 10 Nov 2004 21:18:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4Ud-0001JI-29; Wed, 10 Nov 2004 21:15:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4Pb-0008Sw-H6 for lemonade@megatron.ietf.org; Wed, 10 Nov 2004 21:10:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01484 for ; Wed, 10 Nov 2004 21:10:09 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4Qf-0005RD-Gx for lemonade@ietf.org; Wed, 10 Nov 2004 21:11:18 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iAB24A9N000145; Wed, 10 Nov 2004 21:04:20 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 21:01:15 -0500 Message-ID: From: Eric Burger To: Lyndon Nerenberg Subject: RE: [lemonade] Channel updates for content conversion Date: Wed, 10 Nov 2004 21:01:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 The idea from Vancouver is there are two types of conversion. One is IMAP server-based, most likely for non-stream media. The other is client-driven, most likely for streaming media. That said, once it is in the client's hands, it can do whatever it wants. The feeling in the room today is that server-based would be FETCH driven. What do you think of that? Likewise, for client-driven transcoding, the client needs a URL that it can hand off to the transcoding server. That would be simple URLAUTH. What about that? > -----Original Message----- > From: Lyndon Nerenberg [mailto:lyndon@orthanc.ca] > Sent: Wednesday, November 10, 2004 5:25 PM > To: Eric Burger > Cc: lemonade@ietf.org > Subject: RE: [lemonade] Channel updates for content conversion > > > --On 2004-11-10 2:24 PM -0500 Eric Burger > wrote: > > > This assumes the IMAP server does the conversions. I'll yield > > judgment of the wisdom of that to the IMAP server folks. > > > Where else would you do it? Is there another model you're thinking of? > > > This does not really help for the real-time media types. For > > example, there are many parameters of G.726, H.263, etc. > that are not > > _normally_ (but I suppose can be) conveyed as MIME parameters. > > I considered this but decided to ignore it unless it was going to be > a real issue. I think we can deal with it easily enough by allowing > the final parameter of the CHANNEL command to incorporate the full > syntax of the value part of the MIME Content-Type header. E.g. > > 1 CHANNEL (foo) (1 2) "application/x-gzip; level=9 (an example)" > > > Where does the content go? Is the result of CHANNEL a URLAUTH? > > The content goes wherever the client specifies, according to the > command. > The syntax will be extended to allow CHANNEL to send data in-band by > specifying > a NIL scheme. E.g. > > 2 CHANNEL NIL (1 1) application/pdf > > I'm still working out the protocol syntax for the response (with the > data). > > > Should the functionality be part of URLAUTH and not CHANNEL? > > I thought we decided in Vancouver that URLAUTH would have it's own > scheme for doing conversion (through RTSP, wasn't it?). > > > --lyndon > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 10 21:41:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03818 for ; Wed, 10 Nov 2004 21:41:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4uj-00065f-VH for lemonade-web-archive@ietf.org; Wed, 10 Nov 2004 21:42:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4p8-0005bw-Lr; Wed, 10 Nov 2004 21:36:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4in-00042o-SH for lemonade@megatron.ietf.org; Wed, 10 Nov 2004 21:30:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03001 for ; Wed, 10 Nov 2004 21:29:59 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4js-0005ry-AV for lemonade@ietf.org; Wed, 10 Nov 2004 21:31:08 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAB2TW46038918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2004 19:29:36 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 10 Nov 2004 18:29:32 -0800 From: Lyndon Nerenberg To: Eric Burger Subject: RE: [lemonade] Channel updates for content conversion Message-ID: <40A59F586B52EC1B4C3465CD@peregrin.orthanc.ca> In-Reply-To: References: X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-SdV-Metrics: orthanc.ca 1179; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit --On 2004-11-10 9:01 PM -0500 Eric Burger wrote: > The feeling in the room today is that server-based would be FETCH > driven. What do you think of that? The issue I see with FETCH is the lack of an 8bit clean path. The converted data would still most likely require base64 encoding. I would like to hear Mark's opinion on this. We could structure conversion such that it would work with FETCH, BINARY, and CHANNEL. My concern with this is that it would require adding yet another capability, and as Alexey mentioned, IMAP is growing *way* too many capabilities. From an engineering standpoint I think it's better to implement in-band conversion in one place only. This eliminates the problems associated with maintaining (and debugging) multiple code paths, eliminates the requirement for a separate capability, and avoids a lot of complexity in the protocol grammar. > Likewise, for client-driven transcoding, the client needs a URL that > it can hand off to the transcoding server. That would be simple > URLAUTH. What about that? Yes, that sounds like what was agreed to in Vancouver (I couldn't find my notes with the specifics when I sent the last message). --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 10 22:59:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10524 for ; Wed, 10 Nov 2004 22:59:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS68m-0007Sy-5r for lemonade-web-archive@ietf.org; Wed, 10 Nov 2004 23:00:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS618-00024f-C1; Wed, 10 Nov 2004 22:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5tU-0000Z8-Ic for lemonade@megatron.ietf.org; Wed, 10 Nov 2004 22:45:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09482 for ; Wed, 10 Nov 2004 22:45:04 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS5uW-0007EX-Hq for lemonade@ietf.org; Wed, 10 Nov 2004 22:46:14 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iAB3dVdP005992; Wed, 10 Nov 2004 22:39:32 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 22:36:36 -0500 Message-ID: From: Eric Burger To: Lyndon Nerenberg Subject: RE: [lemonade] Channel updates for content conversion Date: Wed, 10 Nov 2004 22:36:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 I could live with a new, foo command that retrieves content in 8-bit binary mode with translations. I suppose we could call it "CHANNEL" :) That is easy for me to say. I don't write servers, so I'll "go with the flow." Mark? Alexey? > -----Original Message----- > From: Lyndon Nerenberg [mailto:lyndon@orthanc.ca] > Sent: Wednesday, November 10, 2004 9:30 PM > To: Eric Burger > Cc: lemonade@ietf.org > Subject: RE: [lemonade] Channel updates for content conversion > > > --On 2004-11-10 9:01 PM -0500 Eric Burger > wrote: > > > The feeling in the room today is that server-based would be FETCH > > driven. What do you think of that? > > The issue I see with FETCH is the lack of an 8bit clean path. The > converted data would still most likely require base64 > encoding. I would > like to hear Mark's opinion on this. We could structure > conversion such > that it would work with FETCH, BINARY, and CHANNEL. My concern with > this is that it would require adding yet another capability, and as > Alexey mentioned, IMAP is growing *way* too many > capabilities. From an > engineering standpoint I think it's better to implement in-band > conversion in one place only. This eliminates the problems associated > with maintaining (and debugging) multiple code paths, eliminates the > requirement for a separate capability, and avoids a lot of complexity > in the protocol grammar. > > > Likewise, for client-driven transcoding, the client needs a URL that > > it can hand off to the transcoding server. That would be simple > > URLAUTH. What about that? > > Yes, that sounds like what was agreed to in Vancouver (I > couldn't find > my notes with the specifics when I sent the last message). > > --lyndon > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 10 23:28:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12165 for ; Wed, 10 Nov 2004 23:28:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS6ae-0007ym-F7 for lemonade-web-archive@ietf.org; Wed, 10 Nov 2004 23:29:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS6Su-0006Y6-VS; Wed, 10 Nov 2004 23:21:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS6Df-0004aW-ES for lemonade@megatron.ietf.org; Wed, 10 Nov 2004 23:06:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10982 for ; Wed, 10 Nov 2004 23:05:46 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS6Ea-0007bS-0B for lemonade@ietf.org; Wed, 10 Nov 2004 23:06:57 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAB45IUa041555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2004 21:05:22 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 10 Nov 2004 20:05:17 -0800 From: Lyndon Nerenberg To: Eric Burger Subject: RE: [lemonade] Channel updates for content conversion Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-SdV-Metrics: orthanc.ca 1179; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit --On 2004-11-10 10:36 PM -0500 Eric Burger wrote: > That is easy for me to say. I don't write servers, so I'll "go with > the flow." Hey, us server authors get away easy. We don't have to maintain the client state machine that resolves the n*m capability graph to figure out how to do 'foo' with a given server instance :-) Seriously, though, the issue of multiple capabilities and code paths is much more of a nightmare on the client side. I will strongly oppose any proposal that supports multiple paths leading to exactly the same result, unless there is a very good reason for it (from a protocol and software engineering standpoint). --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 11 18:56:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15743 for ; Thu, 11 Nov 2004 18:56:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSOoi-00014H-WD for lemonade-web-archive@ietf.org; Thu, 11 Nov 2004 18:57:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSOmw-0000HT-7n; Thu, 11 Nov 2004 18:55:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSOjn-0007x7-Uy for lemonade@megatron.ietf.org; Thu, 11 Nov 2004 18:52:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15555 for ; Thu, 11 Nov 2004 18:52:21 -0500 (EST) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSOl3-00010C-TT for lemonade@ietf.org; Thu, 11 Nov 2004 18:53:42 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iABNqJht004903; Thu, 11 Nov 2004 15:52:19 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iABNqJ1N020152 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Nov 2004 15:52:19 -0800 Date: Thu, 11 Nov 2004 15:50:17 -0800 (Pacific Standard Time) From: Mark Crispin To: Glenn Parsons Subject: Re: [lemonade] Draft Meeting Minutes for Monday In-Reply-To: <538A9E90-325D-11D9-9764-00306577589E@americasm01.nt.com> Message-ID: References: <538A9E90-325D-11D9-9764-00306577589E@americasm01.nt.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Tue, 9 Nov 2004, Glenn Parsons wrote: > If we leave it out, do you need to upissue the draft? > I would like to WGLC the forward w/o download trio in the next week or > so. If we leave out anonymous and authuser, the current posted draft is ready for WGLC. However, my WGLC comment would be "let's put in anonymous and authuser". :-) -- 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 From lemonade-bounces@ietf.org Fri Nov 12 15:09:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08667 for ; Fri, 12 Nov 2004 15:09:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CShlQ-0001Ea-22 for lemonade-web-archive@ietf.org; Fri, 12 Nov 2004 15:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShhR-0007ZH-5A; Fri, 12 Nov 2004 15:07:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShg3-0006C1-Vm; Fri, 12 Nov 2004 15:05:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07975; Fri, 12 Nov 2004 15:05:45 -0500 (EST) Message-Id: <200411122005.PAA07975@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 12 Nov 2004 15:05:45 -0500 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-mms-mapping-02.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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --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 : Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail Author(s) : R. Gellens Filename : draft-ietf-lemonade-mms-mapping-02.txt Pages : 32 Date : 2004-11-12 The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which are similar to, but differ in key ways from those used in Internet mail. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in ESMTP and Internet message headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping-02.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-mms-mapping-02.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-mms-mapping-02.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: <2004-11-12134457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-mms-mapping-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-mms-mapping-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-12134457.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Nov 12 16:14:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25050 for ; Fri, 12 Nov 2004 16:14:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSimQ-0006R0-19 for lemonade-web-archive@ietf.org; Fri, 12 Nov 2004 16:16:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiUd-0002F8-C9; Fri, 12 Nov 2004 15:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShyx-0003gu-Cl for lemonade@megatron.ietf.org; Fri, 12 Nov 2004 15:25:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11732 for ; Fri, 12 Nov 2004 15:25:17 -0500 (EST) Received: from chd-nt-exch1.inter-tel.com ([192.68.180.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSi0N-0001vi-Kt for lemonade@ietf.org; Fri, 12 Nov 2004 15:26:49 -0500 Received: from TMS-NT-EVS01.inter-tel.com ([172.30.201.91]) by chd-nt-exch1.inter-tel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 12 Nov 2004 13:24:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [lemonade] Channel updates for content conversion Date: Fri, 12 Nov 2004 13:24:57 -0700 Message-ID: <2E1FC8F46C110C4DB01FBDEA78355E13BF0263@TMS-NT-EVS01.inter-tel.com> Thread-Topic: RE: [lemonade] Channel updates for content conversion Thread-Index: AcTI9azMSNmbZrBNQxCEong7K0y1SQ== From: "Ringel, Rick" To: X-OriginalArrivalTime: 12 Nov 2004 20:24:57.0334 (UTC) FILETIME=[AD4E2960:01C4C8F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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="===============0451867088==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede This is a multi-part message in MIME format. --===============0451867088== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C8F5.AD2F7107" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C8F5.AD2F7107 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'm not familiar with all the work that has been completed, and the discussions that have led up to this thread. But, I wanted to suggest something, on the outside chance it has not been discussed and rejected. Forgive my late arrival. Rather than have the client explicitly request a conversion for a specific attachment, has the group considered the addition of a session variable that contains a list of 'preference' formats for audio, image, etc. The server could take preferences into account before rendering the headers in the FETCH response. In other words, the client would establish an abstracted 'view' of the message store. For example, if a low-rate device wants to see all audio files in G.729, then it would set this preference session variable to contain audio/G.729. Then, when the server is processing FETCH commands, it can determine if the native format matches G.729, or if not, determine if a conversion is possible. In either case, it can publish audio/G.729 as the content type, and thus avoid any explicit conversion requests. Any subsequent FETCH of the attachment is served in G.729 format. This would stay in scope during use of the CHANNEL and BINARY commands as well. =20 >From an implementation standpoint, it might simplify the client side to deal with conversion/format issues subsequent to the login phase, but before initiating any mailbox/message/attachment navigation. -Rick Ringel ------_=_NextPart_001_01C4C8F5.AD2F7107 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [lemonade] Channel updates for content conversion

All,

I'm not familiar with all the work that = has been completed, and the discussions that have led up to this = thread.  But, I wanted to suggest something, on the outside chance = it has not been discussed and rejected.  Forgive my late = arrival.

Rather than have the client explicitly = request a conversion for a specific attachment, has the group considered = the addition of a session variable that contains a list of 'preference' = formats for audio, image, etc.   The server could take = preferences into account before rendering the headers in the FETCH = response.  In other words, the client would establish an abstracted = 'view' of the message store.

For example, if a low-rate device wants = to see all audio files in G.729, then it would set this preference = session variable to contain audio/G.729.  Then, when the server is = processing FETCH commands, it can determine if the native format matches = G.729, or if not, determine if a conversion is possible.  In either = case, it can publish audio/G.729 as the content type, and thus avoid any = explicit conversion requests.  Any subsequent FETCH of the = attachment is served in G.729 format.  This would stay in scope = during use of the CHANNEL and BINARY commands as well. 

From an implementation standpoint, it = might simplify the client side to deal with conversion/format issues = subsequent to the login phase, but before initiating any = mailbox/message/attachment navigation.


-Rick Ringel


------_=_NextPart_001_01C4C8F5.AD2F7107-- --===============0451867088== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0451867088==-- From lemonade-bounces@ietf.org Fri Nov 12 16:53:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04368 for ; Fri, 12 Nov 2004 16:44:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSj34-0008L3-8X for lemonade-web-archive@ietf.org; Fri, 12 Nov 2004 16:33:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSin7-0004J4-QP; Fri, 12 Nov 2004 16:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSidE-0000tr-G7 for lemonade@megatron.ietf.org; Fri, 12 Nov 2004 16:06:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23229 for ; Fri, 12 Nov 2004 16:06:54 -0500 (EST) From: Corby.Wilson@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSief-0005ok-7d for lemonade@ietf.org; Fri, 12 Nov 2004 16:08:26 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iACL6iF10896; Fri, 12 Nov 2004 23:06:45 +0200 (EET) X-Scanned: Fri, 12 Nov 2004 23:05:00 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iACL50WZ023840; Fri, 12 Nov 2004 23:05:00 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 005iqDCG; Fri, 12 Nov 2004 23:04:58 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iACL4ua22168; Fri, 12 Nov 2004 23:04:56 +0200 (EET) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 12 Nov 2004 15:04:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Nov 2004 15:04:49 -0600 Message-ID: <78E9902B779FD5428DB035B5F6A50EFB02761140@daebe004.americas.nokia.com> Thread-Topic: Draft Meeting Minutes for Wednesday thread-index: AcTI+z1wTXuCN4XpRSiYQV6NG3he7g== To: , X-OriginalArrivalTime: 12 Nov 2004 21:04:50.0573 (UTC) FILETIME=[3FC973D0:01C4C8FB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org Subject: [lemonade] Draft Meeting Minutes for Wednesday 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Content-Transfer-Encoding: quoted-printable Here are the logs. ----------------------------------------------------------- [14:38:16] welcome to Lemonade [14:38:29] Glen has a new clone. Congratulations! [14:38:56] Agenda bashing [14:39:54] Monday Recap [14:40:18] MMS Mapping, Future Deliv, and S2S are done. Looking for WGLC [14:41:02] URLAUTH: anonymous question on list. Authors will leave it in. [14:41:09] BURL: Done, some nits [14:41:21] CATENATE: Use cases needed (Alexey) [14:41:37] Send URLAUTH, BURL, CATENATE to WGLC by Dec 1 [14:41:53] Pete: BURL, nits identified on ML? [14:42:04] Pete: WGLC BURL now. [14:42:19] Is BURL dependent on other 2? [14:42:36] Glenn: Submit all 3 at the same time for WGCL. No need to do individual submission? [14:42:48] Discussion on WGCL process. [14:43:26] CLEARIDLE/CHECKPOINT: vs. Quick Reconnect and S2C. [14:43:51] Is it appropriate in light of other tech: XMPP, SOAP, SIP, etc. [14:44:08] Definitions seem outside of charter, but we can add. [14:44:19] MSGFILTER: Seems similar to XFILTER. [14:44:20] I need to finish off CATENATE the week of Nov. 22, so I'll need examples by then. [14:44:41] Pete: no problems. [14:44:50] MSGFILTER does not scale in IMAP. [14:44:51] Thanks Alexey. [14:45:02] Subtle diff btw XFILTER and MSGFILTER. Mobile Email (Stephane Maes) http://flyingfox.snowshore.com/i-d/lemonade/slides61/lemonadeChairs61-da y2.ppt ------------------------------------------------ [14:45:12] Stephane: Mobile email [14:45:58] Purpose is to understand notion of mobile email and should lemonade address the notion of mobile email. [14:46:18] Mobile email: "Access to email while mobile" [14:46:34] Expectation: Receive somewhat-instant notification of email [14:46:47] Efficient manipulation of email [14:46:52] e2e secure [14:47:09] Eric: Anybody surprised by this? (non-goals) [14:47:34] Eric: Notifications can be minutes on the corporate LAN. Immediate notification not necessarily the goal. [14:48:36] Mobile extensions to mail. Full scope to provide mobile email solution including IMAP, SMTP, and all associated tech. [14:48:44] Define quasi-instantaneous delivery [14:49:53] Expect appropriate behavior of email delivery when notifications are enabled. [14:50:24] Additional considerations: Format adaptation (CHANNEL?) DRM rules, Provisioning, Charging (billing), etc. [14:50:43] Pete: All of this is fine, as long as everyone understands that we only work on IP based protocols. [14:51:08] Corby: Sufficient to define a UDP protocol, but not a WAP. [14:51:27] Eric (hat off): Define a msg format and transport (hypothetical). [14:51:50] Mobile world would take GW to SMS or WAP. That's fine, but we won't do it. We will define the GW and interface, but that's it. [14:52:11] This is internet email that supports mobile environments. [14:52:40] Randall: Provisioning, tech already exists (XCAP,etc). Why do we need to redefine for Lemonade. [14:52:48] Eric: is it useful for mail [14:53:22] WGCh: Do Provisioning after everything else has been defined. [14:53:47] Firewall: Are we considering FW and NAT traversal for this? [14:53:50] Stephane: Yes. [14:54:43] Challenges for Consumer and Enterprises; [14:55:00] FW, VPNs, E2E sec, etc. etc. etc. [14:55:08] Deployment Patterns (see slides) [14:56:07] Different deployment models for typical enterprise email setup. [14:57:26] Pete: If you were to circle everything in internet and operator space, everything in that space is not something we are working on? [14:57:49] Is Mobile e-mail enabling server etc. in the domain of IP? [14:58:01] Is the connector the edge of IP? [14:58:16] Pete; Connector is not an IP protocol entity. [14:58:34] Greg: Connector can be an IMAP proxy. [14:58:44] Connector is a logical drawing and may not necessarily exists [14:59:20] In fact, the goal of the WG is the line from the email client to the email server. [14:59:43] There may be other servers, proxies, GW in between, but these are out of the scope of the WG. [15:00:14] What is the scope of Lemonade? [15:00:28] Greg: Wants all of these issues addressed (many). [15:00:51] Greg: The competition is extreme and they handle all of the scenarios, so if we don't why are we here? [15:01:14] Greg: All current email is either proprietary or proprietary derivatives of existing standards. [15:01:49] Stephane: Argument can be made to do E2E in IMAP, but reality is we will require other servers to mobilize across networks and vendor spaces. [15:02:18] (cont) Do we want to create something that can compete in the space or do we want to improve what we have? [15:03:05] We will not contort protocols to work around implementation deficiencies in the TCP/IP stack infra in mobile networks and devices. [15:03:18] Don't fix IP problems in the phones. [15:03:52] Eric: Timeline is next year. Most likely the phones will be fixed by the time we release Lemonade. [15:04:31] Eric: Apr 2004, BLOAT was proposed which would solve all these issues. Not considered for this, but just an example [15:05:18] S: Understanding that we can not keep a TCP connection up all the time, we can't fix that and we shouldn't try to fix that, but we=20 can account for characteristics of the network. [15:05:19] FYI, the web slides are on the LEMONADE supplemental site [15:05:23] Eric: We are going to be idealistic and practical. [15:06:18] Randy: If we have solutions which are useful for general classes of problems, then we can support more. Lemonade Goals (Kue Wong) http://flyingfox.snowshore.com/i-d/lemonade/slides61/Goals_-_IETF_61_com ments_KW.ppt ------------------------------------------ [15:06:33] Presentation of Lemonade Goals: [15:06:50] Comments were useful and were incorporated into the draft. [15:07:08] All editorial nits accepted. [15:07:51] the goals document was not intended as a working requirements document, but rather as a historical record. [15:08:54] Eric: we are not going to replace IMAP, (IMAP-NG). [15:09:22] Eric: We are extending IMAP not writing replacement commands or protocols. [15:09:28] No such thing as a Lemonade protocol. [15:10:24] Discussion on Goals references. NP [15:11:21] Fix phrasing in current Goals doc [15:12:11] Q: Is the intion of MMS mapping to define MMS as the primary transport of Lemonade in mobile net? [15:13:45] Randy: Mapping work hits charter item. If you have MMS system and a separate mail system, then those systems can interoperate. There is no dependency in Lemonade to MMS. [15:13:55] Randy: Simply and inter-working document. [15:14:29] Eric: Pragmatic approach to interworking protocols. [15:15:24] Randy: First step to replacing MMS or custom protocols with IP protocols to get homogeneous network system over mobile nets [15:17:30] Reminder: Slide sets available on Alternate Lemonade Page: http://flyingfox.snowshore.com/i-d/lemonade/ [15:17:58] Glenn: We are not creating a new IMAP, we are not creating a new internet email. We are simply defining extensions. [15:18:40] Stephane: Needed to understand the goal of the Goals document. [15:18:53] Q&A: none [15:19:17] Eric: Mumbling: All changes are editorial in nature, so WGLC is closed. [15:19:28] No objections given. Update doc and send to AD ASAP. [15:20:06] Stephane: Goal2 item. Will have some time to discuss progress resolution? [15:20:16] Glenn: Will discuss at end of meeting. Lemonade Profile (Stephane Maes) http://flyingfox.snowshore.com/i-d/lemonade/slides61/lemonadeChairs61-da y2.ppt -------------------------------------------------- [15:20:34] ----------------------------------- [15:20:40] Stephane: Presenting Lemonade Profile [15:20:53] What should be done with profile. [15:21:20] Add the current drafts into profile content. [15:21:51] Glenn: WGCL on profile, decide if we want profile1 and go to new profile or hold profile and continue to update profile and make it a living doc. [15:22:16] Have profile1 be a living doc and continue update and limit to current drafts. [15:22:35] have revision on profile in the next 2 weeks for submission. [15:25:39] Note that the Stephane's slides on mobile email are in the directory for the 60.5 interim meeting Quick Reconnect (Corby Wilson) (slides not yet on web site (Eric: fix)) [15:22:49] -------------------------- [15:23:09] Someone channel Alexey if he as a question or statement. [15:25:54] Corby presenting [15:26:56] indicates that some study is still needed on Michael Wenner's proposal=20 [15:27:19] New SID/NEWSID param on LOGIN/AUTHENTICATE [15:27:28] Creates resumable session. Can keep on LOGOUT. [15:27:35] Send EXPUNGEs [15:27:54] Send FLAGs [15:28:25] Corby goes through states [15:31:44] Open issues: [15:32:08] - server-side state cache (can we eliminate this and have client send enough information) [15:32:26] - number of sessions per account [15:32:26] clarification that loss of SID may require resync of dynamic info (uidlist, flags) but unless the UID validity changes it doesn't require resync of static info [15:32:27] - timeout [15:32:30] - condstore [15:35:19] Cyrus points out that currently clients can reconnect without blocking while resynch [15:35:28] The CONDSTORE issue: RECONNECT extends LOGIN to report EXPUNGEs, do we want to do the same to SELECT (i.e. extend CONDSTORE a bit) [15:35:32] Cyrus suggests bandwidth reduction is a worthwhile goal [15:36:58] The timeout issue: what should be the default? Should the server be able to advertise its session expiration timeout? [15:38:08] Discussion of implicit checkpoints: how does server know which responses client has received [15:39:30] Cyrus asks why we need SID if we already require CONDSTORE; client can use CONDSTORE to request changes [15:41:21] The currently opened mailbox is bound to the SID [15:41:43] Alexey: what is that in response to? [15:42:04] In response to the last question from Cyrus [15:42:40] So it just saves SELECT? [15:42:47] Yes [15:43:57] Maybe we can replace SID with mailbox name. But I have to=20 check that nothing else is going to be lost after this change. [15:45:06] Randy notes that if SID only buys you ability to avoid SELECT=20 if you get lucky and reconnect within timeout, then why not come up with another=20 mechanism that allows you to avoid SELECT at all times, so it benefits clients=20 that reconnect 3x week as well as those that happened to get dropped. [15:45:07] the expunge information may be, but if that is done as an=20 extension to condstore... [15:46:28] Eric suggests this is a service provider choice (how much=20 resources to spend and hence how long timeouts are permitted) [15:46:29] Currently the assumption is that the current mailbox=20 state is associated with SID, so on reconnect some responses don't have to=20 be sent to the client. [15:47:32] Ted suggests loss of connectivity is more compelling problem=20 than reconnect 3x week, notes that LDAP has similar problems [15:48:10] Alexey: I thought there was discussion on adding this to=20 CONDSTORE? [15:48:16] So only CONDSTORE was needed? [15:48:39] Chris would like to do without SID if possible, adds more=20 complexity [15:48:40] Randy: adding what to CONDSTORE? [15:49:03] Alexey: adding extra responses that aren't there now [15:49:36] RECONNECT also combines LOGIN with SELECT [15:49:39] Chris suggests that are approaches that would avoid=20 round-trips by adding atomicity to reconnect [15:50:32] Alexey: right, so if we add the extra responses to CONDSTORE,=20 all that RECONNECT gives you is ability to avoid SELECT, and we can have a=20 mechanism for just that [15:51:41] Chris suggests that today very few clients use PIPELINING,=20 and suggests one reason is the problem that an early command fails but=20 subsequent ones run anyway, atomicity allows sequence to abort [15:52:00] Randy: maybe. Something is still bothering me about state=20 of the selected mailbox. But I can't say what yet [15:52:19] Corby sais big problem is too much information coming back,=20 much of it redundant [15:52:31] I've heard that Apple mail uses PIPELINING [15:53:19] Corby mentioned Thunderbird does too? [15:55:31] Cyrus to look at Alexey's document to see about adding=20 advice on how not to be a stupid client [15:56:00] Draft is 'draft-melnikov-imap-disc-05.txt' [15:56:30] Actually -06 now CHANNEL (Eric Burger) (no slides) [15:56:41] ------------------- [15:56:43] Take over [15:56:47] TRANSCODING [15:57:29] See email from Lydon on Transcoding (WED 11.10.2003) [15:57:34] if condstore is extended to do expunge bits, it may be wise to include a section describing how it affects the IMAP-DISC discussion [15:58:07] Add MIME type to CHANNELCONVERSION to indiciate capabilities. [15:58:32] Use channel command to do a particular transformation from (a) to (b) [15:59:10] Eric: Recap Vancouver discussion on transcoding. [15:59:26] IMAP server asks for the conversion to be done. [16:00:09] Phillip: Use URLAUTH to convert. [16:01:08] If it's a streaming event use URLAUTH. On normal objects and attachments we had just normal IMAP FETCH [16:01:29] Some of these formats take many many parameters (eg, video). [16:01:54] Eric: Mime type is not sufficient to do the conversion because more parameters are needed to do proper transformation. [16:02:15] Eric; Is this the way we want to go?=20 [16:02:46] Gregg: Is this the consesus on view of streaming retrieval for case A. Use IMAP or RTSP? [16:03:38] What about S/MIME and resigning. [16:03:46] Was discussed in Vancouver. [16:04:03] Eric: Not solvable for enc/dec. But for signing what do we need? [16:04:14] What is on the server, stays on the server. [16:04:33] Server content never changes, but what you fetch may change and may loose it's signature/ [16:04:44] Yes, that may happen [16:05:08] They may or may not now that the content has changed, but they know that it isn't signed. [16:05:53] remove the signature as content is transformed, or leave the sig and leave it broken. [16:06:11] Transform the signed part into a hash? [16:06:48] 822 discussion on signing individual parts and then hashing the tree to confirm individual singed parts. [16:07:33] Use contenttype "multipart/alternative"? [16:08:09] Is there a way to verify the signature with out downloading the entire message. [16:08:31] What is the usecase for transcoding? [16:09:09] Client device can not handle original content of attachment. Client asks server to translate type into something the terminal can display. [16:09:38] Signing is something we need to be aware of, but not something we need to solve here. [16:10:10] ERIC: We need a new "Stupid Things" Draft for lemonade to add nits like this to make people aware that we thought about it. [16:10:48] To Eric: maybe this is a part of Lemonade profile? [16:11:09] Isd this a general IMAP problem? Or do other email servers have to deal with this?? [16:11:37] Side Note: Please review OPES re-charter. It is relevant to the work we are doing here and everyone needs to be aware of this [16:12:17] OPES protocol may simplify this problem by using OPES server to resign body/mime parts. [16:13:23] Randy: Confirm consensus. For the class of content where the content doesn't need to be streamed, client asks server to FETCH and transcode it, second, client connects to separate server with URLAUTH and asks transform server to do the work for it. [16:13:44] Eric: All we care about is how to hack FETCH to do transcoding. [16:14:08] Randy: Usefull for informational note to say: OPES may be useful approach to solving this problem. [16:14:31] Send Signing to IMAP-EXT and let them deal with it :) [16:14:52] Pete: Fine to pass over to IMAP-EXT, but they may ask use to work on it. [16:14:58] Do we want to Punt? [16:15:04] Corby: if you want to delay something for long time, that is a sure way :-) [16:16:16] Stephane: Develop CHANNEL document w/o signature problem now so we can move on this for now and deal with edge cases later. [16:16:47] (punt should be to S/MIME) Message Filtering (WG Chairs) ------------------------------------------ [16:16:23] ----------------- [16:16:28] Filter Discussion [16:17:34] Stephane: Third option: Decide in advance when a new message arrives, choose what is being downloaded.=20 [16:18:14] Use SIEVE to filter at the MTA. [16:18:52] PG: Changing the rules of what appears on your mobile can't be done quickly, and is difficult to make retroactive. [16:19:23] Pete: Chage SIVE rule to re-annotate the new stuff and re-annotate the current mail to take care or retroactive. [16:19:37] Sieve can be used to (a) forward selected messages to mobile, (b) move class of messages out of INBOX and only SELECT that folder, (c) use ANNOTATE to add annotation, mobile device does SEARCh and only selects items with annotation=20 [16:20:17] PG: I'm getting trafic for messages I don't care about. Is this important when terminal gets woken up for trafic I dont want to=20 see [16:21:41] 2 approaches. Filter to new mailboxes or filter on views. [16:21:54] Eric: Rathole we have entered before. [16:22:31] XFILTER is view mech of SQL.=20 [16:23:08] You rmobile rules are relativey static, and even if they do change you don't care about history (retroactgive behaviour) [16:24:18] Is the usecase that you have strong filters that you have for the device and you want to change dynamically. [16:25:06] Unless we have an argument for retroactive functionality, it=20 will not be added to the charter. [16:25:36] Coherent proposal for quick reconnect stratgegy [16:25:48] Added to charter, more discussions needed on ML Admin (WG Chairs) http://flyingfox.snowshore.com/i-d/lemonade/slides61/lemonadeChairs61-da y2.ppt -------------------------------------------------------- [16:25:51] ------- [16:25:53] TIMELINE [16:26:00] Dec1: Profile [16:26:07] WGLC: Pull trio [16:26:18] New Docs: S2C Notifications, Transcoding [16:26:28] ---------- [16:26:35] Interim? [16:26:40] Quick Reconnect Options [16:26:54] transcoding requirements [16:27:43] transcoding approaches [16:28:17] Interim: Jan 21-22, 2005 (afternoon-morning) [16:28:26] Host (def, Nortel-Calgary) [16:30:11] Screwup: Jan 20-21, 2005 (Thurs & Friday) [16:32:36] THANK YOU AND GOOD NIGHT! Corby Wilson Security, Connectivity & Mobillity NOKIA 503 Martindale Street Suite 610 Pittsburgh, PA 15212 +1.412.320.2068 (w) +1.412.320.2080 (f) +1.412.576.5402 (m) corby.wilson@nokia.com=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 12 16:59:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05079 for ; Fri, 12 Nov 2004 16:59:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjTI-0002D8-I5 for lemonade-web-archive@ietf.org; Fri, 12 Nov 2004 17:00:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjKt-0008ST-Px; Fri, 12 Nov 2004 16:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjDX-00051i-Do for lemonade@megatron.ietf.org; Fri, 12 Nov 2004 16:44:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04311 for ; Fri, 12 Nov 2004 16:44:19 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSj41-0008MF-Bp for lemonade@ietf.org; Fri, 12 Nov 2004 16:34:39 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iACLWYkh018622 for ; Fri, 12 Nov 2004 15:32:35 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <4M3GHJWP>; Fri, 12 Nov 2004 15:32:34 -0600 Message-ID: <54E40201497DF142B06B27255953F79710FDC24B@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: "Ringel, Rick" , lemonade@ietf.org Subject: RE: [lemonade] Channel updates for content conversion Date: Fri, 12 Nov 2004 15:32:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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="===============0527682824==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0527682824== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C8FF.1D3CDC40" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C8FF.1D3CDC40 Content-Type: text/plain; charset="iso-8859-1" This approach was discussed, in part because it is the model used by MMS, using UAProf. The group discussing it preferred to see the decision-making intelligence pushed down to the client which was in a better position to evaluate whether conversion is desirable. For example, the client is in a better position to determine if a given audio part, in your example, was suitable for conversion or not. It is not clear that a client would necessarily want MP3 audio converted to G.729. It is also clear that sometimes the client will want the content in full form and sometimes not, depending on circumstances. Is the client in a CDMA 1X or a EVDO network region? WiFi connected or dial-up? Is the content "valuable" enough to pay the extra price in getting full fidelity. In the example of the music, maybe it is worth downloading the MP3 file, or waiting to download the MP3 file when in a WiFi hotspot. This probably applies even more to visual media. A scanned text document re! duced to a thumbnail size is worthless, but a reduced size picture may still be useful. Also, limited devices are getting more flexible. They are gaining the ability to fetch new codecs on demand if the user determines that the content is valuable enough. The approach you describe is an important option, I just wanted to state where I think the previous discussions on this point have been. Greg V. -----Original Message----- From: Ringel, Rick [mailto:Rick_Ringel@inter-tel.com] Sent: Friday, November 12, 2004 3:25 PM To: lemonade@ietf.org Subject: RE: [lemonade] Channel updates for content conversion All, I'm not familiar with all the work that has been completed, and the discussions that have led up to this thread. But, I wanted to suggest something, on the outside chance it has not been discussed and rejected. Forgive my late arrival. Rather than have the client explicitly request a conversion for a specific attachment, has the group considered the addition of a session variable that contains a list of 'preference' formats for audio, image, etc. The server could take preferences into account before rendering the headers in the FETCH response. In other words, the client would establish an abstracted 'view' of the message store. For example, if a low-rate device wants to see all audio files in G.729, then it would set this preference session variable to contain audio/G.729. Then, when the server is processing FETCH commands, it can determine if the native format matches G.729, or if not, determine if a conversion is possible. In either case, it can publish audio/G.729 as the content type, and thus avoid any explicit conversion requests. Any subsequent FETCH of the attachment is served in G.729 format. This would stay in scope during use of the CHANNEL and BINARY commands as well. >From an implementation standpoint, it might simplify the client side to deal with conversion/format issues subsequent to the login phase, but before initiating any mailbox/message/attachment navigation. -Rick Ringel ------_=_NextPart_001_01C4C8FF.1D3CDC40 Content-Type: text/html; charset="iso-8859-1" RE: [lemonade] Channel updates for content conversion
This approach was discussed, in part because it is the model used by MMS, using UAProf.  The group discussing it preferred to see the decision-making intelligence pushed down to the client which was in a better position to evaluate whether conversion is desirable.  For example, the client is in a better position to determine if a given audio part, in your example, was suitable for conversion or not.  It is not clear that a client would necessarily want MP3 audio converted to G.729.  It is also clear that sometimes the client will want the content in full form and sometimes not, depending on circumstances.  Is the client in a CDMA 1X or a EVDO network region?  WiFi connected or dial-up?  Is the content "valuable" enough to pay the extra price in getting full fidelity.  In the example of the music, maybe it is worth downloading the MP3 file, or waiting to download the MP3 file when in a WiFi hotspot.  This probably applies even more to visual media.  A scanned text document reduced to a thumbnail size is worthless, but a reduced size picture may still be useful.
 
Also, limited devices are getting more flexible.  They are gaining the ability to fetch new codecs on demand if the user determines that the content is valuable enough. 
 
The approach you describe is an important option, I just wanted to state where I think the previous discussions on this point have been.
 
Greg V.
 
 
-----Original Message-----
From: Ringel, Rick [mailto:Rick_Ringel@inter-tel.com]
Sent: Friday, November 12, 2004 3:25 PM
To: lemonade@ietf.org
Subject: RE: [lemonade] Channel updates for content conversion


All,

I'm not familiar with all the work that has been completed, and the discussions that have led up to this thread.  But, I wanted to suggest something, on the outside chance it has not been discussed and rejected.  Forgive my late arrival.

Rather than have the client explicitly request a conversion for a specific attachment, has the group considered the addition of a session variable that contains a list of 'preference' formats for audio, image, etc.   The server could take preferences into account before rendering the headers in the FETCH response.  In other words, the client would establish an abstracted 'view' of the message store.

For example, if a low-rate device wants to see all audio files in G.729, then it would set this preference session variable to contain audio/G.729.  Then, when the server is processing FETCH commands, it can determine if the native format matches G.729, or if not, determine if a conversion is possible.  In either case, it can publish audio/G.729 as the content type, and thus avoid any explicit conversion requests.  Any subsequent FETCH of the attachment is served in G.729 format.  This would stay in scope during use of the CHANNEL and BINARY commands as well. 

From an implementation standpoint, it might simplify the client side to deal with conversion/format issues subsequent to the login phase, but before initiating any mailbox/message/attachment navigation.


-Rick Ringel


------_=_NextPart_001_01C4C8FF.1D3CDC40-- --===============0527682824== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0527682824==-- From lemonade-bounces@ietf.org Sat Nov 13 12:31:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19024 for ; Sat, 13 Nov 2004 12:31:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT1lv-0001Zf-TU for lemonade-web-archive@ietf.org; Sat, 13 Nov 2004 12:33:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT1bu-0006A1-5j; Sat, 13 Nov 2004 12:22:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT1Vh-0004ZP-Dc for lemonade@megatron.ietf.org; Sat, 13 Nov 2004 12:16:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17648 for ; Sat, 13 Nov 2004 12:16:23 -0500 (EST) From: Corby.Wilson@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT1XJ-0000ry-JD for lemonade@ietf.org; Sat, 13 Nov 2004 12:18:06 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iADHGBv12594; Sat, 13 Nov 2004 19:16:12 +0200 (EET) X-Scanned: Sat, 13 Nov 2004 19:14:07 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iADHE7aV019144; Sat, 13 Nov 2004 19:14:07 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 006rWxTQ; Sat, 13 Nov 2004 19:14:06 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iADHE4a28642; Sat, 13 Nov 2004 19:14:04 +0200 (EET) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 13 Nov 2004 11:14:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Channel updates for content conversion Date: Sat, 13 Nov 2004 11:14:01 -0600 Message-ID: <78E9902B779FD5428DB035B5F6A50EFB027611BD@daebe004.americas.nokia.com> Thread-Topic: [lemonade] Channel updates for content conversion thread-index: AcTHqgMqk+nhiyw7Qoyiclp+zByTrAB+GwDw To: , X-OriginalArrivalTime: 13 Nov 2004 17:14:02.0733 (UTC) FILETIME=[2C3E81D0:01C4C9A4] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable There has been much talk about CHANNEL doing stream conversion. I think we are getting bogged down with the most complex case and ignoring the majority case for content conversion: simple documents. While both are desired, I can see a server implementer choosing to implement only the simple case for the enterprise to allow document and image conversion. The streaming case (audio, video, etc.) seems to be geared more toward the consumer market and requires additional complexity and network resources to deploy. What I was thinking was to separate the CHANNEL draft into the two use cases we identified in Vancouver: (A) for RTP streaming, and (B) for simple file conversion and download. This would allow us to quickly generate a draft for the 80% use case while tackling the complexities of the 20% use case. On the issue of content transformation on the IMAP server: There are quite a few vendors out there that provide libraries and engines which convert content on the users' behalf (eg. ImageMagic). The transcoding can be done either on another server or in another process on the same machine, with a defined API or socket interface to convert the content before download. The problem of in-machine transcoding is that it doesn't scale well at all. Transcoding is VERY expensive and can cripple a server if too many requests are handled at the same time. However, for small businesses it is a perfect solution. I agree with Lyndon that adding the extensions to FETCH would overcomplicate the command. I'm not sure if we are allowed (according to the charter) to create new commands (CHANNEL || TRANSFORM || TRANSCODE), but in this case I can see the need for it simply to handle the variable parameter list better. Corby Wilson =20 > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On > Behalf Of ext Lyndon Nerenberg > Sent: Wednesday, November 10, 2004 11:05 PM > To: Eric Burger > Cc: lemonade@ietf.org > Subject: RE: [lemonade] Channel updates for content conversion >=20 > --On 2004-11-10 10:36 PM -0500 Eric Burger > wrote: >=20 > > That is easy for me to say. I don't write servers, so I'll "go with > > the flow." >=20 > Hey, us server authors get away easy. We don't have to maintain the > client state machine that resolves the n*m capability graph to figure > out how to do 'foo' with a given server instance :-) >=20 > Seriously, though, the issue of multiple capabilities and code paths is > much more of a nightmare on the client side. I will strongly oppose any > proposal that supports multiple paths leading to exactly the same > result, unless there is a very good reason for it (from a protocol and > software engineering standpoint). >=20 > --lyndon >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 13 14:07:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24083 for ; Sat, 13 Nov 2004 14:07:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT3GS-0005i0-NV for lemonade-web-archive@ietf.org; Sat, 13 Nov 2004 14:08:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT34p-0000Ze-7W; Sat, 13 Nov 2004 13:56:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT2yV-0008IR-Qv for lemonade@megatron.ietf.org; Sat, 13 Nov 2004 13:50:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23386 for ; Sat, 13 Nov 2004 13:50:15 -0500 (EST) Received: from agminet04.oracle.com ([141.146.126.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT309-0004wj-0x for lemonade@ietf.org; Sat, 13 Nov 2004 13:51:57 -0500 Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iADInWo3024175 for ; Sat, 13 Nov 2004 10:49:32 -0800 Received: from web69 (web69.oracle.com [148.87.122.101]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iADInUP6024156 for ; Sat, 13 Nov 2004 10:49:31 -0800 Message-ID: <30952000.1100372613171.JavaMail.besadmin@web69> Date: Sat, 13 Nov 2004 12:03:32 -0700 From: Stephane Maes To: corby.wilson@nokia.com, lyndon@orthanc.ca, eburger@brooktrout.com Subject: Re: [lemonade] Channel updates for content conversion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Thread-Topic: [lemonade] Channel updates for content conversion Thread-Index: AcTHqgMqk+nhiyw7Qoyiclp+zByTrAB+GwDwAARCQHU= X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Lyndon's approach is fine. Decision to implement within imap server to have the server delegate is an implementation / deployment choice supported by the proposal. Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM, Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: lemonade-bounces@ietf.org To: lyndon@orthanc.ca ; eburger@brooktrout.com CC: lemonade@ietf.org Sent: Sat Nov 13 10:14:01 2004 Subject: RE: [lemonade] Channel updates for content conversion There has been much talk about CHANNEL doing stream conversion. I think we are getting bogged down with the most complex case and ignoring the majority case for content conversion: simple documents. While both are desired, I can see a server implementer choosing to implement only the simple case for the enterprise to allow document and image conversion. The streaming case (audio, video, etc.) seems to be geared more toward the consumer market and requires additional complexity and network resources to deploy. What I was thinking was to separate the CHANNEL draft into the two use cases we identified in Vancouver: (A) for RTP streaming, and (B) for simple file conversion and download. This would allow us to quickly generate a draft for the 80% use case while tackling the complexities of the 20% use case. On the issue of content transformation on the IMAP server: There are quite a few vendors out there that provide libraries and engines which convert content on the users' behalf (eg. ImageMagic). The transcoding can be done either on another server or in another process on the same machine, with a defined API or socket interface to convert the content before download. The problem of in-machine transcoding is that it doesn't scale well at all. Transcoding is VERY expensive and can cripple a server if too many requests are handled at the same time. However, for small businesses it is a perfect solution. I agree with Lyndon that adding the extensions to FETCH would overcomplicate the command. I'm not sure if we are allowed (according to the charter) to create new commands (CHANNEL || TRANSFORM || TRANSCODE), but in this case I can see the need for it simply to handle the variable parameter list better. Corby Wilson > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On > Behalf Of ext Lyndon Nerenberg > Sent: Wednesday, November 10, 2004 11:05 PM > To: Eric Burger > Cc: lemonade@ietf.org > Subject: RE: [lemonade] Channel updates for content conversion > > --On 2004-11-10 10:36 PM -0500 Eric Burger > wrote: > > > That is easy for me to say. I don't write servers, so I'll "go with > > the flow." > > Hey, us server authors get away easy. We don't have to maintain the > client state machine that resolves the n*m capability graph to figure > out how to do 'foo' with a given server instance :-) > > Seriously, though, the issue of multiple capabilities and code paths is > much more of a nightmare on the client side. I will strongly oppose any > proposal that supports multiple paths leading to exactly the same > result, unless there is a very good reason for it (from a protocol and > software engineering standpoint). > > --lyndon > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 18 15:45:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06716 for ; Thu, 18 Nov 2004 15:45:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtCh-0003qa-Il for lemonade-web-archive@ietf.org; Thu, 18 Nov 2004 15:48:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsm5-0002Yh-LT; Thu, 18 Nov 2004 15:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsfj-0006mc-60; Thu, 18 Nov 2004 15:14:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01235; Thu, 18 Nov 2004 15:14:24 -0500 (EST) Message-Id: <200411182014.PAA01235@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 18 Nov 2004 15:14:24 -0500 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-urlauth-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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --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 : Internet Message Access Protocol (IMAP) - URLAUTH Extension Author(s) : M. Crispin Filename : draft-ietf-lemonade-urlauth-04.txt Pages : 0 Date : 2004-11-18 This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of "URLAUTH". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-urlauth-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-urlauth-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-urlauth-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: <2004-11-18141801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-urlauth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-urlauth-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-18141801.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Nov 19 17:06:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00115 for ; Fri, 19 Nov 2004 17:06:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVGx4-0003iS-D1 for lemonade-web-archive@ietf.org; Fri, 19 Nov 2004 17:09:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVGpz-0005NZ-7x; Fri, 19 Nov 2004 17:02:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVGif-0000to-8E for lemonade@megatron.ietf.org; Fri, 19 Nov 2004 16:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28488 for ; Fri, 19 Nov 2004 16:55:02 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVGlY-0003Dh-5J for lemonade@ietf.org; Fri, 19 Nov 2004 16:58:05 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iAJLoGQj003883 for ; Fri, 19 Nov 2004 16:50:18 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Nov 2004 16:47:16 -0500 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Fri, 19 Nov 2004 16:47:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.6 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [lemonade] URLAUTH WGLC 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de URLAUTH work group last call begins now and ends Monday, December 6 at 9am ET. This document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-urlauth-04.txt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 19 19:28:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11688 for ; Fri, 19 Nov 2004 19:28:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVJAB-0006Tz-Fk for lemonade-web-archive@ietf.org; Fri, 19 Nov 2004 19:31:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVJ5w-00044y-RH; Fri, 19 Nov 2004 19:27:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVIyy-0002kI-MH for lemonade@megatron.ietf.org; Fri, 19 Nov 2004 19:20:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11059 for ; Fri, 19 Nov 2004 19:20:01 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVJ1t-0006Kh-PY for lemonade@ietf.org; Fri, 19 Nov 2004 19:23:06 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iAK0I6iq014813 for ; Fri, 19 Nov 2004 19:18:08 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Nov 2004 19:15:07 -0500 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Fri, 19 Nov 2004 19:15:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [lemonade] WGLC's 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 I screwed up -- we were going to WGLC URLAUTH, BURL, and CATENATE in one fell swoop. The good news is there is no penalty for getting URLAUTH out early. The bad news is this puts pressure on the BURL and CATENATE authors to catch up :) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 20 10:29:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01117 for ; Sat, 20 Nov 2004 10:29:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVXDs-0007RV-J4 for lemonade-web-archive@ietf.org; Sat, 20 Nov 2004 10:32:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVX9w-0003HY-Fb; Sat, 20 Nov 2004 10:28:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVX7s-0002ti-ON for lemonade@megatron.ietf.org; Sat, 20 Nov 2004 10:26:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00904 for ; Sat, 20 Nov 2004 10:26:10 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVXAw-0007N8-39 for lemonade@ietf.org; Sat, 20 Nov 2004 10:29:22 -0500 Received: from [192.168.0.7] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 20 Nov 2004 15:25:22 +0000 Message-ID: <419F61E1.9060600@isode.com> Date: Sat, 20 Nov 2004 15:25:21 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Pete Resnick Subject: CATENATE comments: (was Re: [lemonade] WGLC's) 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: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Eric Burger wrote: >I screwed up -- we were going to WGLC URLAUTH, BURL, and CATENATE in one >fell swoop. > >The good news is there is no penalty for getting URLAUTH out early. > >The bad news is this puts pressure on the BURL and CATENATE authors to catch >up :) > > CATENATE will require at least one more revision, for several reasons: 1). I am writing examples to be added as discussed during the last IETF meeting. I will be sending them soon. 2). I've just realized that the CATENATE extension interacts with UIDPLUS and the CATENATE command must return APPENDUID if both are implemented. I suggest addition of the following text: CATENATE Interaction with UIDPLUS Extension Servers which support both CATENATE and [UIDPLUS] MUST return the APPENDUID response code in the tagged OK response of a successful CATENATE command. The APPENDUID response code contains as arguments the UIDVALIDITY of the destination mailbox and the UID assigned to the catenated message. The syntax of the APPENDUID response code is described in [UIDPLUS]. Add to Normative References: [UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988. 3). IANA considerations section is missing, something like: 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 CATENATE IMAP capability. IANA is requested to add this capability to the registry. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 21 18:13:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03031 for ; Sun, 21 Nov 2004 18:13:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW0wu-0005YY-58 for lemonade-web-archive@ietf.org; Sun, 21 Nov 2004 18:16:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW0re-0005bo-Mf; Sun, 21 Nov 2004 18:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW0qO-0004bC-NN for lemonade@megatron.ietf.org; Sun, 21 Nov 2004 18:10:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02518 for ; Sun, 21 Nov 2004 18:10:06 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW0tj-0005Tv-9j for lemonade@ietf.org; Sun, 21 Nov 2004 18:13:35 -0500 Received: from [213.116.60.140] (1Cust140.tnt106.lnd4.gbr.da.uu.net [213.116.60.140]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 21 Nov 2004 23:09:29 +0000 Message-ID: <41A11680.6050109@isode.com> Date: Sun, 21 Nov 2004 22:28:16 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] WGLC's References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Eric Burger wrote: >I screwed up -- we were going to WGLC URLAUTH, BURL, and CATENATE in one >fell swoop. > > One more thing. I've noticed that in the URLAUTH documents all URLs are transferred as quoted strings, while in CATENATE they transferred as is (MAILBOX-REFERRAL also transfers them with no surrounding quotes). >The good news is there is no penalty for getting URLAUTH out early. > >The bad news is this puts pressure on the BURL and CATENATE authors to catch >up :) > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 21 18:14:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03214 for ; Sun, 21 Nov 2004 18:14:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW0yH-0005a6-7n for lemonade-web-archive@ietf.org; Sun, 21 Nov 2004 18:18:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW0re-0005bt-Sn; Sun, 21 Nov 2004 18:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW0qo-0004sK-5C for lemonade@megatron.ietf.org; Sun, 21 Nov 2004 18:10:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02565 for ; Sun, 21 Nov 2004 18:10:31 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW0u8-0005UG-AE for lemonade@ietf.org; Sun, 21 Nov 2004 18:14:01 -0500 Received: from [213.116.60.140] (1Cust140.tnt106.lnd4.gbr.da.uu.net [213.116.60.140]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 21 Nov 2004 23:09:48 +0000 Message-ID: <41A11FA0.7040104@isode.com> Date: Sun, 21 Nov 2004 23:07:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------040905040101070607010205" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: lemonade@ietf.org Subject: [lemonade] Examples for CATENATE 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc --------------040905040101070607010205 Content-type: text/plain; charset="us-ascii" --------------040905040101070607010205 Content-type: text/plain; name="Catenate.Examples&Comments.txt" Content-Disposition: inline; filename="Catenate.Examples&Comments.txt" Content-Transfer-Encoding: 7bit Lines not starting with "C: " or "S: " are continuations of the previous lines. Example 1: The following example demonstrates how a CATENATE client can replace an attachment in a draft message, without the need to download it to the client and upload it back. The original message (UID = 20) has the following structure: multipart/mixed MIME message with two body parts: 1 - text/plain 2 - application/x-zip-compressed C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) {} S: + Ready for literal data C: Return-Path: C: Received: from [127.0.0.2] C: by rufus.example.org via TCP (internal) with ESMTPA; C: Thu, 11 Nov 2004 16:57:07 +0000 C: Message-ID: <419399E1.6000505@example.org> C: Date: Thu, 11 Nov 2004 16:57:05 +0000 C: From: Bob Ar C: X-Accept-Language: en-us, en C: MIME-Version: 1.0 C: To: foo@example.org C: Subject: A message with attachment C: Content-Type: multipart/mixed; C: boundary="------------030308070208000400050907" C: C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section =1.1 {} S: + Ready for literal data C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=30 {} C: --------------030308070208000400050907-- C: S: A003 OK CATENATE Completed Here , and are lengths of the corresponding literals. <> Example 2: The following example demonstrates how CATENATE can be used to replace edited text in a draft message. The previous version of the draft is marked as \Deleted. Note, that the server also supports the UIDPLUS extension, so the APPENDUID response code is returned in the successful OK response to the CATENATE command. C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) {} S: + Ready for literal data C: Return-Path: C: Received: from [127.0.0.2] C: by rufus.example.org via TCP (internal) with ESMTPA; C: Thu, 11 Nov 2004 16:57:07 +0000 C: Message-ID: <419399E1.6000505@example.org> C: Date: Thu, 12 Nov 2004 16:57:05 +0000 C: From: Bob Ar C: X-Accept-Language: en-us, en C: MIME-Version: 1.0 C: To: foo@example.net C: Subject: About our holiday trip C: Content-Type: multipart/mixed; C: boundary="------------030308070208000400050907" C: C: --------------030308070208000400050907 C: Content-Type: text/plain; charset=us-ascii; format=flowed C: Content-Transfer-Encoding: 7bit C: C: Our travel agent has sent the updated schedule. C: C: Cheers, C: Bob C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20; Section=1.2 {} C: --------------030308070208000400050907-- C: S: A003 OK [APPENDUID 385759045 45] CATENATE Completed C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted) S: A004 OK STORE completed Here and are lengths of the corresponding literals. Example 3: The following example demonstrates how CATENATE can be used to strip attachments. Below a PowerPoint attachment was replaced by a small text part explaining that the attachment was stripped. C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) {} S: + Ready for literal data C: Return-Path: C: Received: from [127.0.0.2] C: by rufus.example.org via TCP (internal) with ESMTPA; C: Thu, 11 Nov 2004 16:57:07 +0000 C: Message-ID: <419399E1.6000505@example.org> C: Date: Thu, 11 Nov 2004 16:57:05 +0000 C: From: Bob Ar C: X-Accept-Language: en-us, en C: MIME-Version: 1.0 C: To: foo@example.org C: Subject: My presentation C: Content-Type: multipart/mixed; C: boundary="------------030308070208000400050903" C: C: --------------030308070208000400050903 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=21; section=1.1 {} S: + Ready for literal data C: --------------030308070208000400050903 C: Content-type: text/plain; charset="us-ascii" C: Content-transfer-encoding: 7bit C: C: This bodypart contained a Power Point presentation, that was C: deleted upon your request. C: --------------030308070208000400050903-- C: S: A003 OK CATENATE Completed Here and are lengths of the corresponding literals. Example 4: The following example demonstrates a failed CATENATE command. The server returns the BADURL response code to indicate that one of the provided URLs is invalid. This example also demonstrates how CATENATE can be used to construct a digest of several messages. C: A003 CATENATE Sent (\Seen $MDNSent) {} S: + Ready for literal data C: Return-Path: C: Received: from [127.0.0.2] C: by rufus.example.org via TCP (internal) with ESMTPA; C: Thu, 11 Nov 2004 16:57:07 +0000 C: Message-ID: <419399E1.6000505@example.org> C: Date: Thu, 21 Nov 2004 16:57:05 +0000 C: From: Farren Oo C: X-Accept-Language: en-us, en C: MIME-Version: 1.0 C: To: bar@example.org C: Subject: Digest of the mailing list for today C: Content-Type: multipart/digest; C: boundary="------------030308070208000400050904" C: C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=11467 {} S: + Ready for literal data C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=113330; section=1.5.9 {} S: + Ready for literal data C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=11916 {} S: + Ready for literal data C: --------------030308070208000400050904-- C: S: A003 NO [BADURL imap://imap.example.org/INBOX;UIDVALIDITY=785799047/ ;UID=113330;section=1.5.9] CATENATE has failed, one message expunged Here , , and are lengths of the corresponding literals. --------------040905040101070607010205 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --------------040905040101070607010205-- From lemonade-bounces@ietf.org Sun Nov 21 18:59:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06426 for ; Sun, 21 Nov 2004 18:59:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW1fD-0006Sl-Oz for lemonade-web-archive@ietf.org; Sun, 21 Nov 2004 19:02:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW1aO-0007EP-LD; Sun, 21 Nov 2004 18:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW1Z0-00076r-Uu for lemonade@megatron.ietf.org; Sun, 21 Nov 2004 18:56:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06334 for ; Sun, 21 Nov 2004 18:56:12 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW1cL-0006PS-Ui for lemonade@ietf.org; Sun, 21 Nov 2004 18:59:42 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iALNuC28024735; Sun, 21 Nov 2004 15:56:12 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iALNuAtL010977; Sun, 21 Nov 2004 15:56:12 -0800 Date: Sun, 21 Nov 2004 15:56:10 -0800 (PST) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] WGLC's In-Reply-To: <41A11680.6050109@isode.com> Message-ID: References: <41A11680.6050109@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Sun, 21 Nov 2004, Alexey Melnikov wrote: > One more thing. I've noticed that in the URLAUTH documents all URLs are > transferred as quoted strings, > while in CATENATE they transferred as is (MAILBOX-REFERRAL also transfers > them with no surrounding quotes). The usage in CATENATE and MAILBOX-REFERRAL only works as long as IMAP URLs can not contain "]" or spaces. That currently seems to be true; but I don't consider it to be a prudent assumption. By using astring, you don't need to have a separate rule that knows about the syntax of imapurl just to parse the command or its response. I think that CATENATE should use astring as well. MAILBOX-REFERRAL is rarely used, and it's possible with that to use a rule that says "everything up to the ] is the URL. -- 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 From lemonade-bounces@ietf.org Mon Nov 22 06:10:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17361 for ; Mon, 22 Nov 2004 06:10:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWC8y-0004u8-Or for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 06:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWByc-0002MS-PU; Mon, 22 Nov 2004 06:03:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWBwU-00022t-E3 for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 06:01:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16237 for ; Mon, 22 Nov 2004 06:01:05 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWBtL-0003sf-MK for lemonade@ietf.org; Mon, 22 Nov 2004 05:57:56 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 22 Nov 2004 10:53:30 +0000 Message-ID: <41A123DC.10409@isode.com> Date: Sun, 21 Nov 2004 23:25:16 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Cyrus Daboo Subject: Re: CATENATE comments: (was Re: [lemonade] WGLC's) References: <419F61E1.9060600@isode.com> <1E051C70ADF2F93B914589CC@ninevah.local> In-Reply-To: <1E051C70ADF2F93B914589CC@ninevah.local> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > Hi Alexey, > > --On November 20, 2004 15:25:21 +0000 Alexey Melnikov > wrote: > >> 2). I've just realized that the CATENATE extension interacts with >> UIDPLUS >> and the CATENATE command must return APPENDUID if both are >> implemented. I >> suggest addition of the following text: >> >> CATENATE Interaction with UIDPLUS Extension >> >> Servers which support both CATENATE and [UIDPLUS] MUST return the >> APPENDUID response code >> in the tagged OK response of a successful CATENATE command. The >> APPENDUID response code contains as >> arguments the UIDVALIDITY of the destination mailbox and the UID >> assigned to the catenated message. >> The syntax of the APPENDUID response code is described in [UIDPLUS]. > > UIDPLUS is already mentioned in the -02 draft in the paragraph right > before section 4. Oops, I've missed that. One of my examples has the APPENDUID response code. > However, the language there is not as strong as you suggest above, and > perhaps it should be. I suggest at least changing "it will also return an APPENDUID response code in the tagged OK response" to "it MUST return an APPENDUID ..." > It might also be worthwhile explicitly making the point that CATENATE > does not support the MULTIAPPEND extension behaviour, given that so > many other aspects of CATENATE appear to be similar to APPEND. Yes, I was thinking about this too. However I've decided that there is no such thing as MULTICATENATE :-), so nothing has to be said. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 22 06:49:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21333 for ; Mon, 22 Nov 2004 06:49:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWCkS-00070b-8O for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 06:52:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWCfC-0001wJ-E5; Mon, 22 Nov 2004 06:47:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWCaJ-0001Bp-9y for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 06:42:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20597 for ; Mon, 22 Nov 2004 06:42:16 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWCdj-0006cU-9G for lemonade@ietf.org; Mon, 22 Nov 2004 06:45:53 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 22 Nov 2004 11:41:34 +0000 Message-ID: <41A1D06D.3050704@isode.com> Date: Mon, 22 Nov 2004 11:41:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick Subject: Re: [lemonade] Examples for CATENATE References: <41A11FA0.7040104@isode.com> In-Reply-To: <41A11FA0.7040104@isode.com> Content-Type: multipart/mixed; boundary="------------010802050401010002060605" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 --------------010802050401010002060605 Content-type: text/plain; charset="us-ascii" Philip has noticed that there are two minor bugs (missing "S: + Ready for literal data" in a few places.) He also pointed out that there is a way to reference top level headers in an IMAP URL. I've updated the examples. --------------010802050401010002060605 Content-type: text/plain; name="Catenate.Examples&Comments.txt" Content-Disposition: inline; filename="Catenate.Examples&Comments.txt" Content-Transfer-Encoding: 7bit Lines not starting with "C: " or "S: " are continuations of the previous lines. Example 1: The following example demonstrates how a CATENATE client can replace an attachment in a draft message, without the need to download it to the client and upload it back. The original message (UID = 20) has the following structure: multipart/mixed MIME message with two body parts: 1 - text/plain 2 - application/x-zip-compressed C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) imap://imap.example. org/Drafts;UIDVALIDITY=385759045/;UID=20;section=HEADER {} S: + Ready for literal data C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section =1.1 {} S: + Ready for literal data C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=30 {} S: + Ready for literal data C: --------------030308070208000400050907-- C: S: A003 OK CATENATE Completed Here , and are lengths of the corresponding literals. Example 2: The following example demonstrates how CATENATE can be used to replace edited text in a draft message, as well as header fields for the top level message part (e.g. Subject has changed). The previous version of the draft is marked as \Deleted. Note, that the server also supports the UIDPLUS extension, so the APPENDUID response code is returned in the successful OK response to the CATENATE command. C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) {} S: + Ready for literal data C: Return-Path: C: Received: from [127.0.0.2] C: by rufus.example.org via TCP (internal) with ESMTPA; C: Thu, 11 Nov 2004 16:57:07 +0000 C: Message-ID: <419399E1.6000505@example.org> C: Date: Thu, 12 Nov 2004 16:57:05 +0000 C: From: Bob Ar C: X-Accept-Language: en-us, en C: MIME-Version: 1.0 C: To: foo@example.net C: Subject: About our holiday trip C: Content-Type: multipart/mixed; C: boundary="------------030308070208000400050907" C: C: --------------030308070208000400050907 C: Content-Type: text/plain; charset=us-ascii; format=flowed C: Content-Transfer-Encoding: 7bit C: C: Our travel agent has sent the updated schedule. C: C: Cheers, C: Bob C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20; Section=1.2 {} S: + Ready for literal data C: --------------030308070208000400050907-- C: S: A003 OK [APPENDUID 385759045 45] CATENATE Completed C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted) S: A004 OK STORE completed Here and are lengths of the corresponding literals. Example 3: The following example demonstrates how CATENATE can be used to strip attachments. Below a PowerPoint attachment was replaced by a small text part explaining that the attachment was stripped. C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) imap://imap.example .org/Drafts;UIDVALIDITY=385759045/;UID=21;section=HEADER {} S: + Ready for literal data C: --------------030308070208000400050903 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=21; section=1.1 {} S: + Ready for literal data C: --------------030308070208000400050903 C: Content-type: text/plain; charset="us-ascii" C: Content-transfer-encoding: 7bit C: C: This bodypart contained a Power Point presentation, that was C: deleted upon your request. C: --------------030308070208000400050903-- C: S: A003 OK CATENATE Completed Here and are lengths of the corresponding literals. Example 4: The following example demonstrates a failed CATENATE command. The server returns the BADURL response code to indicate that one of the provided URLs is invalid. This example also demonstrates how CATENATE can be used to construct a digest of several messages. C: A003 CATENATE Sent (\Seen $MDNSent) {} S: + Ready for literal data C: Return-Path: C: Received: from [127.0.0.2] C: by rufus.example.org via TCP (internal) with ESMTPA; C: Thu, 11 Nov 2004 16:57:07 +0000 C: Message-ID: <419399E1.6000505@example.org> C: Date: Thu, 21 Nov 2004 16:57:05 +0000 C: From: Farren Oo C: X-Accept-Language: en-us, en C: MIME-Version: 1.0 C: To: bar@example.org C: Subject: Digest of the mailing list for today C: Content-Type: multipart/digest; C: boundary="------------030308070208000400050904" C: C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=11467 {} S: + Ready for literal data C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=113330; section=1.5.9 {} S: + Ready for literal data C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=11916 {} S: + Ready for literal data C: --------------030308070208000400050904-- C: S: A003 NO [BADURL imap://imap.example.org/INBOX;UIDVALIDITY=785799047/ ;UID=113330;section=1.5.9] CATENATE has failed, one message expunged Here , , and are lengths of the corresponding literals. --------------010802050401010002060605 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --------------010802050401010002060605-- From lemonade-bounces@ietf.org Mon Nov 22 11:24:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13416 for ; Mon, 22 Nov 2004 11:24:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWH34-0004Xi-PD for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 11:28:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGrZ-0001yD-Hb; Mon, 22 Nov 2004 11:16:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGqQ-0001ee-Ir for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 11:15:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12628 for ; Mon, 22 Nov 2004 11:15:12 -0500 (EST) Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGtt-00042D-L4 for lemonade@ietf.org; Mon, 22 Nov 2004 11:18:50 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAMGFBgw028194; Mon, 22 Nov 2004 08:15:11 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAMGFBoP030690; Mon, 22 Nov 2004 08:15:11 -0800 Date: Mon, 22 Nov 2004 08:15:11 -0800 (PST) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Examples for CATENATE In-Reply-To: <41A1D06D.3050704@isode.com> Message-ID: References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Alexey - I assume that you are going to replace those "{}" tokens with actual values in the final version, and the is just for convenience until the final form is determined. Otherwise, I object to that. Some fool is certain to send "{}" if he sees it in an example. -- 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 From lemonade-bounces@ietf.org Mon Nov 22 11:38:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15133 for ; Mon, 22 Nov 2004 11:38:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWHGF-0005OE-Hz for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 11:41:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWHAj-0006Bk-Lg; Mon, 22 Nov 2004 11:36:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWH5N-0004f2-Id for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 11:30:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14457 for ; Mon, 22 Nov 2004 11:30:39 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWH8n-0004tk-2Z for lemonade@ietf.org; Mon, 22 Nov 2004 11:34:17 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 22 Nov 2004 16:29:44 +0000 Message-ID: <41A213F5.1010809@isode.com> Date: Mon, 22 Nov 2004 16:29:41 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] Examples for CATENATE References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Mark Crispin wrote: > Alexey - > > I assume that you are going to replace those "{}" tokens with > actual values in the final version, and the is just for > convenience until the final form is determined. There is a note after each example: Here , and are lengths of the corresponding literals. > > Otherwise, I object to that. Some fool is certain to send "{}" if > he sees it in an example. And it will fail. I would hope that people at least test what they write. Do you really want me to calculate proper lengths? I was trying to avoid this. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 22 13:06:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27670 for ; Mon, 22 Nov 2004 13:06:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIdO-0006OS-Qc for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 13:09:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIQM-00042t-MR; Mon, 22 Nov 2004 12:56:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIJ5-0002ID-AC for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 12:48:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26319 for ; Mon, 22 Nov 2004 12:48:52 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIMZ-0004dA-BY for lemonade@ietf.org; Mon, 22 Nov 2004 12:52:32 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 22 Nov 2004 17:48:13 +0000 Message-ID: <41A2265C.6040905@isode.com> Date: Mon, 22 Nov 2004 17:48:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick Subject: Re: [lemonade] Examples for CATENATE References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@isode.com> <41A213F5.1010809@isode.com> In-Reply-To: <41A213F5.1010809@isode.com> Content-Type: multipart/mixed; boundary="------------050507040609010000040909" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 --------------050507040609010000040909 Content-type: text/plain; charset="us-ascii" By popular demand: examples with the proper literal sizes. --------------050507040609010000040909 Content-type: text/plain; name="Catenate.Examples&Comments.txt" Content-Disposition: inline; filename="Catenate.Examples&Comments.txt" Content-Transfer-Encoding: 7bit Lines not starting with "C: " or "S: " are continuations of the previous lines. Example 1: The following example demonstrates how a CATENATE client can replace an attachment in a draft message, without the need to download it to the client and upload it back. The original message (UID = 20) has the following structure: multipart/mixed MIME message with two body parts: 1 - text/plain 2 - application/x-zip-compressed C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) imap://imap.example. org/Drafts;UIDVALIDITY=385759045/;UID=20;section=HEADER {40} S: + Ready for literal data C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section =1.1 {40} S: + Ready for literal data C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=30 {44} S: + Ready for literal data C: --------------030308070208000400050907-- C: S: A003 OK CATENATE Completed Example 2: The following example demonstrates how CATENATE can be used to replace edited text in a draft message, as well as header fields for the top level message part (e.g. Subject has changed). The previous version of the draft is marked as \Deleted. Note, that the server also supports the UIDPLUS extension, so the APPENDUID response code is returned in the successful OK response to the CATENATE command. C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) {738} S: + Ready for literal data C: Return-Path: C: Received: from [127.0.0.2] C: by rufus.example.org via TCP (internal) with ESMTPA; C: Thu, 11 Nov 2004 16:57:07 +0000 C: Message-ID: <419399E1.6000505@example.org> C: Date: Thu, 12 Nov 2004 16:57:05 +0000 C: From: Bob Ar C: X-Accept-Language: en-us, en C: MIME-Version: 1.0 C: To: foo@example.net C: Subject: About our holiday trip C: Content-Type: multipart/mixed; C: boundary="------------030308070208000400050907" C: C: --------------030308070208000400050907 C: Content-Type: text/plain; charset=us-ascii; format=flowed C: Content-Transfer-Encoding: 7bit C: C: Our travel agent has sent the updated schedule. C: C: Cheers, C: Bob C: --------------030308070208000400050907 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20; Section=1.2 {44} S: + Ready for literal data C: --------------030308070208000400050907-- C: S: A003 OK [APPENDUID 385759045 45] CATENATE Completed C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted) S: A004 OK STORE completed Example 3: The following example demonstrates how CATENATE can be used to strip attachments. Below a PowerPoint attachment was replaced by a small text part explaining that the attachment was stripped. C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) imap://imap.example .org/Drafts;UIDVALIDITY=385759045/;UID=21;section=HEADER {40} S: + Ready for literal data C: --------------030308070208000400050903 C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=21; section=1.1 {255} S: + Ready for literal data C: --------------030308070208000400050903 C: Content-type: text/plain; charset="us-ascii" C: Content-transfer-encoding: 7bit C: C: This bodypart contained a Power Point presentation, that was C: deleted upon your request. C: --------------030308070208000400050903-- C: S: A003 OK CATENATE Completed Example 4: The following example demonstrates a failed CATENATE command. The server returns the BADURL response code to indicate that one of the provided URLs is invalid. This example also demonstrates how CATENATE can be used to construct a digest of several messages. C: A003 CATENATE Sent (\Seen $MDNSent) {541} S: + Ready for literal data C: Return-Path: C: Received: from [127.0.0.2] C: by rufus.example.org via TCP (internal) with ESMTPA; C: Thu, 11 Nov 2004 16:57:07 +0000 C: Message-ID: <419399E1.6000505@example.org> C: Date: Thu, 21 Nov 2004 16:57:05 +0000 C: From: Farren Oo C: X-Accept-Language: en-us, en C: MIME-Version: 1.0 C: To: bar@example.org C: Subject: Digest of the mailing list for today C: Content-Type: multipart/digest; C: boundary="------------030308070208000400050904" C: C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=11467 {40} S: + Ready for literal data C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=113330; section=1.5.9 {40} S: + Ready for literal data C: --------------030308070208000400050904 C: imap://imap.example.org/INBOX;UIDVALIDITY=785799047/;UID=11916 {44} S: + Ready for literal data C: --------------030308070208000400050904-- C: S: A003 NO [BADURL imap://imap.example.org/INBOX;UIDVALIDITY=785799047/ ;UID=113330;section=1.5.9] CATENATE has failed, one message expunged --------------050507040609010000040909 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --------------050507040609010000040909-- From lemonade-bounces@ietf.org Mon Nov 22 13:15:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28535 for ; Mon, 22 Nov 2004 13:15:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWImK-0007c1-3H for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 13:19:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIci-00065K-DF; Mon, 22 Nov 2004 13:09:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIWx-0004xX-A2 for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 13:03:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27481 for ; Mon, 22 Nov 2004 13:03:12 -0500 (EST) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIaR-0006Fw-K5 for lemonade@ietf.org; Mon, 22 Nov 2004 13:06:52 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAMI3A9s022980; Mon, 22 Nov 2004 10:03:10 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAMI39xP003215; Mon, 22 Nov 2004 10:03:10 -0800 Date: Mon, 22 Nov 2004 10:03:09 -0800 (PST) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Examples for CATENATE In-Reply-To: <41A213F5.1010809@isode.com> Message-ID: References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@isode.com> <41A213F5.1010809@isode.com> 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 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Mon, 22 Nov 2004, Alexey Melnikov wrote: >> Otherwise, I object to that. Some fool is certain to send "{}" if he >> sees it in an example. > And it will fail. I would hope that people at least test what they write. My friend, I'm afraid that you are too optimistic... :-( > Do you really want me to calculate proper lengths? I was trying to avoid > this. Yes, I do. Thanks. -- 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 From lemonade-bounces@ietf.org Mon Nov 22 13:53:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02220 for ; Mon, 22 Nov 2004 13:53:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJMk-0003Pz-A2 for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 13:56:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJC6-0004qU-PE; Mon, 22 Nov 2004 13:45:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJ2k-0003WM-7V for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 13:36:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00874 for ; Mon, 22 Nov 2004 13:36:05 -0500 (EST) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJ6F-0001Qn-4L for lemonade@ietf.org; Mon, 22 Nov 2004 13:39:43 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAMIa4Yu031038; Mon, 22 Nov 2004 10:36:04 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAMIa323005243; Mon, 22 Nov 2004 10:36:04 -0800 Date: Mon, 22 Nov 2004 10:36:03 -0800 (PST) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Examples for CATENATE In-Reply-To: <41A2265C.6040905@isode.com> Message-ID: References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@isode.com> <41A213F5.1010809@isode.com> <41A2265C.6040905@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Mon, 22 Nov 2004, Alexey Melnikov wrote: > By popular demand: examples with the proper literal sizes. TNX 1.0E6 (thanks a million)!!! By the way, those are good examples. -- 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 From lemonade-bounces@ietf.org Mon Nov 22 17:20:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28270 for ; Mon, 22 Nov 2004 17:20:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMb6-0006mJ-Er for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 17:23:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMI3-0004AV-KK; Mon, 22 Nov 2004 17:04:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMDH-00024E-GH for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 16:59:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26444 for ; Mon, 22 Nov 2004 16:59:09 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMGo-0003uQ-Dt for lemonade@ietf.org; Mon, 22 Nov 2004 17:02:50 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAMLx7at006924 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 22 Nov 2004 13:59:07 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAMLx7at006924 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=f/cG0EwikZWN1g2VcU1ZBXSGvZztRQcXaDFqonz60pvQc51DNSrOzS+hnLTE2p9eZ WILjmnCnUL0tuD2bTVBFPwnHOdFOw3Qfe9azQWXbo0VqZFavHFuOh4LxXWDEFs21yn0 eCTnFhow082QuKDZMnmgSMrB/2/+ItRsfAzx814= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAMLx792084533 for ; Mon, 22 Nov 2004 13:59:07 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411222159.iAMLx792084533@lab.smi.sendmail.com> To: lemonade@ietf.org From: Philip Guenther Date: Mon, 22 Nov 2004 13:59:07 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [lemonade] partial fetches with IMAP URLs? 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab IMAP URLs, like HTTP URLs, do not provide a syntax for specifying a specific byte-range of the indicated object, even though the underlying protocol does. Should URLFETCH provide a way to do partial fetches? How about BURL or CATENATE? My gut reaction is that partial fetches wouldn't be useful enough with CATENATE or BURL to be worth adding them there, but that it may be useful for URLFETCH to support them for the same reasons that HTTP supports byte-range retrieval (restarting of interrupted retrievals, efficient random access to large objects, etc). Yes, adding a syntax for partial fetches to URLFETCH but not BURL or CATENATE would make them basically irrelevant to the lemonade forward-without-download profile. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 22 17:21:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28340 for ; Mon, 22 Nov 2004 17:21:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMc3-0006no-8s for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 17:24:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMWE-0006cu-2L; Mon, 22 Nov 2004 17:18:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMGc-0003i6-La for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 17:02:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26882 for ; Mon, 22 Nov 2004 17:02:36 -0500 (EST) Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMK9-0004NH-Gk for lemonade@ietf.org; Mon, 22 Nov 2004 17:06:18 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAMM2aRs010981 for ; Mon, 22 Nov 2004 14:02:36 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAMM2Zon003858 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 22 Nov 2004 14:02:35 -0800 Date: Mon, 22 Nov 2004 14:00:34 -0800 (Pacific Standard Time) From: Mark Crispin To: lemonade@ietf.org Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [lemonade] comments on draft-ietf-lemonade-urlauth-04.txt (fwd) 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 I have received the following comments on draft 04. Unless there is an objection in the next day or two, I propose to act affirmatively on all of these comments and produce a draft 05. I do not think that any of these changes invalidate the WGLC on 04. In my opinion, they are all minor, fall into the category of clarification, and will result in a superior document. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ---------- Forwarded message ---------- The examples that have wrapped lines would be easier to read if the continued lines were indented past the leading "C: " or "S: ". The blurb about continuations at the start of the GENURLAUTH and URLFETCH examples should be removed now that that is mentioned in the 'conventions' section. Shouldn't both RESETKEY and GENURLAUTH require that the user be able to access the mailbox named in the command or URL? Should the server check whether the indicated message both exists and has the indicated part? I think servers should be required to automatically generate a key the first time a user uses GENURLAUTH on a mailbox. That is, a server MUST NOT require a client to use RESETKEY before GENURLAUTH. RESETKEY should only be used by clients for revocation, otherwise clients may unintentionally break each other's URLs. The word "examine" at the end of the first paragraph of BASE.6.3.URLFETCH should be capitalized. The authuser/anonymous text bits look good to me, but I never really understood why generated such a furor. The second line of the syntax for 'access' should be indented further. I think the syntax for mechanism is more liberal than desired: uchar includes parens, asterisk, and URL %-escape sequences, none of which are permitted in the IMAP atom syntax. I suspect mechanism names should be restricted to something like 1*(alpha / digit / safe), though maybe they should have different syntax in URLs vs IMAP? The IANA Considerations section needs to request registration of URLAUTH in the imap4-capabilities registry. There should also be a statement somewhere that the names of URLAUTH authorization mechanisms are case-insensitive. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 22 19:37:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11958 for ; Mon, 22 Nov 2004 19:37:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOjq-0008JP-UV for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 19:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOdq-0001xQ-H4; Mon, 22 Nov 2004 19:34:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOTd-0008WN-4V for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 19:24:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10630 for ; Mon, 22 Nov 2004 19:24:10 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOXB-0006g3-Cw for lemonade@ietf.org; Mon, 22 Nov 2004 19:27:53 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iAN0HRGn018711; Mon, 22 Nov 2004 19:17:29 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Nov 2004 19:14:26 -0500 Message-ID: From: Eric Burger To: Mark Crispin Subject: RE: [lemonade] comments on draft-ietf-lemonade-urlauth-04.txt (fw d) Date: Mon, 22 Nov 2004 19:14:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 As these are all editorial, I would hold off on -05 until after WGLC closes, you can get any and all comments in one update. > -----Original Message----- > From: Mark Crispin [mailto:MRC@CAC.Washington.EDU] > Sent: Monday, November 22, 2004 5:01 PM > To: lemonade@ietf.org > Subject: [lemonade] comments on > draft-ietf-lemonade-urlauth-04.txt (fwd) > > > I have received the following comments on draft 04. Unless > there is an > objection in the next day or two, I propose to act > affirmatively on all of > these comments and produce a draft 05. > > I do not think that any of these changes invalidate the WGLC > on 04. In my > opinion, they are all minor, fall into the category of > clarification, and > will result in a superior document. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > > ---------- Forwarded message ---------- > > The examples that have wrapped lines would be easier to read if the > continued lines were indented past the leading "C: " or "S: ". The > blurb about continuations at the start of the GENURLAUTH and URLFETCH > examples should be removed now that that is mentioned in the > 'conventions' section. > > Shouldn't both RESETKEY and GENURLAUTH require that the user be > able to access the mailbox named in the command or URL? Should the > server check whether the indicated message both exists and has the > indicated part? > > I think servers should be required to automatically generate a key > the first time a user uses GENURLAUTH on a mailbox. That is, a > server MUST NOT require a client to use RESETKEY before GENURLAUTH. > RESETKEY should only be used by clients for revocation, otherwise > clients may unintentionally break each other's URLs. > > The word "examine" at the end of the first paragraph of > BASE.6.3.URLFETCH > should be capitalized. > > The authuser/anonymous text bits look good to me, but I never really > understood why generated such a furor. > > The second line of the syntax for 'access' should be indented further. > > I think the syntax for mechanism is more liberal than desired: uchar > includes parens, asterisk, and URL %-escape sequences, none of which > are permitted in the IMAP atom syntax. I suspect mechanism names > should be restricted to something like 1*(alpha / digit / safe), > though maybe they should have different syntax in URLs vs IMAP? > > The IANA Considerations section needs to request registration of > URLAUTH in the imap4-capabilities registry. There should also be > a statement somewhere that the names of URLAUTH authorization > mechanisms are case-insensitive. > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 22 19:38:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12212 for ; Mon, 22 Nov 2004 19:38:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOlO-0000F4-JF for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 19:42:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOes-0002ba-IR; Mon, 22 Nov 2004 19:35:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOWT-0000Kh-9Y for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 19:27:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10810 for ; Mon, 22 Nov 2004 19:27:06 -0500 (EST) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOa0-0006nw-Gg for lemonade@ietf.org; Mon, 22 Nov 2004 19:30:49 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAN0R5ws016397; Mon, 22 Nov 2004 16:27:05 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAN0R4vx009036 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Nov 2004 16:27:05 -0800 Date: Mon, 22 Nov 2004 16:25:03 -0800 (Pacific Standard Time) From: Mark Crispin To: Eric Burger Subject: RE: [lemonade] comments on draft-ietf-lemonade-urlauth-04.txt (fw d) In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Mon, 22 Nov 2004, Eric Burger wrote: > As these are all editorial, I would hold off on -05 until after WGLC closes, > you can get any and all comments in one update. Roger wilco!! :-) -- 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 From lemonade-bounces@ietf.org Mon Nov 22 21:56:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23172 for ; Mon, 22 Nov 2004 21:56:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWQuZ-0001jt-FY for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 22:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWQoe-0005di-HY; Mon, 22 Nov 2004 21:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWQn1-0005OR-TT for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 21:52:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22783 for ; Mon, 22 Nov 2004 21:52:22 -0500 (EST) 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.33) id 1CWQqQ-0000xz-Om for lemonade@ietf.org; Mon, 22 Nov 2004 21:56:06 -0500 Received: from [130.129.135.164] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Mon, 22 Nov 2004 20:51:39 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: <41A11680.6050109@isode.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Mon, 22 Nov 2004 20:51:34 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On 11/21/04 at 3:56 PM -0800, Mark Crispin wrote: >On Sun, 21 Nov 2004, Alexey Melnikov wrote: >>One more thing. I've noticed that in the URLAUTH documents all URLs >>are transferred as quoted strings, while in CATENATE they >>transferred as is (MAILBOX-REFERRAL also transfers them with no >>surrounding quotes). > >The usage in CATENATE and MAILBOX-REFERRAL only works as long as >IMAP URLs can not contain "]" or spaces. That currently seems to be >true; but I don't consider it to be a prudent assumption. > >By using astring, you don't need to have a separate rule that knows >about the syntax of imapurl just to parse the command or its >response. > >I think that CATENATE should use astring as well. With responses, I agree that astring is definitely a better way to go. There's no reason to start parsing URLs in reponses. But in the command itself, I'm a bit nervous. Folks who make e-mail clients (let alone web browsers) screw up URL quoting conventions and literals all over the place. (How many times have you seen & or %hh where they didn't belong?) In the command, you're going to have to parse the URL anyway, and I'd worry that backslashes are going to make their way into the URL parser if we use astring. Also, if we put astring in the CATENATE syntax, it's only going to be a textual reference to IMAPURL. I'm not saying we absolutely shouldn't use astring, but it does make me worry a bit. I'd like some input from other folks before I change the syntax. -- 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 From lemonade-bounces@ietf.org Mon Nov 22 21:59:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23367 for ; Mon, 22 Nov 2004 21:59:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWQxZ-00028s-Rg for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 22:03:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWQs9-0006I3-DY; Mon, 22 Nov 2004 21:57:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWQol-0005gV-MS for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 21:54:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22905 for ; Mon, 22 Nov 2004 21:54:10 -0500 (EST) 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.33) id 1CWQsK-0001LM-NG for lemonade@ietf.org; Mon, 22 Nov 2004 21:57:54 -0500 Received: from [130.129.135.164] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Mon, 22 Nov 2004 20:53:39 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <41A2265C.6040905@isode.com> References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@isode.com> <41A213F5.1010809@isode.com> <41A2265C.6040905@isode.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Mon, 22 Nov 2004 20:53:36 -0600 To: Alexey Melnikov From: Pete Resnick Subject: Re: [lemonade] Examples for CATENATE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On 11/22/04 at 5:48 PM +0000, Alexey Melnikov wrote: > C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) imap://imap.example. > org/Drafts;UIDVALIDITY=385759045/;UID=20;section=HEADER {40} > S: + Ready for literal data > C: --------------030308070208000400050907 > C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section > =1.1 {40} > S: + Ready for literal data > C: --------------030308070208000400050907 > C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=30 {44} > S: + Ready for literal data > C: --------------030308070208000400050907-- > C: > S: A003 OK CATENATE Completed Is the space before each URL required? 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 From lemonade-bounces@ietf.org Mon Nov 22 22:24:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04469 for ; Mon, 22 Nov 2004 22:24:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRLM-0005HJ-Od for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 22:27:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRD9-0001ze-Fs; Mon, 22 Nov 2004 22:19:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWR9a-0001Lw-ET for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 22:15:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29594 for ; Mon, 22 Nov 2004 22:15:40 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRDA-00047q-Bb for lemonade@ietf.org; Mon, 22 Nov 2004 22:19:24 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAN3FZFA025728; Mon, 22 Nov 2004 19:15:35 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAN3FZDw012243 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Nov 2004 19:15:35 -0800 Date: Mon, 22 Nov 2004 19:15:50 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Resnick Subject: Re: [lemonade] WGLC's In-Reply-To: Message-ID: References: <41A11680.6050109@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 On Mon, 22 Nov 2004, Pete Resnick wrote: > With responses, I agree that astring is definitely a better way to go. > There's no reason to start parsing URLs in reponses. But in the command > itself, I'm a bit nervous. Folks who make e-mail clients (let alone web > browsers) screw up URL quoting conventions and literals all over the place. Understood. But this is IMAP quoting, not URL quoting. > In the > command, you're going to have to parse the URL anyway, Aye, there's the rub. *Something* has to parse the URL. It may not necessarily be the IMAP server; it may be a separate engine that the IMAP server asks to resolve the URL. I very much do not want to add a URL parser to my IMAP server engine. > and I'd worry that > backslashes are going to make their way into the URL parser if we use > astring. I think that this is unlikely, considering the RFC 3501 rules that say that the only time you can have a backslash is <\"> for <"> and <\\> for <\>. Unlike RFC [2]822, backslash is not a general quoting mechanism in IMAP, so "foo\bar" is a syntax error. > Also, if we put astring in the CATENATE syntax, it's only going to > be a textual reference to IMAPURL. No, you'd use the syntax rule in IMAP. Or do I misunderstand what you're saying here? > I'm not saying we absolutely shouldn't use astring, but it does make me worry > a bit. I'd like some input from other folks before I change the syntax. I'm worried about a future in which CATENATE allows other URIs besides IMAP URLs, and those URIs have syntax which can be confused with other IMAP syntax. An alternate solution is to define the URL argument to CATENATE as an atom, e.g. catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] 1*(SP (literal / url)) url = atom ; contains imapurl as defined in [IMAPURL] and extended ; by [URLAUTH] This only works if we can guarantee that url will never have any of these characters: ( ) { * % ] " \ SP CTL That's right -- } and [ are valid atom characters in IMAP! Anyway, I think that % is going to be a problem here. My proposal is similar: catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] 1*(SP (literal / url)) url = astring ; contains imapurl as defined in [IMAPURL] and extended ; by [URLAUTH] The difference is that the server must handle a quoted string and a literal, and of course a client can send such if it needs to send a non-atom character. -- 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 From lemonade-bounces@ietf.org Mon Nov 22 22:37:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07530 for ; Mon, 22 Nov 2004 22:37:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRY8-0006yH-OK for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 22:41:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRTw-0005TN-0T; Mon, 22 Nov 2004 22:36:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRLY-0003yN-3O for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 22:28:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06354 for ; Mon, 22 Nov 2004 22:28:02 -0500 (EST) 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.33) id 1CWRP7-0005g2-PW for lemonade@ietf.org; Mon, 22 Nov 2004 22:31:47 -0500 Received: from [130.129.135.164] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Mon, 22 Nov 2004 21:27:28 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@isode.com> <41A213F5.1010809@isode.com> <41A2265C.6040905@isode.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Mon, 22 Nov 2004 21:27:25 -0600 To: Alexey Melnikov From: Pete Resnick Subject: Re: [lemonade] Examples for CATENATE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Uh, nevermind. Brain blip. Of course the space is required. On 11/22/04 at 8:53 PM -0600, Pete Resnick wrote: >On 11/22/04 at 5:48 PM +0000, Alexey Melnikov wrote: > >> C: A003 CATENATE Drafts (\Seen \Draft $MDNSent) imap://imap.example. >> org/Drafts;UIDVALIDITY=385759045/;UID=20;section=HEADER {40} >> S: + Ready for literal data >> C: --------------030308070208000400050907 >> C: >>imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section >> =1.1 {40} >> S: + Ready for literal data >> C: --------------030308070208000400050907 >> C: imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=30 {44} >> S: + Ready for literal data >> C: --------------030308070208000400050907-- >> C: >> S: A003 OK CATENATE Completed > >Is the space before each URL required? > >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 From lemonade-bounces@ietf.org Mon Nov 22 22:38:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07653 for ; Mon, 22 Nov 2004 22:38:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRZe-0007Kv-IM for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 22:42:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRTx-0005TY-BS; Mon, 22 Nov 2004 22:36:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRLt-00048O-AC for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 22:28:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06402 for ; Mon, 22 Nov 2004 22:28:23 -0500 (EST) Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRPT-0005hX-HF for lemonade@ietf.org; Mon, 22 Nov 2004 22:32:08 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAN3SMBI001016; Mon, 22 Nov 2004 19:28:22 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAN3SMVW023945 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Nov 2004 19:28:22 -0800 Date: Mon, 22 Nov 2004 19:28:39 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Resnick Subject: Re: [lemonade] Examples for CATENATE In-Reply-To: Message-ID: References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@isode.com> <41A213F5.1010809@isode.com> <41A2265C.6040905@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Mon, 22 Nov 2004, Pete Resnick wrote: > Is the space before each URL required? Yes. Arguments are space-delimited, not only in IMAP but also in CATENATE. If you want to remove the space, you would have to do two things: First, you need to change: catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] 1*(SP (literal / imapurl)) to something like: catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] SP *argument (imapurl / literal) argument = (imapurl SP) / literal Second, you'd have to pry consent from my cold dead hands..... :-) -- 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 From lemonade-bounces@ietf.org Mon Nov 22 22:52:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08871 for ; Mon, 22 Nov 2004 22:52:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRmY-0000XI-K1 for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 22:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRhi-0000r4-3i; Mon, 22 Nov 2004 22:50:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRdT-0008IA-Ll for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 22:46:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08219 for ; Mon, 22 Nov 2004 22:46:33 -0500 (EST) 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.33) id 1CWRh2-000882-U8 for lemonade@ietf.org; Mon, 22 Nov 2004 22:50:18 -0500 Received: from [130.129.135.164] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Mon, 22 Nov 2004 21:46:03 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200411222159.iAMLx792084533@lab.smi.sendmail.com> References: <200411222159.iAMLx792084533@lab.smi.sendmail.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Mon, 22 Nov 2004 21:45:59 -0600 To: Philip Guenther From: Pete Resnick Subject: Re: [lemonade] partial fetches with IMAP URLs? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On 11/22/04 at 1:59 PM -0800, Philip Guenther wrote: >IMAP URLs, like HTTP URLs, do not provide a syntax for specifying a >specific byte-range of the indicated object, even though the >underlying protocol does. Should URLFETCH provide a way to do >partial fetches? How about BURL or CATENATE? There was discussion not too long ago that IMAPURL needed to be updated anyway. Adding byte-ranges to the URL would get them into URLFETCH, BURL, and CATENATE by reference automatically. (I think I had offered to pick up that token, but I thought Mark or someone else wanted it instead. Who's got the token on IMAPURL-bis?) pr1 -- 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 From lemonade-bounces@ietf.org Mon Nov 22 22:55:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09183 for ; Mon, 22 Nov 2004 22:55:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRpw-0001G4-95 for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 22:59:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRi3-00012W-VN; Mon, 22 Nov 2004 22:51:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRe9-00004s-Cc for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 22:47:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08330 for ; Mon, 22 Nov 2004 22:47:15 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRhi-0008VV-H1 for lemonade@ietf.org; Mon, 22 Nov 2004 22:50:59 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAN3lB9j022863 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 22 Nov 2004 19:47:11 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAN3lB9j022863 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=Vm0bNiWkpIUd+5zLZ6YmL6i9IdwcV2dmm65+U8v/7t1sksIdlS9nvWymQU0Vg8O1M 0E5JKJbaVWzX9P5FXwh8AR2QwJ4Ww1+YZR6lofj32e9EADdES/MQW17NLcb1rBZQldE izvi7UyO+wEpEiMtUFDL3YyfAnOXbJa+C8uy5Rc= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAN3lBlp009951; Mon, 22 Nov 2004 19:47:11 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> To: Mark Crispin From: Philip Guenther Subject: Re: [lemonade] WGLC's In-reply-to: References: <41A11680.6050109@isode.com> Date: Mon, 22 Nov 2004 19:47:11 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Mark Crispin writes: ... >> Also, if we put astring in the CATENATE syntax, it's only going to >> be a textual reference to IMAPURL. > >No, you'd use the syntax rule in IMAP. Or do I misunderstand what you're >saying here? He's saying that the CATENATE syntax would no longer make direct reference to a production from the IMAP-URL syntax. >> I'm not saying we absolutely shouldn't use astring, but it does make >> me worry a bit. I'd like some input from other folks before I change >> the syntax. Can't use plain 'astring', as that would make the grammar ambiguous: is a literal an imapurl or just text to include? >An alternate solution is to define the URL argument to CATENATE as an >atom, e.g. ... >This only works if we can guarantee that url will never have any of these >characters: > ( ) { * % ] " \ SP CTL > >That's right -- } and [ are valid atom characters in IMAP! Anyway, I >think that % is going to be a problem here. Very much so: it would exclude all i18d mailbox names. >My proposal is similar: > > catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] > 1*(SP (literal / url)) > > url = astring > ; contains imapurl as defined in [IMAPURL] and extended > ; by [URLAUTH] This is ambiguous. I suppose url could be defined as 'quoted / atom', so that literals would be text to include while quoted or atoms would be URLs, but that's kinda gross. Perhaps URL arguments to CATENATE should be preceeded by a known atom, say: catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] 1*(SP (literal / "URL" url)) url = astring ; contains imapurl as defined in [IMAPURL] and extended ; by [URLAUTH] Then it could be later expanded to support URNs and URIs too! Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 22 23:01:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09688 for ; Mon, 22 Nov 2004 23:01:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRv8-0001jn-5H for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 23:04:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRpJ-0002UA-R0; Mon, 22 Nov 2004 22:58:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRkY-0001Q7-PD for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 22:53:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09005 for ; Mon, 22 Nov 2004 22:53:52 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRo8-0000u4-QK for lemonade@ietf.org; Mon, 22 Nov 2004 22:57:37 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAN3rqVO028652; Mon, 22 Nov 2004 19:53:52 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAN3rq8U025247 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Nov 2004 19:53:52 -0800 Date: Mon, 22 Nov 2004 19:54:13 -0800 (Pacific Standard Time) From: Mark Crispin To: Philip Guenther Subject: Re: [lemonade] WGLC's In-Reply-To: <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> Message-ID: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Mon, 22 Nov 2004, Philip Guenther wrote: > catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] > 1*(SP (literal / "URL" url)) > > url = astring > ; contains imapurl as defined in [IMAPURL] and extended > ; by [URLAUTH] I like this. Unambiguous syntax, nicely extensible, and less reliance upon magic. I am not proud of the syntax of APPEND. -- 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 From lemonade-bounces@ietf.org Mon Nov 22 23:04:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10081 for ; Mon, 22 Nov 2004 23:04:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRy7-0002AA-00 for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 23:07:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRqo-00032U-MR; Mon, 22 Nov 2004 23:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRmZ-0001sQ-6y for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 22:55:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09221 for ; Mon, 22 Nov 2004 22:55:57 -0500 (EST) Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRq8-0001HX-FD for lemonade@ietf.org; Mon, 22 Nov 2004 22:59:41 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAN3tuFO003189; Mon, 22 Nov 2004 19:55:56 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAN3tu2u013986 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Nov 2004 19:55:56 -0800 Date: Mon, 22 Nov 2004 19:56:17 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Resnick Subject: Re: [lemonade] partial fetches with IMAP URLs? In-Reply-To: Message-ID: References: <200411222159.iAMLx792084533@lab.smi.sendmail.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Philip Guenther , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Mon, 22 Nov 2004, Pete Resnick wrote: > There was discussion not too long ago that IMAPURL needed to be updated > anyway. Adding byte-ranges to the URL would get them into URLFETCH, BURL, and > CATENATE by reference automatically. Actually, not; since the byte-range would be determined by whatever entity generated the URL, whereas the need is for the entity that is fetching the data. Not to belittle the idea of adding byte ranges to IMAP URLs, or for generator-determined byte ranges. But that solution won't solve this need. > (I think I had offered to pick up that token, but I thought Mark or someone > else wanted it instead. Who's got the token on IMAPURL-bis?) I don't have it. -- 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 From lemonade-bounces@ietf.org Mon Nov 22 23:31:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12301 for ; Mon, 22 Nov 2004 23:31:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWSOY-0005f0-Mn for lemonade-web-archive@ietf.org; Mon, 22 Nov 2004 23:35:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWSJr-0000qL-FQ; Mon, 22 Nov 2004 23:30:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWSI5-0000QF-F8 for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 23:28:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12042 for ; Mon, 22 Nov 2004 23:28:31 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWSLe-0005Hb-OP for lemonade@ietf.org; Mon, 22 Nov 2004 23:32:16 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAN4SU5b001083 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 22 Nov 2004 20:28:30 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAN4SU5b001083 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=dFwVrseocABZPBfy9eAkdVpctJqCEX65UGbpeM9bLjDWZhgzhCpV6b+BrBYlTST/+ bbdNpggsoCHlmiLmTfn+1yxFs5t2+ZcT/AfqSdaWkA/Nev3Z+7KC80p4fR839GpZqxD Ps8AZue49n4bDPwhe70BKldkU1EeBh7qv0cJ6N0= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAN4SUqF012564; Mon, 22 Nov 2004 20:28:30 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411230428.iAN4SUqF012564@lab.smi.sendmail.com> To: Pete Resnick From: Philip Guenther Subject: Re: [lemonade] partial fetches with IMAP URLs? In-reply-to: References: <200411222159.iAMLx792084533@lab.smi.sendmail.com> Date: Mon, 22 Nov 2004 20:28:30 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Pete Resnick writes: >On 11/22/04 at 1:59 PM -0800, Philip Guenther wrote: >>IMAP URLs, like HTTP URLs, do not provide a syntax for specifying a >>specific byte-range of the indicated object, even though the >>underlying protocol does. Should URLFETCH provide a way to do >>partial fetches? How about BURL or CATENATE? > >There was discussion not too long ago that IMAPURL needed to be >updated anyway. Adding byte-ranges to the URL would get them into >URLFETCH, BURL, and CATENATE by reference automatically. While this makes sense, I'm a bit concerned by the http precedent: HTTP-the-protocol support sub-ranges retrieval, why doesn't http-the-schema? Is it because HTTP has difficulty with mutable resources, as seen in the rules around validators and sub-range requests? If so, then adding byte-range syntax to the imap schema should be fine, at least when a UIDVALIDITY is also specified, as IMAP provides strong immutability guarantees in that case. Are there any existing schemata that define byte-range (subobject?) access whose example the imap schema could follow Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 09:27:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13639 for ; Tue, 23 Nov 2004 09:27:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbh5-0007xU-7Q for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 09:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbX4-0005NP-Uy; Tue, 23 Nov 2004 09:20:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbLr-0003Q7-8u for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 09:09:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12565 for ; Tue, 23 Nov 2004 09:09:00 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbPU-0005aP-2g for lemonade@ietf.org; Tue, 23 Nov 2004 09:12:50 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 23 Nov 2004 14:07:50 +0000 Message-ID: <41A34434.9080601@isode.com> Date: Tue, 23 Nov 2004 14:07:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Philip Guenther Subject: Re: [lemonade] WGLC's References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Mark Crispin , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Mark Crispin wrote: > On Mon, 22 Nov 2004, Philip Guenther wrote: > >> catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] >> 1*(SP (literal / "URL" url)) >> >> url = astring >> ; contains imapurl as defined in [IMAPURL] and extended >> ; by [URLAUTH] > > I like this. Unambiguous syntax, nicely extensible, and less reliance > upon magic. I am not proud of the syntax of APPEND. Do you really mean something like: URL"imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20" or is there a space missing? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 09:37:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14490 for ; Tue, 23 Nov 2004 09:37:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbr3-0000kU-Qs for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 09:41:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbcs-0006m5-0x; Tue, 23 Nov 2004 09:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbNp-0003iT-2m for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 09:11:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12753 for ; Tue, 23 Nov 2004 09:11:02 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbRS-0005ed-GR for lemonade@ietf.org; Tue, 23 Nov 2004 09:14:53 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 23 Nov 2004 14:10:20 +0000 Message-ID: <41A344CB.10304@isode.com> Date: Tue, 23 Nov 2004 14:10:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Pete Resnick Subject: Re: [lemonade] partial fetches with IMAP URLs? References: <200411222159.iAMLx792084533@lab.smi.sendmail.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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Philip Guenther , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Pete Resnick wrote: > On 11/22/04 at 1:59 PM -0800, Philip Guenther wrote: > >> IMAP URLs, like HTTP URLs, do not provide a syntax for specifying a >> specific byte-range of the indicated object, even though the >> underlying protocol does. Should URLFETCH provide a way to do >> partial fetches? How about BURL or CATENATE? > > There was discussion not too long ago that IMAPURL needed to be > updated anyway. Adding byte-ranges to the URL would get them into > URLFETCH, BURL, and CATENATE by reference automatically. Yes, exactly my thoughts. > (I think I had offered to pick up that token, but I thought Mark or > someone else wanted it instead. Who's got the token on IMAPURL-bis?) I've offered to take this one recently. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 09:58:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17069 for ; Tue, 23 Nov 2004 09:58:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcBZ-0003zm-9H for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 10:02:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbuP-0003NS-LX; Tue, 23 Nov 2004 09:44:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbp3-0001W2-6S for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 09:39:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14679 for ; Tue, 23 Nov 2004 09:39:10 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbsh-00017D-T7 for lemonade@ietf.org; Tue, 23 Nov 2004 09:43:01 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANEclY17735; Tue, 23 Nov 2004 16:38:55 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 16:37:31 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iANEbVHL029828; Tue, 23 Nov 2004 16:37:31 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00irjmMe; Tue, 23 Nov 2004 16:37:31 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANEbUS20005; Tue, 23 Nov 2004 16:37:30 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 08:36:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] partial fetches with IMAP URLs? Date: Tue, 23 Nov 2004 08:36:57 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BBD@daebe005.americas.nokia.com> Thread-Topic: [lemonade] partial fetches with IMAP URLs? thread-index: AcTREeSqDFjl1gKDTbqzocECZY7vOwAVT9Dg To: , X-OriginalArrivalTime: 23 Nov 2004 14:36:58.0457 (UTC) FILETIME=[E3119C90:01C4D169] X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Mark Crispin > Sent: Monday, November 22, 2004 10:56 PM ... > On Mon, 22 Nov 2004, Pete Resnick wrote: > > There was discussion not too long ago that IMAPURL needed=20 > to be updated=20 > > anyway. Adding byte-ranges to the URL would get them into=20 > URLFETCH, BURL, and=20 > > CATENATE by reference automatically. >=20 > Actually, not; since the byte-range would be determined by=20 > whatever entity=20 > generated the URL, whereas the need is for the entity that is=20 > fetching the=20 > data. The syntax could allow the range to be appended after the fetching entity received it. URLAUTH would have to allow for the URL to=20 extend beyond "URLAUTH=3D::". The token would=20 only authorize the rump, and would tolerate the range syntax. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 10:20:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20481 for ; Tue, 23 Nov 2004 10:20:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcWz-0006w8-8y for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 10:24:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcNX-0006Dx-NF; Tue, 23 Nov 2004 10:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcAD-0007gP-0D for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 10:01:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17436 for ; Tue, 23 Nov 2004 10:01:02 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcDs-00043g-3x for lemonade@ietf.org; Tue, 23 Nov 2004 10:04:53 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iANEpZ5j010319; Tue, 23 Nov 2004 09:51:41 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Nov 2004 09:48:33 -0500 Message-ID: From: Eric Burger To: Philip Guenther Subject: RE: [lemonade] partial fetches with IMAP URLs? Date: Tue, 23 Nov 2004 09:48:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 What if I had a URLAUTH over an imap: URL? If I hack the byte range, won't that hack the signature. Also, what about error conditions, like fetching beyond the end of the object or across the end of the object? > -----Original Message----- > From: Philip Guenther [mailto:guenther+lemonade@sendmail.com] > Sent: Monday, November 22, 2004 11:29 PM > To: Pete Resnick > Cc: lemonade@ietf.org > Subject: Re: [lemonade] partial fetches with IMAP URLs? > > > Pete Resnick writes: > >On 11/22/04 at 1:59 PM -0800, Philip Guenther wrote: > >>IMAP URLs, like HTTP URLs, do not provide a syntax for specifying a > >>specific byte-range of the indicated object, even though the > >>underlying protocol does. Should URLFETCH provide a way to do > >>partial fetches? How about BURL or CATENATE? > > > >There was discussion not too long ago that IMAPURL needed to be > >updated anyway. Adding byte-ranges to the URL would get them into > >URLFETCH, BURL, and CATENATE by reference automatically. > > While this makes sense, I'm a bit concerned by the http precedent: > HTTP-the-protocol support sub-ranges retrieval, why doesn't > http-the-schema? Is it because HTTP has difficulty with mutable > resources, as seen in the rules around validators and sub-range > requests? If so, then adding byte-range syntax to the imap schema > should be fine, at least when a UIDVALIDITY is also specified, as IMAP > provides strong immutability guarantees in that case. > > Are there any existing schemata that define byte-range (subobject?) > access whose example the imap schema could follow > > > Philip Guenther > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 10:48:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23602 for ; Tue, 23 Nov 2004 10:48:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcxL-000277-TW for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 10:51:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWck0-0004Ke-FU; Tue, 23 Nov 2004 10:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcZA-0001u1-W7 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 10:26:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21060 for ; Tue, 23 Nov 2004 10:26:50 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWccq-0007jg-Aa for lemonade@ietf.org; Tue, 23 Nov 2004 10:30:41 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANFPkF26314; Tue, 23 Nov 2004 17:25:51 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 17:27:48 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iANFRmsW014707; Tue, 23 Nov 2004 17:27:48 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00IxiWBn; Tue, 23 Nov 2004 17:27:47 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANFOpa14639; Tue, 23 Nov 2004 17:24:51 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 09:24:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Channel updates for content conversion Date: Tue, 23 Nov 2004 09:24:47 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAC42@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Channel updates for content conversion thread-index: AcTG/CiYm4DUTsb2SQek3w7qr/FIfwKc+9kw To: , X-OriginalArrivalTime: 23 Nov 2004 15:24:48.0758 (UTC) FILETIME=[91E6C960:01C4D170] X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Lyndon Nerenberg > Sent: Wednesday, November 10, 2004 3:00 AM ... > 3 CHANNELCONVERSIONS "image audio foo" > * CHANNELCONVERSIONS "audio/gsm" > * CHANNELCONVERSIONS "audio/g723" > * CHANNELCONVERSIONS "audio/basic" > * CHANNELCONVERSIONS "image/gif" > * CHANNELCONVERSIONS "image/jpeg" > 3 OK CHANNELCONVERSIONS completed How do you communicate that a conversion between top level media types is permitted? For example from pdf to plain=20 text. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 10:50:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23883 for ; Tue, 23 Nov 2004 10:50:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWd09-0002Ww-9A for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 10:54:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWckG-0004Pw-5U; Tue, 23 Nov 2004 10:38:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcca-0002eQ-Ll for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 10:30:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21376 for ; Tue, 23 Nov 2004 10:30:21 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcgF-00087v-R8 for lemonade@ietf.org; Tue, 23 Nov 2004 10:34:13 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANFTrv09092; Tue, 23 Nov 2004 17:30:01 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 17:29:22 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iANFTMf2009450; Tue, 23 Nov 2004 17:29:22 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 009LFQFJ; Tue, 23 Nov 2004 17:29:22 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANFTLS00100; Tue, 23 Nov 2004 17:29:21 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 09:27:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Channel updates for content conversion Date: Tue, 23 Nov 2004 09:27:47 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAC43@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Channel updates for content conversion thread-index: AcTHdm14Z6d4rE3xQXWuKqov/WPf4AJ+kb3A To: X-OriginalArrivalTime: 23 Nov 2004 15:27:48.0433 (UTC) FILETIME=[FCFF0410:01C4D170] X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Lyndon Nerenberg > Sent: Wednesday, November 10, 2004 5:25 PM ... > The syntax will be extended to allow CHANNEL to send data in-band by=20 > specifying > a NIL scheme. E.g. >=20 > 2 CHANNEL NIL (1 1) application/pdf I would like to see a mechanism that allowed for partial retrieval in=20 the case of in-band. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 11:14:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26325 for ; Tue, 23 Nov 2004 11:14:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdMg-0005s8-OC for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 11:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWd0X-0000FX-0x; Tue, 23 Nov 2004 10:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcww-0007KV-E3 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 10:51:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23945 for ; Tue, 23 Nov 2004 10:51:23 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWd0c-0002Xp-Ny for lemonade@ietf.org; Tue, 23 Nov 2004 10:55:15 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANFpGF06650; Tue, 23 Nov 2004 17:51:22 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 17:47:20 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iANFlKCG020537; Tue, 23 Nov 2004 17:47:20 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00EbEc32; Tue, 23 Nov 2004 17:47:18 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANFlHS10312; Tue, 23 Nov 2004 17:47:17 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 09:46:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] partial fetches with IMAP URLs? Date: Tue, 23 Nov 2004 09:46:52 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BBF@daebe005.americas.nokia.com> Thread-Topic: [lemonade] partial fetches with IMAP URLs? thread-index: AcTRcMmEsQdULUtBSp29Hyk7LqE5ygAAllnw To: , X-OriginalArrivalTime: 23 Nov 2004 15:46:53.0169 (UTC) FILETIME=[A74FDE10:01C4D173] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Eric Burger > Sent: Tuesday, November 23, 2004 9:49 AM ... > What if I had a URLAUTH over an imap: URL? If I hack the=20 > byte range, won't > that hack the signature. =20 Define the signature coverage to not include the range specifier. > Also, what about error conditions,=20 > like fetching > beyond the end of the object or across the end of the object? This could be handled the same way FETCH does it. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 11:14:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26380 for ; Tue, 23 Nov 2004 11:14:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdN4-0005sQ-KH for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 11:18:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWd0X-0000Fq-AZ; Tue, 23 Nov 2004 10:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcx0-0007Ka-48 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 10:51:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23954 for ; Tue, 23 Nov 2004 10:51:27 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWd0g-0002Xv-MG for lemonade@ietf.org; Tue, 23 Nov 2004 10:55:19 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANFouF06238; Tue, 23 Nov 2004 17:51:08 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 17:44:58 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iANFiwGx027781; Tue, 23 Nov 2004 17:44:58 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00yKEqES; Tue, 23 Nov 2004 17:44:58 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANFg1a28815; Tue, 23 Nov 2004 17:42:02 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 09:41:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Channel updates for content conversion Date: Tue, 23 Nov 2004 09:41:23 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BBE@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Channel updates for content conversion thread-index: AcTHmBWldooWA9WOT2ubXjXVzHEc8QJ2ftjg To: , X-OriginalArrivalTime: 23 Nov 2004 15:41:25.0181 (UTC) FILETIME=[E3D0DED0:01C4D172] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of ext Lyndon Nerenberg > Sent: Wednesday, November 10, 2004 9:30 PM ... > --On 2004-11-10 9:01 PM -0500 Eric Burger =20 > wrote: >=20 > > The feeling in the room today is that server-based would be FETCH > > driven. What do you think of that? >=20 > The issue I see with FETCH is the lack of an 8bit clean path. The=20 > converted data would still most likely require base64=20 > encoding. I would=20 > like to hear Mark's opinion on this. We could structure=20 > conversion such=20 > that it would work with FETCH, BINARY, and CHANNEL. My concern with=20 > this is that it would require adding yet another capability, and as=20 > Alexey mentioned, IMAP is growing *way* too many=20 > capabilities. From an=20 > engineering standpoint I think it's better to implement in-band=20 > conversion in one place only. This eliminates the problems associated=20 I prefer not to use FETCH as well.=20 Another inelegance with using FETCH is that within the same=20 FETCH command you could request MIME headers that say the=20 Content-Type is one thing and then the conversion is returning another. I know the syntax could be adjusted to clarify, but=20 I still find it unappealing. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 12:03:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00384 for ; Tue, 23 Nov 2004 12:03:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWe8V-0003tg-2E for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 12:07:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdz7-0001QT-Sd; Tue, 23 Nov 2004 11:57:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWduD-0000Fd-91 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 11:52:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29579 for ; Tue, 23 Nov 2004 11:52:38 -0500 (EST) Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdxt-0002bW-5N for lemonade@ietf.org; Tue, 23 Nov 2004 11:56:30 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout3.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iANGqa0f026384; Tue, 23 Nov 2004 08:52:36 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iANGqali012575; Tue, 23 Nov 2004 08:52:36 -0800 Date: Tue, 23 Nov 2004 08:52:36 -0800 (PST) From: Mark Crispin To: Michael.Wener@nokia.com Subject: RE: [lemonade] partial fetches with IMAP URLs? In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BBF@daebe005.americas.nokia.com> Message-ID: References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BBF@daebe005.americas.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: guenther+lemonade@sendmail.com, lemonade@ietf.org, eburger@brooktrout.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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > Define the signature coverage to not include the range specifier. Magic invariably leads to evil. We've learned this lesson the hard way many many times before. If there is to be a byte range, it needs to be a facility in the URLFETCH command. Additionally, it may also be desirable to have a facility in the IMAP URL. -- 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 From lemonade-bounces@ietf.org Tue Nov 23 12:32:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02002 for ; Tue, 23 Nov 2004 12:32:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWeaI-0007nZ-Hh for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 12:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWeP2-00019q-Ut; Tue, 23 Nov 2004 12:24:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWe2l-0002OR-O4 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 12:01:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00264 for ; Tue, 23 Nov 2004 12:01:28 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWe6R-0003VS-Pw for lemonade@ietf.org; Tue, 23 Nov 2004 12:05:21 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iANH1Stb018825; Tue, 23 Nov 2004 09:01:28 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iANH1SOW012777; Tue, 23 Nov 2004 09:01:28 -0800 Date: Tue, 23 Nov 2004 09:01:28 -0800 (PST) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] WGLC's In-Reply-To: <41A34434.9080601@isode.com> Message-ID: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A34434.9080601@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Philip Guenther , Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Tue, 23 Nov 2004, Alexey Melnikov wrote: > Do you really mean something like: > URL"imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20" > or is there a space missing? Yeah, I agree that a space should be added. In the name of magic elimination, how about: catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] 1*(SP (("TEXT" SP literal) / ("URL" SP url))) or even: catenate = "CATENATE" SP mailbox SP parameters 1*(SP (("TEXT" SP literal) / ("URL" SP url))) parameters = ("(" parameter [1*(SP parameter)] ")") / "NIL" paramter = ("FLAGS" SP flag-list]) / ("DATE" date-time) -- 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 From lemonade-bounces@ietf.org Tue Nov 23 12:39:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02368 for ; Tue, 23 Nov 2004 12:39:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWehA-00009u-KG for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 12:43:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWePM-0001LR-8T; Tue, 23 Nov 2004 12:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWeMb-0008S3-Ef for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 12:22:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01337 for ; Tue, 23 Nov 2004 12:21:58 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWeQI-0006E6-Eq for lemonade@ietf.org; Tue, 23 Nov 2004 12:25:51 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 23 Nov 2004 17:21:09 +0000 Message-ID: <41A37183.5050209@isode.com> Date: Tue, 23 Nov 2004 17:21:07 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] WGLC's References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A34434.9080601@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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Philip Guenther , Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Mark Crispin wrote: > On Tue, 23 Nov 2004, Alexey Melnikov wrote: > >> Do you really mean something like: >> URL"imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20" >> or is there a space missing? > > > Yeah, I agree that a space should be added. > > In the name of magic elimination, how about: > > catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] > 1*(SP (("TEXT" SP literal) / ("URL" SP url))) > > or even: > > catenate = "CATENATE" SP mailbox SP parameters > 1*(SP (("TEXT" SP literal) / ("URL" SP url))) > > parameters = ("(" parameter [1*(SP parameter)] ")") / "NIL" > > paramter = ("FLAGS" SP flag-list]) / ("DATE" date-time) Let's break everything :-). Seriously, I think the latter will eliminate convoluted logic for checking for optional flags and date. It also allows for easy extensibility in the future. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 13:08:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04864 for ; Tue, 23 Nov 2004 13:08:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWf9m-0003yf-NA for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 13:12:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWf3y-0001Y0-Pk; Tue, 23 Nov 2004 13:06:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWf1V-00012k-UA for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 13:04:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04387 for ; Tue, 23 Nov 2004 13:04:13 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWf5B-0003OM-To for lemonade@ietf.org; Tue, 23 Nov 2004 13:08:07 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANI3vF26806; Tue, 23 Nov 2004 20:04:06 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 20:03:18 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iANI3IBP028479; Tue, 23 Nov 2004 20:03:18 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Kx6mv8; Tue, 23 Nov 2004 20:03:17 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANI3GS28122; Tue, 23 Nov 2004 20:03:17 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 12:03:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] partial fetches with IMAP URLs? Date: Tue, 23 Nov 2004 12:03:01 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC1@daebe005.americas.nokia.com> Thread-Topic: [lemonade] partial fetches with IMAP URLs? thread-index: AcTRfTbUuOgkOjDeQE6hAxMbau5TJgACB6qQ To: X-OriginalArrivalTime: 23 Nov 2004 18:03:08.0441 (UTC) FILETIME=[B0276090:01C4D186] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Mark Crispin [mailto:mrc@CAC.Washington.EDU] > Sent: Tuesday, November 23, 2004 11:53 AM > To: Wener Michael (Nokia-ES/Pittsburgh) ... > On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > > Define the signature coverage to not include the range specifier. >=20 > Magic invariably leads to evil. =20 How is this magic? Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 13:48:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08000 for ; Tue, 23 Nov 2004 13:48:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfla-0000vD-41 for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 13:51:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfgi-0002IP-Hi; Tue, 23 Nov 2004 13:46:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfbt-00015c-66 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 13:41:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07379 for ; Tue, 23 Nov 2004 13:41:51 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWffa-0008Ne-2z for lemonade@ietf.org; Tue, 23 Nov 2004 13:45:43 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iANIfn9Z009521; Tue, 23 Nov 2004 10:41:50 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iANIfmhP031759 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 Nov 2004 10:41:48 -0800 Date: Tue, 23 Nov 2004 10:43:51 -0800 (Pacific Standard Time) From: Mark Crispin To: Michael.Wener@nokia.com Subject: RE: [lemonade] partial fetches with IMAP URLs? In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC1@daebe005.americas.nokia.com> Message-ID: References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC1@daebe005.americas.nokia.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: >>> Define the signature coverage to not include the range specifier. >> Magic invariably leads to evil. > How is this magic? URLAUTH covers the entire URL. Except when it doesn't cover the entire URL. There's this exception, that exception, the other exception. But trust us to anticipate all the interactions and how they will affect security. I feel that such is the path of madness. We have gone down similar paths many times before in the past 30 or so years, and have invariably come to regret it. -- 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 From lemonade-bounces@ietf.org Tue Nov 23 14:11:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09494 for ; Tue, 23 Nov 2004 14:11:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWg7u-00040M-UX for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 14:14:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfzo-0005Yg-Op; Tue, 23 Nov 2004 14:06:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfrd-000430-M0 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 13:58:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08720 for ; Tue, 23 Nov 2004 13:58:07 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfvL-00027x-JZ for lemonade@ietf.org; Tue, 23 Nov 2004 14:02:00 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iANIw5vG013398; Tue, 23 Nov 2004 10:58:05 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iANIw4UT002310 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 Nov 2004 10:58:05 -0800 Date: Tue, 23 Nov 2004 11:00:07 -0800 (Pacific Standard Time) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] WGLC's In-Reply-To: <41A37183.5050209@isode.com> Message-ID: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A34434.9080601@isode.com> <41A37183.5050209@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Philip Guenther , Pete Resnick , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Tue, 23 Nov 2004, Alexey Melnikov wrote: >> catenate = "CATENATE" SP mailbox SP parameters >> 1*(SP (("TEXT" SP literal) / ("URL" SP url))) >> >> parameters = ("(" parameter [1*(SP parameter)] ")") / "NIL" >> >> paramter = ("FLAGS" SP flag-list]) / ("DATE" date-time) > Let's break everything :-). Indeed. > Seriously, I think the latter will eliminate convoluted logic for checking > for optional flags and date. It also allows for easy extensibility in the > future. That's what I thought. Copying APPEND was a good idea initially, but I believe that we have stretched it beyond its reasonable limits. I am not proud of the syntax of APPEND in IMAP. It was the ugly result of evolution, not planned creation; and it shows. It we were going to implement catenate as an extension syntax to APPEND, we'd have to go this route; but as MULTIAPPEND has precluded that (and is also very useful) we have to have a separate CATENATE command. There is, however, another possibility. We *could* defend a new APPEND, identified with an APPENDPLUS extension, with the following syntax that permits both CATENATE and MULTIAPPEND functionality: append =/ "APPEND" SP parameters SP mailbox 1*(SP appendtext) parameters = "(" *parameter ")" parameter = ("FLAGS" SP flag-list]) / ("DATE" date-time) appendtext = "( ("TEXT" SP astring) / ("URL" SP astring) ")" There are a few warts with this. The parameters have to be before the mailbox to distinguish from the IMAP4 APPEND command; and empty parameters would be by the empty list () instead of the more IMAP traditional NIL. But these are small warts compared to the benefits of the cleanup. -- 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 From lemonade-bounces@ietf.org Tue Nov 23 14:32:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11260 for ; Tue, 23 Nov 2004 14:32:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgSJ-0006lq-GZ for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 14:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgMp-0001iJ-MB; Tue, 23 Nov 2004 14:30:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgGD-0000kz-Lf for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 14:23:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10531 for ; Tue, 23 Nov 2004 14:23:31 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgJu-0005bw-5J for lemonade@ietf.org; Tue, 23 Nov 2004 14:27:24 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANJNIS00186; Tue, 23 Nov 2004 21:23:23 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 21:25:30 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iANJPUS1003861; Tue, 23 Nov 2004 21:25:30 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00vK4OpD; Tue, 23 Nov 2004 21:25:28 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANJMba27430; Tue, 23 Nov 2004 21:22:37 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 13:22:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] partial fetches with IMAP URLs? Date: Tue, 23 Nov 2004 13:22:32 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC2@daebe005.americas.nokia.com> Thread-Topic: [lemonade] partial fetches with IMAP URLs? thread-index: AcTRjE0czVN3JhpIQuyQeyPWDacCKwAAS7fg To: X-OriginalArrivalTime: 23 Nov 2004 19:22:33.0565 (UTC) FILETIME=[C86398D0:01C4D191] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: mrc@ndcms.cac.washington.edu > [mailto:mrc@ndcms.cac.washington.edu]On Behalf Of ext Mark Crispin > Sent: Tuesday, November 23, 2004 1:44 PM .. > On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > >>> Define the signature coverage to not include the range specifier. > >> Magic invariably leads to evil. > > How is this magic? >=20 > URLAUTH covers the entire URL. >=20 > Except when it doesn't cover the entire URL. There's this=20 > exception, that=20 > exception, the other exception. But trust us to anticipate all the=20 > interactions and how they will affect security. Right now the signature only covers everything prior to and=20 excluding the 2rd ":" from the end. So technically it is not the=20 entire URL, but I understand your point. Your point is about=20 exceptions to the rule. Of course the same rule applies in the case where there may be URL to the right of . In other words the rule can be the same. So I don't see madness. I see consistency. Everything to the left is signed. Everything to the right is not signed. I think there may be more confusion by allowing ranges to be=20 defined in two places, i.e. the URL and in a command that uses a URL. Now there is the issue of tracking mismatches=20 between them or disallowing them to be used together. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 14:36:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11650 for ; Tue, 23 Nov 2004 14:36:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgWF-0007BZ-9c for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 14:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgMs-0001jP-Ek; Tue, 23 Nov 2004 14:30:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgJL-00011R-8G for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 14:26:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10782 for ; Tue, 23 Nov 2004 14:26:45 -0500 (EST) 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.33) id 1CWgN3-0005zc-D4 for lemonade@ietf.org; Tue, 23 Nov 2004 14:30:38 -0500 Received: from [130.129.135.164] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Tue, 23 Nov 2004 13:26:10 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: <41A11680.6050109@isode.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Tue, 23 Nov 2004 13:26:04 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 So I want to go back to the beginning because things seem to be getting worse as we go along: On 11/21/04 at 3:56 PM -0800, Mark Crispin wrote: >The usage in CATENATE and MAILBOX-REFERRAL only works as long as >IMAP URLs can not contain "]" or spaces. That currently seems to be >true; but I don't consider it to be a prudent assumption. > >By using astring, you don't need to have a separate rule that knows >about the syntax of imapurl just to parse the command or its >response. In the command itself, we don't have to worry about "]". All we have to worry about is space. And space is thoroughly illegal in *any* URIs, not just IMAP ones. So there is no requirement to know the syntax of imapurl just to parse the CATENATE command: You look for the space. If the character after it is a "{", then you've got a literal. Else, it's a URI. Read until next space or EOL. Anything that turns out later to not be a legit URI (even if it's due to a bad client inserting a space into a URL where it doesn't belong) will simply generate a NO. By putting it in an astring, you're requiring implementations to go through and esacpe backslashes and double-quotes. We all know that implementations will screw this up. Some will do stupid things like "%" escaping them instead of "\" escaping. Some will fail to do it at all. We'll end up with some server implementations trying to be "helpful". I think the chances for foul-up are much greater by requiring them to be astrings than if we put them in in the raw. Now, the response code is a different story. We might have to worry about "]". But in the case of the response code, we're pretty much talking about trace information, so if a server screws up the escaping there, I'm not nearly so concerned. With only my "member of the WG" hat on: My feeling is that we should stick to the current syntax on the command but make the response contain an astring. 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 From lemonade-bounces@ietf.org Tue Nov 23 14:42:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12319 for ; Tue, 23 Nov 2004 14:42:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgc0-00080E-V4 for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 14:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgX6-0003oc-BA; Tue, 23 Nov 2004 14:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgVi-0003aZ-PS for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 14:39:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11989 for ; Tue, 23 Nov 2004 14:39:32 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgZQ-0007aU-EB for lemonade@ietf.org; Tue, 23 Nov 2004 14:43:25 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 23 Nov 2004 19:38:53 +0000 Message-ID: <41A391CC.1060201@isode.com> Date: Tue, 23 Nov 2004 19:38:52 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick Subject: Re: [lemonade] WGLC's References: <41A11680.6050109@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: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Pete Resnick wrote: > Now, the response code is a different story. We might have to worry > about "]". But in the case of the response code, we're pretty much > talking about trace information, so if a server screws up the escaping > there, I'm not nearly so concerned. > > With only my "member of the WG" hat on: My feeling is that we should > stick to the current syntax on the command but make the response > contain an astring. You can't return <"> or "{" in a response code, so we can't use "astring"/"quoted"/"literal". We can only use something like "atom". _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 15:01:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15998 for ; Tue, 23 Nov 2004 15:01:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWguD-00028R-Le for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 15:04:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWggw-0005dR-1g; Tue, 23 Nov 2004 14:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgZU-0004Pf-Uu for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 14:43:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12523 for ; Tue, 23 Nov 2004 14:43:27 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgdD-00081J-Ko for lemonade@ietf.org; Tue, 23 Nov 2004 14:47:20 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 23 Nov 2004 19:42:50 +0000 Message-ID: <41A392B9.1030604@isode.com> Date: Tue, 23 Nov 2004 19:42:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick Subject: Re: [lemonade] WGLC's References: <41A11680.6050109@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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Pete Resnick wrote: > By putting it in an astring, you're requiring implementations to go > through and esacpe backslashes and double-quotes. We all know that > implementations will screw this up. As I understand it, just doing <"> url <"> should suffice. Anyway, escape rules for quoted strings are well understood. Borrowing existing function for sending a quoted string from c-client or Cyrus should be no brainer. > Some will do stupid things like "%" escaping them instead of "\" > escaping. Some will fail to do it at all. We'll end up with some > server implementations trying to be "helpful". I think the chances for > foul-up are much greater by requiring them to be astrings than if we > put them in in the raw. Have you noticed how many times recently we try to work around dumb implementors? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 16:33:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05758 for ; Tue, 23 Nov 2004 16:33:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiLX-0001Ij-61 for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 16:37:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWhxK-0004nj-9H; Tue, 23 Nov 2004 16:12:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWhC2-0000tS-FY for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 15:23:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19680 for ; Tue, 23 Nov 2004 15:23:15 -0500 (EST) Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWhFl-0005SN-4V for lemonade@ietf.org; Tue, 23 Nov 2004 15:27:09 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iANKNGh5006548; Tue, 23 Nov 2004 12:23:16 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iANKNFgL029935 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 Nov 2004 12:23:15 -0800 Date: Tue, 23 Nov 2004 12:25:18 -0800 (Pacific Standard Time) From: Mark Crispin To: Michael.Wener@nokia.com Subject: RE: [lemonade] partial fetches with IMAP URLs? In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC2@daebe005.americas.nokia.com> Message-ID: References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC2@daebe005.americas.nokia.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > Of course the same rule applies in the case where there may be > URL to the right of . In other words the rule can be the > same. So I don't see madness. I see consistency. Everything to > the left is signed. Everything to the right is not signed. The current definition of URLAUTH requires that the URLAUTH be the last thing in the URL. > I think there may be more confusion by allowing ranges to be > defined in two places, i.e. the URL and in a command that > uses a URL. Now there is the issue of tracking mismatches > between them or disallowing them to be used together. These do two entirely different things. One, in the generated URL, is a range determined by the entity that generated the URL, and the client can not retrieve outside that range. The other allows the client to do partial fetching within data that he has access to. -- 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 From lemonade-bounces@ietf.org Tue Nov 23 16:44:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07712 for ; Tue, 23 Nov 2004 16:44:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiWP-00034J-NV for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 16:48:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiIt-0004YI-LL; Tue, 23 Nov 2004 16:34:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWi5q-0000Zl-Sg for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 16:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03765 for ; Tue, 23 Nov 2004 16:20:56 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWi9Y-0007rY-FW for lemonade@ietf.org; Tue, 23 Nov 2004 16:24:49 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANLKhF10385; Tue, 23 Nov 2004 23:20:50 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 23:20:05 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iANLK5tJ023367; Tue, 23 Nov 2004 23:20:05 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00yDf6Kz; Tue, 23 Nov 2004 23:20:04 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANLJwS26547; Tue, 23 Nov 2004 23:19:58 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 15:18:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] partial fetches with IMAP URLs? Date: Tue, 23 Nov 2004 15:18:49 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC4@daebe005.americas.nokia.com> Thread-Topic: [lemonade] partial fetches with IMAP URLs? thread-index: AcTRmnKfVi05AFSXQbKm3JcqUr1J3gAA8qww To: X-OriginalArrivalTime: 23 Nov 2004 21:18:49.0650 (UTC) FILETIME=[0675B120:01C4D1A2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: mrc@ndcms.cac.washington.edu > [mailto:mrc@ndcms.cac.washington.edu]On Behalf Of ext Mark Crispin > Sent: Tuesday, November 23, 2004 3:25 PM ... > On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > > Of course the same rule applies in the case where there may be > > URL to the right of . In other words the rule can be the > > same. So I don't see madness. I see consistency. Everything to > > the left is signed. Everything to the right is not signed. >=20 > The current definition of URLAUTH requires that the URLAUTH=20 > be the last=20 > thing in the URL. I understand. My response above assumes that would be changed. >=20 > > I think there may be more confusion by allowing ranges to be > > defined in two places, i.e. the URL and in a command that > > uses a URL. Now there is the issue of tracking mismatches > > between them or disallowing them to be used together. >=20 > These do two entirely different things. >=20 > One, in the generated URL, is a range determined by the entity that=20 > generated the URL, and the client can not retrieve outside that range. >=20 > The other allows the client to do partial fetching within=20 > data that he has=20 > access to. I understand. So you chose the first semantic I listed. The fact that = one range is signed, and one is not is irrelevant when it comes to tracking=20 range mismatch issues. In any event I don't think the use case you describe is very meaningful. The usefulness of partial fetch is driven more by the mechanics of how the client software chooses to download the message or body part, not=20 by partial authorizations. Why would a client want to authorize a slice of a message or body part? How would the granting client even know what slice to authorize? The answer to the above questions is that it would require human=20 intervention. How would the receiving client know what to do with this slice once it=20 was granted access to it? Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 17:00:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10946 for ; Tue, 23 Nov 2004 17:00:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWimF-0005UB-Mf for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 17:04:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiPb-0000cs-5V; Tue, 23 Nov 2004 16:41:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiEX-0007mp-Gn for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 16:29:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05267 for ; Tue, 23 Nov 2004 16:29:54 -0500 (EST) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiIG-0000on-42 for lemonade@ietf.org; Tue, 23 Nov 2004 16:33:49 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iANLTslk020502; Tue, 23 Nov 2004 13:29:54 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iANLTrDi028130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 Nov 2004 13:29:54 -0800 Date: Tue, 23 Nov 2004 13:31:56 -0800 (Pacific Standard Time) From: Mark Crispin To: Michael.Wener@nokia.com Subject: RE: [lemonade] partial fetches with IMAP URLs? In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC4@daebe005.americas.nokia.com> Message-ID: References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC4@daebe005.americas.nokia.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > Why would a client want to authorize a slice of a message or body part? > How would the granting client even know what slice to authorize? I can think of any number of cases in which I might want to grant access to a portion of my mailbox but not all of it. URLAUTH reduces the granularity to message and segment within a message. This is a further reduction in granularity. Note that IMAPURL does not permit the full richness of IMAP sections; in particular, note that IMAPURL has a "section" syntax rule which is a subset of the corresponding rule 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 From lemonade-bounces@ietf.org Tue Nov 23 17:22:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13171 for ; Tue, 23 Nov 2004 17:22:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWj7I-0000Lu-L2 for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 17:26:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiqA-00078b-RU; Tue, 23 Nov 2004 17:08:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWieY-0000d8-9r for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 16:56:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10051 for ; Tue, 23 Nov 2004 16:56:47 -0500 (EST) 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.33) id 1CWiiH-0004qx-7i for lemonade@ietf.org; Tue, 23 Nov 2004 17:00:42 -0500 Received: from [130.129.135.164] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Tue, 23 Nov 2004 15:56:08 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <41A392B9.1030604@isode.com> References: <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Tue, 23 Nov 2004 15:56:03 -0600 To: Alexey Melnikov From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On 11/23/04 at 7:42 PM +0000, Alexey Melnikov wrote: >Pete Resnick wrote: > >>By putting it in an astring, you're requiring implementations to go >>through and esacpe backslashes and double-quotes. We all know that >>implementations will screw this up. > >As I understand it, just doing <"> url <"> should suffice. "Should" is the key. The concern is that you're going to get a "\" or a <"> in a URL, at which point you're going to have to escape them with "\". So the algorithm will inevitably be to do the escaping. >Anyway, escape rules for quoted strings are well understood. >Borrowing existing function for sending a quoted string from >c-client or Cyrus should be no brainer. To quote your later comment: >Have you noticed how many times recently we try to work around dumb >implementors? Implementors have no shortage in their ability to produce dumb implementations. In this case, I think there is less chance of us having to work around a dumb implementor by saying "insert space followed by literal or URL" instead of "insert space followed by literal or appropriately encoded URL." 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 From lemonade-bounces@ietf.org Tue Nov 23 17:43:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15244 for ; Tue, 23 Nov 2004 17:43:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWjRS-0002oj-AN for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 17:47:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWjC8-00058m-IV; Tue, 23 Nov 2004 17:31:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWj7z-00043n-K7 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 17:27:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13535 for ; Tue, 23 Nov 2004 17:27:12 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWjBi-0000mn-P5 for lemonade@ietf.org; Tue, 23 Nov 2004 17:31:08 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANMQxv13000; Wed, 24 Nov 2004 00:27:08 +0200 (EET) X-Scanned: Wed, 24 Nov 2004 00:26:52 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iANMQqG2011792; Wed, 24 Nov 2004 00:26:52 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0095egKc; Wed, 24 Nov 2004 00:26:51 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANMQoa23835; Wed, 24 Nov 2004 00:26:50 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 16:26:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] partial fetches with IMAP URLs? Date: Tue, 23 Nov 2004 16:26:48 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC5@daebe005.americas.nokia.com> Thread-Topic: [lemonade] partial fetches with IMAP URLs? thread-index: AcTRo8Z4tVQviAZAQ+Sn2wA8xR+jdwAAREvg To: X-OriginalArrivalTime: 23 Nov 2004 22:26:49.0806 (UTC) FILETIME=[866C16E0:01C4D1AB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: mrc@ndcms.cac.washington.edu > [mailto:mrc@ndcms.cac.washington.edu]On Behalf Of ext Mark Crispin > Sent: Tuesday, November 23, 2004 4:32 PM ... > On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > > Why would a client want to authorize a slice of a message=20 > or body part? > > How would the granting client even know what slice to authorize? >=20 > I can think of any number of cases in which I might want to=20 > grant access=20 > to a portion of my mailbox but not all of it. URLAUTH reduces the=20 > granularity to message and segment within a message. This is=20 > a further=20 > reduction in granularity. I agree the granularity of message or section for authorization=20 makes good sense. The granularity of an arbitrary slice of bytes=20 of either a message or a section for authorization does not make=20 sense to me. >=20 > Note that IMAPURL does not permit the full richness of IMAP=20 > sections; in=20 > particular, note that IMAPURL has a "section" syntax rule which is a=20 > subset of the corresponding rule in IMAP. I don't see the difference, but I don't think this is relevant. I'm concerned with the partial byte range. The portion I'm talking about=20 is authorization for an arbitrary slice of bytes from a message or=20 a section. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 17:53:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15989 for ; Tue, 23 Nov 2004 17:53:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWjas-0004N7-SZ for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 17:57:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWjNu-0000Zn-SR; Tue, 23 Nov 2004 17:43:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWjHG-0006Tr-UA for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 17:36:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14637 for ; Tue, 23 Nov 2004 17:36:47 -0500 (EST) Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWjL0-00020V-Fj for lemonade@ietf.org; Tue, 23 Nov 2004 17:40:42 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iANMamGk003575; Tue, 23 Nov 2004 14:36:48 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iANMalSJ007528 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 Nov 2004 14:36:48 -0800 Date: Tue, 23 Nov 2004 14:38:50 -0800 (Pacific Standard Time) From: Mark Crispin To: Michael.Wener@nokia.com Subject: RE: [lemonade] partial fetches with IMAP URLs? In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC5@daebe005.americas.nokia.com> Message-ID: References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC5@daebe005.americas.nokia.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > The granularity of an arbitrary slice of bytes > of either a message or a section for authorization does not make > sense to me. I can think of use cases; but I agree that these use cases aren't particularly exciting given that there's always the existing choice of download-then-forward. I'm not going to jump up and down for this functionality. I'm just pointing out that it has a use which is not duplicated by any other proposal. If we decide that this functionality is not important (and that is a question that I will "abstain" on), then there is no need to modify IMAP URLs because it can be done in the URLFETCH command. >> Note that IMAPURL does not permit the full richness of IMAP sections; >> in particular, note that IMAPURL has a "section" syntax rule which is a >> subset of the corresponding rule in IMAP. > I don't see the difference, but I don't think this is relevant. I'm > concerned with the partial byte range. The portion I'm talking about > is authorization for an arbitrary slice of bytes from a message or > a section. One of the use cases (admittedly a stretch) is to represent an IMAP section that can not be represented in an IMAP URL. As such, it goes on the "this is why we need it" pile. The other side (which you may argue) is that this functionality isn't useful enough to merit updating IMAPURL. -- 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 From lemonade-bounces@ietf.org Tue Nov 23 18:48:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21754 for ; Tue, 23 Nov 2004 18:48:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWkSY-00037Y-Km for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 18:52:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWkLl-0006Yl-6n; Tue, 23 Nov 2004 18:45:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRS8-0004pH-Kv for lemonade@megatron.ietf.org; Mon, 22 Nov 2004 22:34:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07159 for ; Mon, 22 Nov 2004 22:34:50 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRVi-0006gl-02 for lemonade@ietf.org; Mon, 22 Nov 2004 22:38:34 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAN3Yhio019571 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 22 Nov 2004 19:34:43 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAN3Yhio019571 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=eb/l46cZ/fBgfmG1Hz2s91H/Xqey/hacpP0tzS/4SHTeM0fMq7RI/uyfDgnnrN/// a2pjHAWAa2/vNnSxzJ9jhR4M3oXQzAP3hTOo0DMCTg/T2Bt80JdxnROL7ttLiPjT1kO YxeOWCGU95ihLZd0oxm6EGmaO3Bj9IR9biH3EBY= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAN3Yhl3009193; Mon, 22 Nov 2004 19:34:43 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411230334.iAN3Yhl3009193@lab.smi.sendmail.com> To: Pete Resnick Subject: Re: [lemonade] Examples for CATENATE In-reply-to: References: <41A11FA0.7040104@isode.com> <41A1D06D.3050704@isode.com> <41A213F5.1010809@isode.com> <41A2265C.6040905@isode.com> Date: Mon, 22 Nov 2004 19:34:43 -0800 From: Philip Guenther X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Tue, 23 Nov 2004 18:45:30 -0500 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Pete Resnick writes: >Is the space before each URL required? Yes. The grammar certainly requires a space before each imapurl. Leaving them out only when the previous argument was a literal would make the grammar more complicated for no gain and in fact make it different from how other IMAP commands are parsed when literals are used. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 21:02:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01942 for ; Tue, 23 Nov 2004 21:02:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWmYA-0003m2-Dq for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 21:06:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWmQ8-00065X-KA; Tue, 23 Nov 2004 20:58:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWmOF-0005Sc-G7 for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 20:56:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01551 for ; Tue, 23 Nov 2004 20:56:13 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWmS0-0002zQ-I8 for lemonade@ietf.org; Tue, 23 Nov 2004 21:00:09 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAO1u3Y00502; Wed, 24 Nov 2004 03:56:08 +0200 (EET) X-Scanned: Wed, 24 Nov 2004 03:55:54 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAO1tsVw005452; Wed, 24 Nov 2004 03:55:54 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Dbo8xv; Wed, 24 Nov 2004 03:55:53 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAO1tka08496; Wed, 24 Nov 2004 03:55:47 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 19:55:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] partial fetches with IMAP URLs? Date: Tue, 23 Nov 2004 19:55:44 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC6@daebe005.americas.nokia.com> Thread-Topic: [lemonade] partial fetches with IMAP URLs? thread-index: AcTRrQM4lFSgrIJsRHG2jSMHh//7rQAGmopw To: X-OriginalArrivalTime: 24 Nov 2004 01:55:45.0592 (UTC) FILETIME=[B6553B80:01C4D1C8] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: mrc@ndcms.cac.washington.edu > [mailto:mrc@ndcms.cac.washington.edu]On Behalf Of ext Mark Crispin > Sent: Tuesday, November 23, 2004 5:39 PM ... > On Tue, 23 Nov 2004 Michael.Wener@nokia.com wrote: > > The granularity of an arbitrary slice of bytes > > of either a message or a section for authorization does not make > > sense to me. >=20 > I can think of use cases; but I agree that these use cases aren't=20 > particularly exciting given that there's always the existing=20 > choice of=20 > download-then-forward. >=20 > I'm not going to jump up and down for this functionality. I'm just=20 > pointing out that it has a use which is not duplicated by any other=20 > proposal. If we decide that this functionality is not=20 > important (and that=20 > is a question that I will "abstain" on), then there is no=20 > need to modify=20 > IMAP URLs because it can be done in the URLFETCH command. I think signed byte ranges would be of dubious value. This is not the same as saying that IMAP URLs would be of no importance. Summary of my opinion is: 1) IMAP URLs should have byte ranges added. 2) Commands that take IMAP URLs as the identity of a byte stream=20 should not have additional byte range arguments qualifying that same byte stream. 3) URLAUTH can have a sensible syntax defined that allows a signed URL without signing the byte range defined in that URL. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 23:14:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11334 for ; Tue, 23 Nov 2004 23:14:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWobg-00042S-Ej for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 23:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWoUZ-0003m9-T5; Tue, 23 Nov 2004 23:10:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWoSx-00037r-4X for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 23:09:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11056 for ; Tue, 23 Nov 2004 23:09:12 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWoWj-0003I8-G5 for lemonade@ietf.org; Tue, 23 Nov 2004 23:13:10 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAO48Fdi038671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Nov 2004 21:08:19 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Tue, 23 Nov 2004 20:08:14 -0800 From: Lyndon Nerenberg To: Michael.Wener@nokia.com, lemonade@ietf.org Subject: RE: [lemonade] Channel updates for content conversion Message-ID: <11A53CCD282C60540AF29096@peregrin.orthanc.ca> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAC42@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAC42@daebe005.americas. nokia.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-SdV-Metrics: orthanc.ca 1179; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit --On 2004-11-23 9:24 AM -0600 Michael.Wener@nokia.com wrote: > How do you communicate that a conversion between top level > media types is permitted? For example from pdf to plain > text. Advertise text/plain as a target conversion type. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 23 23:22:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11740 for ; Tue, 23 Nov 2004 23:22:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWojz-0005Af-RI for lemonade-web-archive@ietf.org; Tue, 23 Nov 2004 23:26:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWoZE-0004ya-3s; Tue, 23 Nov 2004 23:15:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWoX9-0004QI-Pz for lemonade@megatron.ietf.org; Tue, 23 Nov 2004 23:13:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11306 for ; Tue, 23 Nov 2004 23:13:32 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWoaw-00041v-Kv for lemonade@ietf.org; Tue, 23 Nov 2004 23:17:31 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAO4Crc8058022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Nov 2004 21:12:55 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Tue, 23 Nov 2004 20:12:53 -0800 From: Lyndon Nerenberg To: Michael.Wener@nokia.com Subject: RE: [lemonade] Channel updates for content conversion Message-ID: <89A1E463A5EC3272AC8F6768@peregrin.orthanc.ca> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAC43@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAC43@daebe005.americas. nokia.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-SdV-Metrics: orthanc.ca 1179; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit --On 2004-11-23 9:27 AM -0600 Michael.Wener@nokia.com wrote: > I would like to see a mechanism that allowed for partial retrieval in > the case of in-band. Where would this be useful? Channel was instigated in part because Fetch with partials was not sufficient for some clients. Partial fetch was being misused to fake out streaming downloads. That didn't work. Channel is an attempt to fix that. So in the context of Channel, why (and how) would a partial fetch be useful. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 06:23:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10725 for ; Wed, 24 Nov 2004 06:23:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWvJ8-0006Uw-SZ for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 06:27:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWvDz-0005ex-Tr; Wed, 24 Nov 2004 06:22:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWvDg-0005Ur-O6 for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 06:21:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10625 for ; Wed, 24 Nov 2004 06:21:53 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWvHX-0006D5-CW for lemonade@ietf.org; Wed, 24 Nov 2004 06:25:56 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 24 Nov 2004 11:20:42 +0000 Message-ID: <41A3BD2F.2090907@isode.com> Date: Tue, 23 Nov 2004 22:43:59 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] comments on draft-ietf-lemonade-urlauth-04.txt (fwd) 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.4 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Mark Crispin wrote: > I have received the following comments on draft 04. Unless there is > an objection in the next day or two, I propose to act affirmatively on > all of these comments and produce a draft 05. > > I do not think that any of these changes invalidate the WGLC on 04. > In my opinion, they are all minor, fall into the category of > clarification, and will result in a superior document. > > ---------- Forwarded message ---------- > > [...] > Shouldn't both RESETKEY and GENURLAUTH require that the user be > able to access the mailbox named in the command or URL? Should the > server check whether the indicated message both exists and has the > indicated part? I've added the following text to the next revision of the RFC 2086 (ACL) document: RESETKEY - "r" right is required for each mailbox affected by the command. In particular the RESETKEY MUST NOT reset keys on mailboxes that can't be SELECT/EXAMINEd by the current user. GENURLAUTH - "r" right is required for each mailbox referenced in the URL(s) specified as parameter(s) to the GENURLAUTH command. URLFETCH - no rights required to perform this operation. ========= More comments: section about URLFETCH Command has the following note: Note: This command does not require that the URL refer to the selected mailbox; nor does it require that any mailbox be selected. It also does not in any way interfere with any selected mailbox. I think the same note should be added for the GENURLAUTH command. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 07:06:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14962 for ; Wed, 24 Nov 2004 07:06:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWvyR-0002Hc-Mh for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 07:10:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWvtm-00068J-De; Wed, 24 Nov 2004 07:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWvqh-0005Ot-N8 for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 07:02:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14400 for ; Wed, 24 Nov 2004 07:02:12 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWvuX-0001w9-Sc for lemonade@ietf.org; Wed, 24 Nov 2004 07:06:15 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 24 Nov 2004 12:01:38 +0000 Message-ID: <41A47820.4070000@isode.com> Date: Wed, 24 Nov 2004 12:01:36 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Pete Resnick Subject: Re: [lemonade] WGLC's References: <41A11680.6050109@isode.com> <41A392B9.1030604@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: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Pete Resnick wrote: > On 11/23/04 at 7:42 PM +0000, Alexey Melnikov wrote: > >> Pete Resnick wrote: >> >>> By putting it in an astring, you're requiring implementations to go >>> through and esacpe backslashes and double-quotes. We all know that >>> implementations will screw this up. >> >> As I understand it, just doing <"> url <"> should suffice. > > "Should" is the key. The concern is that you're going to get a "\" or > a <"> in a URL, at which point you're going to have to escape them > with "\". So the algorithm will inevitably be to do the escaping. From RFC 1738: > Unsafe: > > Characters can be unsafe for a number of reasons. The space > character is unsafe because significant spaces may disappear and > insignificant spaces may be introduced when URLs are transcribed or > typeset or subjected to the treatment of word-processing programs. > The characters "<" and ">" are unsafe because they are used as the > delimiters around URLs in free text; the quote mark (""") is used to > delimit URLs in some systems. The character "#" is unsafe and should > always be encoded because it is used in World Wide Web and in other > systems to delimit a URL from a fragment/anchor identifier that might > follow it. The character "%" is unsafe because it is used for > encodings of other characters. Other characters are unsafe because > gateways and other transport agents are known to sometimes modify > such characters. These characters are "{", "}", "|", "\", "^", "~", > "[", "]", and "`". > > All unsafe characters must always be encoded within a URL. My reading of this is that unencoded "\" and <"> are not allowed in URLs, so you must ignore "should" in my previous statement ;-). The server has to check for URL validity anyway. The main question is - should this cause IMAP protocol error, i.e. the server tries to decode an invalid URL sent as a quoted string and fails (<"> <">), because some characters are not escaped, or should IMAP parsing succeed and the URL be rejected during URL validity check. >> Anyway, escape rules for quoted strings are well understood. >> Borrowing existing function for sending a quoted string from c-client >> or Cyrus should be no brainer. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 13:50:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19785 for ; Wed, 24 Nov 2004 13:50:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2Hb-0003AM-JV for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 13:54:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2DA-0007pY-Ct; Wed, 24 Nov 2004 13:49:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX25a-0005sG-Vm for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 13:42:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19168 for ; Wed, 24 Nov 2004 13:42:01 -0500 (EST) 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.33) id 1CX29K-0002vo-Sf for lemonade@ietf.org; Wed, 24 Nov 2004 13:46:06 -0500 Received: from [130.129.135.164] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Wed, 24 Nov 2004 12:41:11 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <41A47820.4070000@isode.com> References: <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Wed, 24 Nov 2004 12:41:06 -0600 To: Alexey Melnikov From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On 11/24/04 at 12:01 PM +0000, Alexey Melnikov wrote: > > Characters can be unsafe for a number of reasons. The space > > character is unsafe because significant spaces may disappear and > > insignificant spaces may be introduced when URLs are transcribed or > > typeset or subjected to the treatment of word-processing programs. > > The characters "<" and ">" are unsafe because they are used as the > > delimiters around URLs in free text; the quote mark (""") is used to > > delimit URLs in some systems. The character "#" is unsafe and should > > always be encoded because it is used in World Wide Web and in other > > systems to delimit a URL from a fragment/anchor identifier that might > > follow it. The character "%" is unsafe because it is used for > > encodings of other characters. Other characters are unsafe because > > gateways and other transport agents are known to sometimes modify > > such characters. These characters are "{", "}", "|", "\", "^", "~", >> "[", "]", and "`". >> >> All unsafe characters must always be encoded within a URL. > >My reading of this is that unencoded "\" and <"> are not allowed in >URLs, so you must ignore "should" in my previous statement ;-). Well, right, but the same is true of "]" and " ", and if everyone followed the rules, we wouldn't even need to have this conversation: IMAP servers implementations wouldn't need the astring because they could simply look for the next space and be done with it. And if we really trust that client implementors will send only valid URLs, we should just leave things as they are. >The server has to check for URL validity anyway. The main question >is - should this cause IMAP protocol error, i.e. the server tries to >decode an invalid URL sent as a quoted string and fails (<"> ><">), because some characters are not escaped, or should IMAP >parsing succeed and the URL be rejected during URL validity check. So, as I was saying before, the only chance of an IMAP protocol error in the command itself is if a client sends a URL with a space in it. I think the odds of that happening are lower than an client screwing up astring escaping of a URL, so my opinion is to leave the command syntax alone. I am less sanguine about the response code (since a client could screw that up by including a "]"), but I'm willing to buy that the odds are low enough there too. Do we really think that complicating the syntax is worth it for clients who are able to get astring escaping correct but can't get URL escaping right? -- 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 From lemonade-bounces@ietf.org Wed Nov 24 14:10:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20802 for ; Wed, 24 Nov 2004 14:10:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2b6-0003cv-2V for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 14:14:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2Vx-0002Do-OL; Wed, 24 Nov 2004 14:09:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2Sz-0001d9-Gv for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 14:06:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20579 for ; Wed, 24 Nov 2004 14:06:11 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2Wt-0003W4-Ka for lemonade@ietf.org; Wed, 24 Nov 2004 14:10:17 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAOJ69vi013314 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 24 Nov 2004 11:06:09 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAOJ69vi013314 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=aTLwr1G+3xemkF5ovVs7N486nVCLbpGgzdTUQ8TG744eH+vPONVV7QDFd975dcwxN CsEw1DbwcFJv8k2I8Dli2S8fs74iIB7PihLCpdtPS8mwr6tbLKW124TQ3+b+UvWLfPK UsMht4wruQC63o+Sgfavpq9V6P5IXUEb0PNIBb8= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAOJ69c1071947; Wed, 24 Nov 2004 11:06:09 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411241906.iAOJ69c1071947@lab.smi.sendmail.com> To: Pete Resnick From: Philip Guenther Subject: Re: [lemonade] WGLC's In-reply-to: References: <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> Date: Wed, 24 Nov 2004 11:06:09 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org, Alexey Melnikov , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Pete Resnick writes: ... >Well, right, but the same is true of "]" and " ", and if everyone >followed the rules, we wouldn't even need to have this conversation: >IMAP servers implementations wouldn't need the astring because they >could simply look for the next space and be done with it. And if we >really trust that client implementors will send only valid URLs, we >should just leave things as they are. The problems wasn't so much with "]" or " ", but rather with "(", ")", "*", and "%", all of which are legal in URLs (and mailbox names) but not in IMAP atoms. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 14:30:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21888 for ; Wed, 24 Nov 2004 14:30:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2uS-000437-Sn for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 14:34:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2mJ-00066s-Oy; Wed, 24 Nov 2004 14:26:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2ld-0005ul-5v for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 14:25:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21667 for ; Wed, 24 Nov 2004 14:25:27 -0500 (EST) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2pY-0003wn-97 for lemonade@ietf.org; Wed, 24 Nov 2004 14:29:32 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAOJPOIG031498; Wed, 24 Nov 2004 11:25:25 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAOJPOKX012128; Wed, 24 Nov 2004 11:25:24 -0800 Date: Wed, 24 Nov 2004 11:25:24 -0800 (PST) From: Mark Crispin To: Pete Resnick Subject: Re: [lemonade] WGLC's In-Reply-To: Message-ID: References: <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c On Wed, 24 Nov 2004, Pete Resnick wrote: > Do we really think that complicating the syntax is worth it for clients > who are able to get astring escaping correct but can't get URL escaping > right? My opinion: it complicates the syntax worse to add a new type of token that is "everything up to the next space" (but not really, since it actually is the entire set of rules for URL), than it does to use an existing syntax rule -- astring. As a server implementor, I very much want to parse an astring rather than to write a completely new syntax rule. If the consensus is to do the "everything up to the next space", then I insist that a completely new syntax rule be written for IMAP that defines this rule. Something like: urlatom = 1*urlatomchar urlatomchar = ATOM-CHAR / "(" / ")" / "{" / CTL / list-wildcards / quoted-specials / resp-specials / urlhighchar urlhighchar = %x80-ff Not nice? Didn't think so. But that is, literally, the "everything up to the next space rule". If we dispense with any reference to other IMAP rules, then we may have something like: urlatom = 1*urlatomchar urlatomchar = %x01-09 / %x0b / %0x0d-1f / %0x21-ff Not so nice either. Or, if we exclude those characters that can't be in URLs (which is quite a bit different than "everything up to the next space"), we have an entirely different set of rules. But then we can't use "everything up to the next space". And, of course, it has to track any changes made to URLs. Now, doesn't astring seem to be sooooooo much less complicated now? :-) -- 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 From lemonade-bounces@ietf.org Wed Nov 24 14:32:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22019 for ; Wed, 24 Nov 2004 14:32:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2we-00046g-ED for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 14:36:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2rJ-00070z-Ft; Wed, 24 Nov 2004 14:31:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2ne-0006EL-6b for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 14:27:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21772 for ; Wed, 24 Nov 2004 14:27:32 -0500 (EST) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2rY-00040S-Iq for lemonade@ietf.org; Wed, 24 Nov 2004 14:31:37 -0500 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAOJRV3v014091; Wed, 24 Nov 2004 11:27:31 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAOJRVho012177; Wed, 24 Nov 2004 11:27:31 -0800 Date: Wed, 24 Nov 2004 11:27:31 -0800 (PST) From: Mark Crispin To: Philip Guenther Subject: Re: [lemonade] WGLC's In-Reply-To: <200411241850.iAOIo73h070860@lab.smi.sendmail.com> Message-ID: References: <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Pete Resnick , Alexey Melnikov , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Wed, 24 Nov 2004, Philip Guenther wrote: > The IMAP base spec doesn't (that I see) require the server to, for > example, throw away everything up to the next newline when it receives a > CREATE command with a misquoted mailbox name Once upon a time, it did. This was widely considered to have been a mistake, and it was amended. There have been no "rest of line" or "everything up to the next space" rules in IMAP for over a decade. Hence my attempt to resist adding such now. -- 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 From lemonade-bounces@ietf.org Wed Nov 24 14:54:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23663 for ; Wed, 24 Nov 2004 14:54:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3Hv-0004ad-UN for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 14:58:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX396-0002np-U6; Wed, 24 Nov 2004 14:49:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX34n-0001PB-An for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 14:45:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22992 for ; Wed, 24 Nov 2004 14:45:15 -0500 (EST) 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.33) id 1CX38h-0004Lk-Vj for lemonade@ietf.org; Wed, 24 Nov 2004 14:49:21 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Wed, 24 Nov 2004 13:44:36 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Wed, 24 Nov 2004 13:44:31 -0600 To: Philip Guenther From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 (* Pete has the "aha!" moment *) On 11/24/04 at 11:27 AM -0800, Mark Crispin wrote: >This was widely considered to have been a mistake, and it was >amended. There have been no "rest of line" or "everything up to the >next space" rules in IMAP for over a decade. OK, so this is about current parsing rules being relatively well defined and introducing the new one *does* complicate things. This makes a little more sense now. But let me get back to Philip's earlier comment, which I don't get: On 11/22/04 at 7:47 PM -0800, Philip Guenther wrote: >Can't use plain 'astring', as that would make the grammar ambiguous: >is a literal an imapurl or just text to include? I don't see how this is ambiguous. A literal is *always* text to include. Literals begin with "{". If it doesn't begin with "{", it's an astring which must be a URL. Care to explain why astring is not sufficient? 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 From lemonade-bounces@ietf.org Wed Nov 24 15:02:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24241 for ; Wed, 24 Nov 2004 15:02:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3Oy-0004nT-3Z for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 15:06:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3HN-0005HI-EX; Wed, 24 Nov 2004 14:58:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3Eu-0004XR-7s for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 14:55:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23796 for ; Wed, 24 Nov 2004 14:55:42 -0500 (EST) 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.33) id 1CX3Ip-0004bK-0w for lemonade@ietf.org; Wed, 24 Nov 2004 14:59:48 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Wed, 24 Nov 2004 13:55:12 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Wed, 24 Nov 2004 13:55:06 -0600 To: lemonade@ietf.org From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Philip Guenther , 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 [And everybody pause while Pete answer's his own question again....] On 11/24/04 at 1:44 PM -0600, Pete Resnick wrote: >I don't see how this is ambiguous. A literal is *always* text to >include. Literals begin with "{". If it doesn't begin with "{", it's >an astring which must be a URL. Care to explain why astring is not >sufficient? Because astring contains string which contains literal. Now editing in Philip's syntax. -- 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 From lemonade-bounces@ietf.org Wed Nov 24 15:09:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25204 for ; Wed, 24 Nov 2004 15:09:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3W1-0004ym-Pw for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 15:13:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3Nr-0003Yu-NZ; Wed, 24 Nov 2004 15:04:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3In-0005WR-Ho for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 14:59:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24057 for ; Wed, 24 Nov 2004 14:59:43 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3Mj-0004jX-2F for lemonade@ietf.org; Wed, 24 Nov 2004 15:03:49 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAOJxeqj031590 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 24 Nov 2004 11:59:40 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAOJxeqj031590 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=os9MHh44Zi/jOSfhgDjVB7VbMC+buJDJp3xiFjvpXow2PlFUUMiwR+qR6q6LSn8df FHae+v/RnK8ALFIxVcBK9P9/83vZV7SFHw2neLCgUDJ88m/4koj2Qp7sLbKGp7DYUcD 9qnO1YUb1iSi93Q9+fWmOMcLvx5TYuQAKgIun5U= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAOJxekk075776; Wed, 24 Nov 2004 11:59:40 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411241959.iAOJxekk075776@lab.smi.sendmail.com> To: Pete Resnick From: Philip Guenther Subject: Re: [lemonade] WGLC's In-reply-to: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> Date: Wed, 24 Nov 2004 11:59:40 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org, 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Pete Resnick writes: >But let me get back to Philip's earlier comment, which I don't get: > >On 11/22/04 at 7:47 PM -0800, Philip Guenther wrote: > >>Can't use plain 'astring', as that would make the grammar ambiguous: >>is a literal an imapurl or just text to include? > >I don't see how this is ambiguous. A literal is *always* text to >include. Literals begin with "{". If it doesn't begin with "{", it's >an astring which must be a URL. Care to explain why astring is not >sufficient? reduce/reduce conflict: astring = 1*ASTRING-CHAR / string string = quoted / literal So a literal is an astring too. If you're thinking that a literal would be 'reduced' directly as text to include instead of as a form of astring holding a URL, then that should be directly expressed by the grammar, ala: catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] 1*(SP (literal / url)) url = atom / quoted I find that unpleasant, as it creates a situation where a quoted string has different semantics than a literal with the same value. Thus my suggestion to 'tag' URLs and use astring for them. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 15:21:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27467 for ; Wed, 24 Nov 2004 15:21:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3i6-0005MR-68 for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 15:25:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3be-0004Oy-Hg; Wed, 24 Nov 2004 15:19:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3Uf-00008p-LW for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 15:12:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25697 for ; Wed, 24 Nov 2004 15:11:59 -0500 (EST) 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.33) id 1CX3Ya-00053X-Ga for lemonade@ietf.org; Wed, 24 Nov 2004 15:16:05 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5) for ; Wed, 24 Nov 2004 14:11:29 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Wed, 24 Nov 2004 14:11:24 -0600 To: Lemonade From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On 11/24/04 at 1:55 PM -0600, I wrote: >Now editing in Philip's syntax. OK, taking Mark's, Alexey's, and Philip's recommendations and a little ABNF cleanup, does this make everyone queasy or happy? catenate = "CATENATE" SP mailbox SP parameters 1*(SP (text-literal / url)) parameters = ("(" parameter *(SP parameter) ")") / "NIL" parameter = ("FLAGS" SP flag-list) / ("DATE" SP date-time) text-literal = "TEXT" SP literal url = "URL" SP astring ; astring contains an imapurl as defined by badurl_response_code = "BADURL" SP astring ; astring contains an imapurl as defined by -- 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 From lemonade-bounces@ietf.org Wed Nov 24 16:03:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02012 for ; Wed, 24 Nov 2004 16:03:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4MB-0006Uj-M0 for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 16:07:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4HF-0002U4-2E; Wed, 24 Nov 2004 16:02:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4DK-0000Ah-Nt for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 15:58:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01615 for ; Wed, 24 Nov 2004 15:58:08 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4HF-0006Ma-TT for lemonade@ietf.org; Wed, 24 Nov 2004 16:02:15 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAOKw7bC016011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 24 Nov 2004 12:58:08 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAOKw7bC016011 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=AeV1n3Sao0rL/TpmAsafX1miMRz/WKaWqAbQH2hW94kP6zoNbmbFhf5yEQF6wBDfM vmUtZQ+QzQtW8pH+aUHCZ49sLRdCwXzos5r3IrE0ImloSKYHZcSxaPovys/+sRf/e08 AesNXv7I2xPqiL6YIl8T+rR8y9cILkk6Un9KGFI= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAOKw7AG080181; Wed, 24 Nov 2004 12:58:07 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411242058.iAOKw7AG080181@lab.smi.sendmail.com> To: Pete Resnick From: Philip Guenther Subject: Re: [lemonade] WGLC's In-reply-to: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> Date: Wed, 24 Nov 2004 12:58:07 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 One issue: response codes can't contain literals. When this was recently discussed on the IMAP list for the BADCHARSET case, it resulted in an erratum that adds a charset = atom / quoted production, then used that in both the BADCHARSET response code and for the CHARSET argument to SEARCH. That precedent would suggest having both badurl_response_code and url refer to an "atom / quoted" production. Tweaking a couple names to be less generic, how about: command-auth =/ catenate catenate = "CATENATE" SP mailbox SP catenate-params 1*(SP (text-literal / catenate-url)) catenate-params = ("(" catenate-param *(SP catenate-param) ")") / "NIL" catenate-param = ("FLAGS" SP flag-list) / ("DATE" SP date-time) text-literal = "TEXT" SP literal catenate-url = "URL" SP url url = atom / quoted ; contains an imapurl as defined by ; resp-text-code =/ badurl-resp-code badurl-resp-code = "BADURL" SP url Philip Guenther (Hmm, when the I18N stuff is finished and the SORT/THREAD rfc is unblocked, the latter should be edited to reference the 'charset' non-terminal too.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 16:05:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02163 for ; Wed, 24 Nov 2004 16:05:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4O6-0006XY-UD for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 16:09:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4Hb-0002jv-MH; Wed, 24 Nov 2004 16:02:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4H3-0002FO-Gl for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 16:02:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01829 for ; Wed, 24 Nov 2004 16:01:59 -0500 (EST) 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.33) id 1CX4Ky-0006Ra-Pg for lemonade@ietf.org; Wed, 24 Nov 2004 16:06:06 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Wed, 24 Nov 2004 15:01:22 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200411242058.iAOKw7AG080181@lab.smi.sendmail.com> References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> <200411242058.iAOKw7AG080181@lab.smi.sendmail.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Wed, 24 Nov 2004 15:01:17 -0600 To: Philip Guenther From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On 11/24/04 at 12:58 PM -0800, Philip Guenther wrote: >That precedent would suggest having both badurl_response_code and >url refer to an "atom / quoted" production. If we're going to go down that road, is there a reason to introduce the "URL" and "TEXT" (or for that matter "FLAGS" and "DATE") tags, since there won't be any ambiguity between literal and url? 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 From lemonade-bounces@ietf.org Wed Nov 24 16:19:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05009 for ; Wed, 24 Nov 2004 16:19:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4bk-0006xS-S5 for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 16:23:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4W0-0003Kh-4i; Wed, 24 Nov 2004 16:17:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4T3-0001Wa-G4 for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 16:14:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04088 for ; Wed, 24 Nov 2004 16:14:22 -0500 (EST) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4Wy-0006no-F1 for lemonade@ietf.org; Wed, 24 Nov 2004 16:18:29 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAOLEMRk001326; Wed, 24 Nov 2004 13:14:22 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAOLELIh023717 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Nov 2004 13:14:21 -0800 Date: Wed, 24 Nov 2004 13:16:23 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Resnick Subject: Re: [lemonade] WGLC's In-Reply-To: Message-ID: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> <200411242058.iAOKw7AG080181@lab.smi.sendmail.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Philip Guenther , Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Wed, 24 Nov 2004, Pete Resnick wrote: >> That precedent would suggest having both badurl_response_code and url refer >> to an "atom / quoted" production. > If we're going to go down that road, is there a reason to introduce the "URL" > and "TEXT" (or for that matter "FLAGS" and "DATE") tags, since there won't be > any ambiguity between literal and url? Unlike commands, there is precedent for response codes to use "rest of code". So, yes, URLs would use a different production for response code and command. -- 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 From lemonade-bounces@ietf.org Wed Nov 24 16:24:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05577 for ; Wed, 24 Nov 2004 16:24:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4gp-00076z-ES for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 16:28:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4Yr-0005Ed-7X; Wed, 24 Nov 2004 16:20:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4WA-0003Sw-R8 for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 16:17:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04867 for ; Wed, 24 Nov 2004 16:17:36 -0500 (EST) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4a6-0006ul-5a for lemonade@ietf.org; Wed, 24 Nov 2004 16:21:43 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAOLHZWH001951; Wed, 24 Nov 2004 13:17:36 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAOLHZa5024179 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Nov 2004 13:17:35 -0800 Date: Wed, 24 Nov 2004 13:19:37 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Resnick Subject: Re: [lemonade] WGLC's In-Reply-To: Message-ID: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Wed, 24 Nov 2004, Pete Resnick wrote: > OK, taking Mark's, Alexey's, and Philip's recommendations and a little ABNF > cleanup, does this make everyone queasy or happy? Very close. Just one change to badurl-response-code: badurl-response-code = "BADURL" SP 1* ; value contains an imapurl as defined by -- 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 From lemonade-bounces@ietf.org Wed Nov 24 16:28:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05905 for ; Wed, 24 Nov 2004 16:28:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4kw-0007D7-2Q for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 16:32:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4fb-0000X7-IT; Wed, 24 Nov 2004 16:27:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4d8-0007T5-SI for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 16:24:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05626 for ; Wed, 24 Nov 2004 16:24:48 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4h4-00077Q-8Y for lemonade@ietf.org; Wed, 24 Nov 2004 16:28:55 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAOLOjMh024524 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 24 Nov 2004 13:24:46 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAOLOjMh024524 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=mMwLuZqlx6PHxUDts9mNEmoCyuYB37Jv94mv+Zz3gca2KSRojtfqZbxUtiOyCRVWL yp6jLZinwmdosCBOAI9ZfXtv+q9gzVg3ftjFo8NVbqUdDMrxrYnbNE53n3vwzumeLRw Sf7Kggcj122KWdS9B2KloYyfTiXDu1ud7Kd8u0w= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAOLOjSl082332; Wed, 24 Nov 2004 13:24:45 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411242124.iAOLOjSl082332@lab.smi.sendmail.com> To: Pete Resnick From: Philip Guenther Subject: Re: [lemonade] WGLC's In-reply-to: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> <200411242058.iAOKw7AG080181@lab.smi.sendmail.com> Date: Wed, 24 Nov 2004 13:24:45 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Pete Resnick writes: >On 11/24/04 at 12:58 PM -0800, Philip Guenther wrote: > >>That precedent would suggest having both badurl_response_code and >>url refer to an "atom / quoted" production. > >If we're going to go down that road, is there a reason to introduce >the "URL" and "TEXT" (or for that matter "FLAGS" and "DATE") tags, >since there won't be any ambiguity between literal and url? ...thus my hair tearing comment. IMHO, there's a difference between simply restricting how certain values are expressed and changing the semantics of a value depending on how it is expressed. I believe APPEND is the only command where the semantics of a given argument depend upon whether it is a quoted string or a literal. We should not replicate that situation. Hmm, that actually suggests an ambiguity of sorts in the tagless syntax: if the first thing after the flag list is a quoted string, you have to examine the value of the string to decide whether it's a date-time or a URL. Please, let's keep the tagged syntax. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 16:37:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06445 for ; Wed, 24 Nov 2004 16:37:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4t7-0007M1-J6 for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 16:41:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4ox-00021I-7K; Wed, 24 Nov 2004 16:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4jP-0001Kv-Do for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 16:31:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06020 for ; Wed, 24 Nov 2004 16:31:16 -0500 (EST) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4nK-0007EM-L9 for lemonade@ietf.org; Wed, 24 Nov 2004 16:35:24 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAOLVGb7004033; Wed, 24 Nov 2004 13:31:16 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAOLVFaG012485 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Nov 2004 13:31:16 -0800 Date: Wed, 24 Nov 2004 13:33:17 -0800 (Pacific Standard Time) From: Mark Crispin To: Philip Guenther Subject: Re: [lemonade] WGLC's In-Reply-To: <200411242124.iAOLOjSl082332@lab.smi.sendmail.com> Message-ID: References: <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> <200411242058.iAOKw7AG080181@lab.smi.sendmail.com> <200411242124.iAOLOjSl082332@lab.smi.sendmail.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Pete Resnick , Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Wed, 24 Nov 2004, Philip Guenther wrote: > I believe APPEND is the only command where the semantics > of a given argument depend upon whether it is a quoted string or a > literal. We should not replicate that situation. Strong agreement. APPEND is a wart on the beautiful face of IMAP. It is too late to remote that wart, but we can avoid adding another one. :-) > Please, let's keep the tagged syntax. Hear, hear! -- 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 From lemonade-bounces@ietf.org Wed Nov 24 16:52:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07341 for ; Wed, 24 Nov 2004 16:52:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX57l-0007dm-SA for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 16:56:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX50i-0005YQ-8k; Wed, 24 Nov 2004 16:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4zF-00055q-Eq for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 16:47:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07044 for ; Wed, 24 Nov 2004 16:47:38 -0500 (EST) 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.33) id 1CX53C-0007XF-3w for lemonade@ietf.org; Wed, 24 Nov 2004 16:51:46 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Wed, 24 Nov 2004 15:47:05 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Wed, 24 Nov 2004 15:47:01 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: [lemonade] WGLC's Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On 11/24/04 at 1:19 PM -0800, Mark Crispin wrote: >On Wed, 24 Nov 2004, Pete Resnick wrote: >>OK, taking Mark's, Alexey's, and Philip's recommendations and a >>little ABNF cleanup, does this make everyone queasy or happy? > >Very close. Just one change to badurl-response-code: > >badurl-response-code = "BADURL" SP 1* OK, except that I did the explicit ABNF for "any TEXT-CHAR except ']'" in a separate url-resp-text: badurl_response_code = "BADURL" SP url-text url-resp-text= 1*(%x01-09 / %x0B-0C / %x0E-5B / %x5D-FE) ; Any TEXT-CHAR except "]" Now, what should the description of the command be? That is: Arguments: mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string one or more message parts to catenate, specified as: message literal or message (or message part) URL I can come up with the descriptive text, but I'd appreciate help on what would make the above clearest. 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 From lemonade-bounces@ietf.org Wed Nov 24 17:25:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09589 for ; Wed, 24 Nov 2004 17:25:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5db-0008H2-HB for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 17:29:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5Xn-00041Q-Uq; Wed, 24 Nov 2004 17:23:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5Wl-0003r0-Ck for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 17:22:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09247 for ; Wed, 24 Nov 2004 17:22:16 -0500 (EST) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5ai-0008D0-2M for lemonade@ietf.org; Wed, 24 Nov 2004 17:26:24 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAOMMHxC005336; Wed, 24 Nov 2004 14:22:17 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAOMMHUj032745 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Nov 2004 14:22:17 -0800 Date: Wed, 24 Nov 2004 14:24:18 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Resnick Subject: Re: [lemonade] WGLC's In-Reply-To: Message-ID: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Wed, 24 Nov 2004, Pete Resnick wrote: > OK, except that I did the explicit ABNF for "any TEXT-CHAR except ']'" in a > separate url-resp-text: Fine with me! > Now, what should the description of the command be? That is: > > Arguments: mailbox name > OPTIONAL flag parenthesized list > OPTIONAL date/time string > one or more message parts to catenate, specified as: > message literal > or > message (or message part) URL I suggest leaving it at "one or more message parts to catenate", and then let the textual description below describe it further. That is: Arguments: mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string one or more message parts to catenate [. . .] A message part consists of a message part name followed by the message part value. The current part names are URL and TEXT. The URL part blah blah blah The TEXT part blah blah blah My last suggestion is to consider a word other than part, to avoid confusion with MIME parts (since RFC 3501 uses "part" in that context). Perhaps "message text component"? -- 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 From lemonade-bounces@ietf.org Wed Nov 24 18:06:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13309 for ; Wed, 24 Nov 2004 18:06:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6HV-0000la-6R for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 18:10:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6AK-0005Zt-DS; Wed, 24 Nov 2004 18:03:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX68Y-0003Sa-Fe for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 18:01:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12533 for ; Wed, 24 Nov 2004 18:01:19 -0500 (EST) Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6CT-0000dX-L1 for lemonade@ietf.org; Wed, 24 Nov 2004 18:05:28 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAON1CRT019764 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 24 Nov 2004 15:01:12 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAON1CRT019764 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=KMkffzdlhMD9++kyJyMhFtYOZOX8A2Ow5CDjv58KQxq35bbRtjvs/W1yCkWUq+9OY pXVPmB37MuJ1X6ayBejqtT0pHK0Vw739P1gTGyoOThCjfQ9NKSgxj5T3SYXXz6IsZVm pGiZ7askya26OzAVVJYQO8f3BlvZjino/8QCLY0= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAON1CUj089132; Wed, 24 Nov 2004 15:01:12 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411242301.iAON1CUj089132@lab.smi.sendmail.com> To: Mark Crispin From: Philip Guenther Subject: Re: [lemonade] WGLC's In-reply-to: References: <41A11680.6050109@isode.com> <200411230347.iAN3lBlp009951@lab.smi.sendmail.com> <41A11680.6050109@isode.com> <41A392B9.1030604@isode.com> <41A47820.4070000@isode.com> <200411241850.iAOIo73h070860@lab.smi.sendmail.com> Date: Wed, 24 Nov 2004 15:01:12 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Pete Resnick , Lemonade 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Mark Crispin writes: ... > OPTIONAL flag parenthesized list > OPTIONAL date/time string ... Those should be replaced with message parameter list or NIL The currently defined message parameters are FLAGS and DATE. etc. Hmm, the new syntax would make extension to multi-message injection unambiguous: an open paren or NIL tag would start the description of the next message to catenate. Did we decide "not going there"? Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 18:52:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17870 for ; Wed, 24 Nov 2004 18:52:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6zn-0001hz-4g for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 18:56:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6un-0002LF-M6; Wed, 24 Nov 2004 18:51:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6rU-0001nu-QF for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 18:47:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17718 for ; Wed, 24 Nov 2004 18:47:45 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6vR-0001dI-GP for lemonade@ietf.org; Wed, 24 Nov 2004 18:51:54 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAONlav28798; Thu, 25 Nov 2004 01:47:36 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 01:47:02 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAONl2pj032399; Thu, 25 Nov 2004 01:47:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00njuEQ5; Thu, 25 Nov 2004 01:47:01 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAONkxa29099; Thu, 25 Nov 2004 01:46:59 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 Nov 2004 17:46:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Channel updates for content conversion Date: Wed, 24 Nov 2004 17:46:54 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC7@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Channel updates for content conversion thread-index: AcTR24GvGY9ArzIGRFirwIsn1wWV8gAojEZQ To: , X-OriginalArrivalTime: 24 Nov 2004 23:46:55.0373 (UTC) FILETIME=[E12D2BD0:01C4D27F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Lyndon Nerenberg [mailto:lyndon@orthanc.ca] > Sent: Tuesday, November 23, 2004 11:08 PM ... > --On 2004-11-23 9:24 AM -0600 Michael.Wener@nokia.com wrote: >=20 > > How do you communicate that a conversion between top level > > media types is permitted? For example from pdf to plain > > text. >=20 > Advertise text/plain as a target conversion type. I think of conversion as a function with a Domain and Range. CHANNELCONVERSIONS returns the Range. You seem to be assuming the Domain to be the universe of all content types, which is=20 reasonable. How do I know what the mapping is? For example=20 the following conversion makes no sense: Convert(application/pdf) =3D audio/basic Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 24 19:10:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19277 for ; Wed, 24 Nov 2004 19:10:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX7HX-00029Z-K5 for lemonade-web-archive@ietf.org; Wed, 24 Nov 2004 19:14:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX7BK-000676-KH; Wed, 24 Nov 2004 19:08:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX77S-0005Mv-SU for lemonade@megatron.ietf.org; Wed, 24 Nov 2004 19:04:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18713 for ; Wed, 24 Nov 2004 19:04:15 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX7BP-0001yi-LT for lemonade@ietf.org; Wed, 24 Nov 2004 19:08:25 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAP045000405; Thu, 25 Nov 2004 02:04:08 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 02:03:35 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAP03ZK3003335; Thu, 25 Nov 2004 02:03:35 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 009bCrBL; Thu, 25 Nov 2004 02:03:33 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAP03Ua10624; Thu, 25 Nov 2004 02:03:31 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 Nov 2004 18:02:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Channel updates for content conversion Date: Wed, 24 Nov 2004 18:02:54 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC8@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Channel updates for content conversion thread-index: AcTR3CRnIUOnLK5rSnu7e6fCcY9LdwAo/Ecg To: X-OriginalArrivalTime: 25 Nov 2004 00:02:53.0742 (UTC) FILETIME=[1C68ACE0:01C4D282] X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Lyndon Nerenberg [mailto:lyndon@orthanc.ca] > Sent: Tuesday, November 23, 2004 11:13 PM ... > > I would like to see a mechanism that allowed for partial=20 > retrieval in > > the case of in-band. >=20 > Where would this be useful? Channel was instigated in part because=20 > Fetch with partials was not sufficient for some clients.=20 > Partial fetch=20 > was being misused to fake out streaming downloads. That didn't work.=20 > Channel is an attempt to fix that. So in the context of Channel, why=20 > (and how) would a partial fetch be useful. When Channel is used as a mechanism for streaming it wouldn't be=20 useful, but you've overloaded CHANNEL to do conversions. A=20 conversion does not necessarily imply a streaming use case. So=20 the usefulness of partial retrieval would be the same as in=20 FETCH. Maybe I'm missing something from the discussion had in Vancouver. I=20 read the minutes. I understood the CHANNEL conversion proposal as=20 meeting option A)? Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 25 12:56:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03782 for ; Thu, 25 Nov 2004 12:56:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXNv8-0001RR-6D for lemonade-web-archive@ietf.org; Thu, 25 Nov 2004 13:00:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXNmt-0002Ej-TS; Thu, 25 Nov 2004 12:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXNkK-0001OM-2t for lemonade@megatron.ietf.org; Thu, 25 Nov 2004 12:49:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03290 for ; Thu, 25 Nov 2004 12:49:29 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXNoR-0001Gj-99 for lemonade@ietf.org; Thu, 25 Nov 2004 12:53:47 -0500 Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAPHnNL9059228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Nov 2004 10:49:25 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 25 Nov 2004 09:49:23 -0800 From: Lyndon Nerenberg To: Michael.Wener@nokia.com, lemonade@ietf.org Subject: RE: [lemonade] Channel updates for content conversion Message-ID: In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC7@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BC7@daebe005.americas. nokia.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-SdV-Metrics: orthanc.ca 1179; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit --On 2004-11-24 5:46 PM -0600 Michael.Wener@nokia.com wrote: > I think of conversion as a function with a Domain and Range. > CHANNELCONVERSIONS returns the Range. You seem to be assuming > the Domain to be the universe of all content types, which is > reasonable. How do I know what the mapping is? The client is assumed to know about the conversions it is performing. E.g. one assumes that a reasonable client won't ask a server to convert audio/basic to text/plain. Enumerating the list of all possible transformations is potentially very verbose. And even with the list, the client still has to make an intelligent decision about the transformation. You have to assume some intelligence on the part of the client. If it's presented with an image/jpeg and cannot handle the JPEG format, but can display GIF, then the presence or absence of 'image/gif' in the CHANNELCONVERSIONS output is a strong hint that the conversion will work. If the client asks to convert that image/jpeg to a text/plain, it deserves what it gets. (A NO response.) > For example > the following conversion makes no sense: > > Convert(application/pdf) = audio/basic And the server would return a tagged NO response, since it is unable to perform the requested conversion. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 29 08:41:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20226 for ; Mon, 29 Nov 2004 08:41:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlrQ-0001MA-Tz for lemonade-web-archive@ietf.org; Mon, 29 Nov 2004 08:46:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlj8-00075z-Nt; Mon, 29 Nov 2004 08:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlaN-0005AK-Lr for lemonade@megatron.ietf.org; Mon, 29 Nov 2004 08:28:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18824 for ; Mon, 29 Nov 2004 08:28:58 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlfI-00011U-2m for lemonade@ietf.org; Mon, 29 Nov 2004 08:34:04 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iATDSho28874; Mon, 29 Nov 2004 15:28:44 +0200 (EET) X-Scanned: Mon, 29 Nov 2004 15:28:18 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iATDSIn0016442; Mon, 29 Nov 2004 15:28:18 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00YHehy1; Mon, 29 Nov 2004 15:27:52 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iATDRia24400; Mon, 29 Nov 2004 15:27:45 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Nov 2004 07:27:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Channel updates for content conversion Date: Mon, 29 Nov 2004 07:27:28 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BCD@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Channel updates for content conversion thread-index: AcTTF2ak17ggfgl8QyitTaDTtb3X7QC+zweg To: , X-OriginalArrivalTime: 29 Nov 2004 13:27:29.0300 (UTC) FILETIME=[2C893D40:01C4D617] X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Lyndon Nerenberg [mailto:lyndon@orthanc.ca] > Sent: Thursday, November 25, 2004 12:49 PM ... > > I think of conversion as a function with a Domain and Range. > > CHANNELCONVERSIONS returns the Range. You seem to be assuming > > the Domain to be the universe of all content types, which is > > reasonable. How do I know what the mapping is? >=20 > The client is assumed to know about the conversions it is performing.=20 > E.g. one assumes that a reasonable client won't ask a server=20 > to convert=20 > audio/basic to text/plain. Agreed. I'm assuming a client is completely intelligent from it's=20 perspective. The problem is not the clients ability to guess a=20 reasonable mapping.=20 The problem is that the current definition of CHANNELCONVERSIONS may "tease" a client into thinking a mapping is supported and=20 then require a NO response to find out. This does not seem like the best way to solve the problem. You end up with the following=20 unfortunate exchange: C: 1 CHANNELCONVERSIONS text S: * CHANNELCONVERSIONS "text/plain" S: 1 OK CHANNELCONVERSIONS Now guess the legal domain! C: 2 CHANNEL (inband) (1 2) "text/plain" S: 2 NO CHANNEL Sorry, no cigar. Try some other Content-Type. In this case 1.2 may have been application/pdf, but the server only supports conversions from text/html -> text/plain, for example. >=20 > Enumerating the list of all possible transformations is potentially=20 > very verbose.=20 It is verbose because you have allowed it to be verbose. I see no=20 value in allowing a NIL argument to get the entire Range. This is a=20 very simple problem to solve. You change the syntax to have=20 CHANNELCONVERSIONS take an element of the Domain and return the=20 range for that element only. C: 1 CHANNELCONVERSIONS application/pdf S: * CHANNELCONVERSIONS "text/plain" S: 1 OK CHANNELCONVERSIONS This is entire range This is more in line with how a mobile client will want to use it. For example, let's say a mobile client has a Word viewer but no PDF viewer. It will be interested in asking what are it's options specifically for PDF, not the fact that the server might support conversion to plain text. > is a strong hint that the conversion will work. If the client asks to=20 > convert that image/jpeg to a text/plain, it deserves what it gets. (A=20 > NO response.) It does not deserve a NO response if it is asked to convert=20 application/pdf to text/plain. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 29 11:06:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04765 for ; Mon, 29 Nov 2004 11:06:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYo7U-00052g-NV for lemonade-web-archive@ietf.org; Mon, 29 Nov 2004 11:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnmc-0006v8-OU; Mon, 29 Nov 2004 10:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYndz-0004wX-MW for lemonade@megatron.ietf.org; Mon, 29 Nov 2004 10:40:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02427 for ; Mon, 29 Nov 2004 10:40:49 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYniv-0004Qd-8S for lemonade@ietf.org; Mon, 29 Nov 2004 10:45:57 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iATFZ1Ja016108; Mon, 29 Nov 2004 10:35:03 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Nov 2004 10:31:57 -0500 Message-ID: From: Eric Burger To: Michael.Wener@nokia.com, lyndon@orthanc.ca, lemonade@ietf.org Subject: RE: [lemonade] Channel updates for content conversion Date: Mon, 29 Nov 2004 10:31:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Sorry, but the conversion application/pdf -> audio/basic makes sense. We call it "Text-to-Speech". Mail readers will render the pdf as Text (not as Portable Document Format, but as the text rendered by the PDF) and then read it. Schematically, the server does: application/pdf -> text/plain -> audio/basic Of course, Greg would like us to do application/pdf -> audio/g723 :) What's the point of this? One cannot make an algorithmic or protocol mandate of what conversions make sense. Conversions that don't seem to make sense today may make sense tomorrow. For example, consider: video/h263 -> text/plain It turns out that the video can be a video of ASL, which gets translated into text. Sensible translation. Of course, this brings up my favorite topic, Message Context. For example, the thing to be translated might not be the signing, but lip reading :) > -----Original Message----- > From: Michael.Wener@nokia.com [mailto:Michael.Wener@nokia.com] > Sent: Wednesday, November 24, 2004 6:47 PM > To: lyndon@orthanc.ca; lemonade@ietf.org > Subject: RE: [lemonade] Channel updates for content conversion > > > > -----Original Message----- > > From: ext Lyndon Nerenberg [mailto:lyndon@orthanc.ca] > > Sent: Tuesday, November 23, 2004 11:08 PM > ... > > --On 2004-11-23 9:24 AM -0600 Michael.Wener@nokia.com wrote: > > > > > How do you communicate that a conversion between top level > > > media types is permitted? For example from pdf to plain > > > text. > > > > Advertise text/plain as a target conversion type. > > I think of conversion as a function with a Domain and Range. > CHANNELCONVERSIONS returns the Range. You seem to be assuming > the Domain to be the universe of all content types, which is > reasonable. How do I know what the mapping is? For example > the following conversion makes no sense: > > Convert(application/pdf) = audio/basic > > Mike > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 29 11:22:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05975 for ; Mon, 29 Nov 2004 11:22:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYoNF-0005QF-Lg for lemonade-web-archive@ietf.org; Mon, 29 Nov 2004 11:27:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYoCL-0003Al-OI; Mon, 29 Nov 2004 11:16:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnt2-00082A-Va for lemonade@megatron.ietf.org; Mon, 29 Nov 2004 10:56:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03797 for ; Mon, 29 Nov 2004 10:56:23 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnxy-0004p6-Jj for lemonade@ietf.org; Mon, 29 Nov 2004 11:01:31 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iATFuCo29286; Mon, 29 Nov 2004 17:56:13 +0200 (EET) X-Scanned: Mon, 29 Nov 2004 17:54:08 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iATFs8HU027320; Mon, 29 Nov 2004 17:54:08 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 008oIAyK; Mon, 29 Nov 2004 17:54:07 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iATFs5a19746; Mon, 29 Nov 2004 17:54:05 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Nov 2004 09:53:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Channel updates for content conversion Date: Mon, 29 Nov 2004 09:53:41 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BD2@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Channel updates for content conversion thread-index: AcTWKjGQrpshj1MZTQ2huV2StITP5AAAJhnw To: , , X-OriginalArrivalTime: 29 Nov 2004 15:53:42.0074 (UTC) FILETIME=[998451A0:01C4D62B] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Eric Burger [mailto:eburger@brooktrout.com] > Sent: Monday, November 29, 2004 10:32 AM ... > Sorry, but the conversion >=20 > application/pdf -> audio/basic >=20 > makes sense. We call it "Text-to-Speech". Mail readers will=20 > render the pdf Agreed. I thought of that after I sent the response. There are many like this. > What's the point of this? One cannot make an algorithmic or protocol > mandate of what conversions make sense. Conversions that=20 > don't seem to make > sense today may make sense tomorrow. The point is made in my second response. The point is not that a client needs to be told what are sensible=20 conversions. Not at all! The client should be told what are the legal mappings supported=20 by the server so it does not ask for pointless, but sensible,=20 conversions. Pointless because the server does not support the=20 mapping. See my other post for an example. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 29 12:20:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10533 for ; Mon, 29 Nov 2004 12:20:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpHf-0006ff-VX for lemonade-web-archive@ietf.org; Mon, 29 Nov 2004 12:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYovj-0002ro-EF; Mon, 29 Nov 2004 12:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYonU-0001Nm-6E for lemonade@megatron.ietf.org; Mon, 29 Nov 2004 11:54:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08280 for ; Mon, 29 Nov 2004 11:54:41 -0500 (EST) Received: from 206-169-2-196.gen.twtelecom.net ([206.169.2.196] helo=mail.optistreams.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYosF-00062V-SP for lemonade@ietf.org; Mon, 29 Nov 2004 11:59:50 -0500 Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id AD3B3F7E0298; Mon, 29 Nov 2004 08:24:27 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <302847BE-4227-11D9-B6BA-000A9571873E@guppylake.com> Content-Transfer-Encoding: 7bit From: Nathaniel Borenstein Subject: Re: [lemonade] Channel updates for content conversion Date: Mon, 29 Nov 2004 11:53:26 -0500 To: Eric Burger X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, lyndon@orthanc.ca 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit On Nov 29, 2004, at 10:31 AM, Eric Burger wrote: > Schematically, the server does: > > application/pdf -> text/plain -> audio/basic > > Of course, Greg would like us to do > > application/pdf -> audio/g723 Just to muddy the water a tad further... this is one of the few areas where the small number of top-level MIME types is more than a minor organizational device, because what you might really want to specify, in some contexts, is simply the conversion: application/pdf -> text/plain -> audio/* where the audio subtype might best be left unspecified until the capabilities of a receiving client are known. More ominously, in your more fanciful example: > video/h263 -> text/plain it's actually far more complex than you make it sound. If you're translating a video of someone "speaking" ASL, not only is there ambiguity between lip reading and sign reading, there's also the possibility of using the closed captioning. Far worse, what if it's not ASL but some non-English sign language? It's far from trivial even to know how to set the "charset" parameter after the translation, but you *do* have to worry about that whenever you're talking about "text/plain" as a target. At some point, any software that does the voice-to-text conversion is going to have to be able to set the character set on its output, because it's going to be the component best able to tell the difference between spoken English and spoken Chinese. Back in the bad old days when lots of mail went through gateways to different email protocols, I liked to say that "no gateway ever improved a message that went through it." The same is surely true of format translation. To me, this suggests that format translation is a last resort, and always best delayed to the last possible moment. The goal of LEMONADE, of course, is to optimize bandwidth usage for currently-expensive mobile connections, and format translation is certainly a plausible way to approach that goal. It would be a shame, however, if in enabling such optimizations, we created legacy barriers to better solutions in a hypothetical future where mobile bandwidth is cheap.(**1**) In short, we need to be sure there's always a way to turn all our "optimizations" off. We now return to our regularly-scheduled nitpicking. -- Nathaniel (**1**) Circa 1980, the dedicated line in our CMU offices was upgraded from 1200 baud to 56K, and some people quickly took advantage of that enormous bandwidth to replace command line software with friendly interactive menus (ZOG). A grumpy fellow grad student described this as "the most obscene waste of bandwidth I ever saw" but I was inspired to dump AI and theory in favor of research on human-computer interaction. Circa 1990, I sent one of the first "interesting" MIME messages to the ietf-822 list, containing a 4-second audio clip of my voice, saying "Memory is cheap, bandwidth is cheaper!" Even on that forward-looking mailing list, I got more than a few irate complaints about such a profligate waste of bandwidth (about 50K in one email!) and the "inefficiencies" it portended. Circa 2005, we have LEMONADE. I just hope we don't lock in too many assumptions about the duration of our current bandwidth limitations. -- Nathaniel _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 29 21:28:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10749 for ; Mon, 29 Nov 2004 21:28:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxpm-0006Tk-0s for lemonade-web-archive@ietf.org; Mon, 29 Nov 2004 21:33:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxjP-0005iy-Fi; Mon, 29 Nov 2004 21:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxiC-0005UZ-2l for lemonade@megatron.ietf.org; Mon, 29 Nov 2004 21:25:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10526 for ; Mon, 29 Nov 2004 21:25:50 -0500 (EST) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxnD-0006QM-CH for lemonade@ietf.org; Mon, 29 Nov 2004 21:31:03 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAU2Pli8018489 for ; Mon, 29 Nov 2004 18:25:48 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAU2PliK025450 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 29 Nov 2004 18:25:47 -0800 Date: Mon, 29 Nov 2004 18:27:51 -0800 (Pacific Standard Time) From: Mark Crispin To: lemonade@ietf.org Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [lemonade] URLAUTH document WGLC 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad It sounds like the dust has settled. Should I upload draft -05 based upon the coments which came during the WGLC? -- 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 From lemonade-bounces@ietf.org Tue Nov 30 08:13:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15468 for ; Tue, 30 Nov 2004 08:13:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ7tp-00039W-E2 for lemonade-web-archive@ietf.org; Tue, 30 Nov 2004 08:18:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ7iT-0000w4-Bx; Tue, 30 Nov 2004 08:06:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ7ck-0008DW-Pk for lemonade@megatron.ietf.org; Tue, 30 Nov 2004 08:00:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14449 for ; Tue, 30 Nov 2004 08:00:53 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ7ho-0002qf-MS for lemonade@ietf.org; Tue, 30 Nov 2004 08:06:12 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAUD0mv09178 for ; Tue, 30 Nov 2004 15:00:49 +0200 (EET) X-Scanned: Tue, 30 Nov 2004 15:00:15 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAUD0FbE031494 for ; Tue, 30 Nov 2004 15:00:15 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00cSQ0Cb; Tue, 30 Nov 2004 15:00:10 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAUD02a26735 for ; Tue, 30 Nov 2004 15:00:02 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 30 Nov 2004 06:58:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Nov 2004 06:58:47 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3BD5@daebe005.americas.nokia.com> Thread-Topic: URLFETCH Partial Fetches thread-index: AcTW3FUFkKve+7JHThGKwnhM2SWHBA== To: X-OriginalArrivalTime: 30 Nov 2004 12:58:48.0640 (UTC) FILETIME=[555B1C00:01C4D6DC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] URLFETCH Partial Fetches 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Personally I don't think this is an issue when using URLFETCH=20 in the "Forward without Download" solution. In this case=20 the client will be the SMTP server and I don't see much=20 benefit for partial fetches in this case. My concern is with future use of URLFETCH in environments=20 where "weaker" clients will be using the command. This is my understanding of where this left off ... 1) There was no consensus on how to solve it. The Approaches seemed to be=20 a) An extension to IMAPURL to handle byte ranges b) Syntax added to the URLFETCH command to handle=20 ranges c) A possible combination of a) and b) (I expressed my preference in a previous note) 2) Alexey said he would look into extending IMAPURL=20 to handle byte ranges. 3) I think either a) or b) would require modification to the=20 URLAUTH draft Does this sound correct? Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade