From: Burger, Eric [eburger@cantata.com] Sent: Thursday, June 01, 2006 10:21 PM To: Enhancements to Internet email to support diverse service enivronments Subject: [lemonade] Draft Minutes, Both Days [Corrections applied from list] Draft Minutes, lemonade Interim Meeting 65,5 31 May 2006 - 01 July 2006 Ottawa, ON, Canada Chairs: Eric Burger Glenn Parsons Attendees: Alexey Melnikov Arnt Gulbrandsen Ray Cromwell Dave Cridland Greg Vaudreuil Mike Parsel Ken Murchison Jerry Shih Stephane Maes Randy Gellens Jabber Logs 31 May 2006: http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-05-31.html 01 June 2006: http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-06-01.html Meeting Goal: Get updates to documents by 19 June 2006 in time for WGLC before or at IETF 66 in Montreal. Draft Discussions ================= RECONNECT --------- Issue: Do we need to mandate a minimum number of outstanding sessions a server must support? Discussion: Could make clients easier to implement if they knew that a server would have at least so many sessions available. Rejoinder: No matter what, another client can consume sessions, so the client must have code to deal with exhaustion of session resources. Thus there is no benefit of having a preset minimum number of sessions available for reconnect. Result: Be silent on a minimum number of sessions. Issue: Do we need server-side RECONNECT? Discussion: RECONNECT authors realized the tokens being passed to let the server know which session was being reconnected was identical to the state the server needed to know to re-establish state. Thus it is possible for the server to be stateless. This follows IETF practice of avoiding fate sharing. The client holds the state, and if the client fails, it doesn't care the state is lost, as it lost the state anyway. The proposal does not add any burden on clients, as the client needed to store the same information with the server-driven scheme. Rejoinder: Server-driven document is already written; do we want to delay? Result: Create new document centered around client-driven RECONNECT. It will be a work group document: draft-ietf-lemonade-reconnect-client; we are confident in its status as only about 2 paragraphs change. After the new draft is issued and the old draft is updated (there are some ABNF issues, etc. that need to be addressed), we will preferably chose one document and kill the other. Alternately, we will chose one, reference it in Profile-bis, and release the other as Experimental. Worst-case is both documents progress. IMAP URL (2192-bis) ------------------- Issue: Alexey needs Mark's input to decide what goes into 2192-bis versus URLAUTH. Resolution: Alexey will e-mail Mark directly. Issue: Alexey needs some help with sections talking about listing content of a server and mailbox naming scope. Resolution: We volunteer Dave to help. Issue: Should 2192-bis include examples of extensions from BINARY, URLFETCH, imap-search-ret? Resolution: If those drafts are stable, then yes, otherwise, no. Alexey will send note to list if he doesn't get a response, then he will assume the drafts are not stable. CONVERT ------- Issue: ISO-8859-n has 16 values for n. Which one(s) do we mandate? Resolution: All of them (?). Clearly at least ISO-8859-1 (trivially easy) and ISO-8859-5 (in honor of Alexey) will be mandatory to implement. Issue: The original draft had a bunch of conversions that are now not mandatory. Resolution: Leave the text, but change RFC 2119 language from MUST/SHOULD to MAY. Note that OMA will impose relevant mandatory-to-implement conversions. We will ensure the protocol can handle them, but will not mandate any particular conversions outside of ISO-8859-n to UTF-8. COMPRESS -------- Note: There are some very interesting results discussed in the Jabber log , around the 12:20 time mark, about compression experiment results for TLS and compress=deflate. The short of it is that traffic with a moderate amount of attachments gets 70% compression using TLS; traffic with lots of attachments gets better compression with compress=deflate. Issue: How to disambiguate Content-Transfer-Encoding from Content-Type? Discussion: VPIM experience is the C-T-E is not well supported. One proposal is to use magic MIME types. Rejoinder: Only a C-T-E knowledgeable client will request compression from a C-T-E knowledgeable server. Moreover, using C-T-E is a correct protocol thing to do, as in "say what we mean." Reminder: The server is in the best position to decide whether or not to compress (if compression accepted by the client). The client-driven use case, where the client wants to save CPU at the expense of radio power, does not match the physics of the situation. Discussion: Propose compress=deflate (draft-arnt-imap-deflate-02). Unquestionable desire to NOT have the mechanism be on a request-per-body-part basis. However, there is also a desire to have the mechanism be controllable (on or off) at client-requested point in the session. Discussion: Although deflate is the compression algorithm of gzip, and the proposed lemonade mechanism was called gzip, we are NOT discussing using gzip anymore. This means that the stream will not include the actual MIME type or file name (as would happen if we used the entire gzip structure). Discussion: Clear win for downstream (server->client) compression. However, compression could be a cost for upstream messages, as the protocol messages are often smaller than the PDU of the compressed block. Discussion: What, if in the middle of a transaction, the client says, "stop compressing"? That isn't a problem, because the IMAP transaction model says the current transaction completes. Resolution: Move compress out of convert document. Use compress=deflate. Ensure the method is controllable. Ensure the method can be asymmetric (compress one way and not the other). Arnt is to be lead author. Special note: we will re-use the name draft-ietf-lemonade-compress-04, but the contents will be entirely deleted and the new content will substantially come from draft-arnt-imap-deflate-02. ENCRYPT ------- Issue: Still not clear what the business / use case is for this feature. Needs to be clear and distinct. Discussion: Classic industry problem: if we don't do it, someone less knowledgeable will do it. Resolution: new draft coming. WITHIN ------ Issue: Second recalculation is way too much of a server burden. Discussion: We are not trying to replicate instant messaging. Daily is enough. Hourly is OK. Discussion: We came up with a bunch of use cases which do need finer grain than hourly, e.g., transportation (your flight has been diverted) and military (invade Iraq if I don't hear from you for 15 minutes). Discussion: Can we let the client request whatever it wants (in minutes) and have the server reply with what it set it to? I.e., if a server does hourly, and I request 39 minutes, the server responds that it will do updates hourly; if a server does quarter-hourly, and I request 39 minutes, the server responds with 30 minutes or 45 minutes (up to the server to decide). Resolution: By minutes; need to think about letting the server do the granularity (need text). Issue: Should we give guidance on recomputing views? Resolution: Yes, put in an informative section into the document. VFOLDER ------- Issue: Anonymous users creating VFOLDERs can be a DoS attack. Resolution: Anonymous users cannot create a VFOLDER, but they can read them. Issue: Legacy clients might duplicate messages since they don't know the messages are virtual. Reminder: In Dallas (and on the list) we said that only lemonade clients could use VFOLDERs. Discussion: Would be very useful for legacy clients to see VFOLDERs. Resolution: Allow VFOLDER only for lemonade clients for now. Issue: What happens if one renames a folder a VFOLDER depends on? Discussion: Original proposal is to delete the VFOLDER. Rejoinder: That would be a customer service nightmare, "All of my folders disappeared?!?!" Resolution: VFOLDER calculations get updated when one renames an underlying mailbox. Issue: What happens if one deletes a folder a VFOLDER depends on? Discussion: Choice is to immediately delete the dependent VFOLDERs, keep the VFOLDERs around until the next status/select/examine, or make the VFOLDER real. Arnt's implementation today immediately deletes the dependent VFOLDERs. Issue: What about Append/Copy support for VFOLDER? The current draft says "maybe". Discussion: Alexey proposed saying "yes" unless not possible. Arnt said that some clients expect a message to be there if they put it in the folder. If it isn't there, the client may retry. If it is the View that keeps the message away, the repost will always fail (causing the client to loop). Rejoinder: The scenario of a message never getting posted can happen today. One client can post a message while another expunges it. Answer to that is that while it could happen, it is not likely to occur repetitively. Issue: The server should be able to reject expensive or complex VFOLDER calculations. Discussion: This could cause a user interface problem if the creation of the VFOLDER is hard-coded in the client. That is, the user does not know they are requesting the creation of a VFOLDER. Thus they get a surprise when they get an error messaging saying the VFOLDER they didn't know they were creating failed to be created. Rejoinder: In a sense, this is a client implementation failure, and the user will sensibly force the provider to fix the client. Discussion: The impetus for the question is that it is thought that some servers may not implement dynamic attributes for VFOLDER. Further discussion indicated that if you do VFOLDER and CONDSTORE, you pretty much have already done dynamic attributes. Resolution: Consensus is that if one does VFOLDER, one must do Dynamic Attrributes. Issue: There are two use cases for VFOLDER. One is as a notification mechanism (setup a VFOLDER to filter messages of interest and then report on the state of that VFOLDER). The other is as a mailbox management mechanism (I get thousands of messages per day or I have a ton of messages in my folder, and I want to have only a small subset on my client). Should we have two mechanisms? Discussion: It is true that the former use case demands dynamic attributes while the second may be able to get by with static attributes. However, the use cases are too close together, and the user interface would be too complicated, to split the functionality. Resolution: We just have VFOLDER, and it requires support of dynamic attributes. Issue: Can we have a VFOLDER that is the set of messages that are not selected by any other VFOLDER? Resolution: Submit text. Issue: When does a VFOLDER recomputed its contents? Discussion: Clearly when a new message arrives. What about on any IMAP command? on IMAP commands the mutate state? only on SELECT? by time interval? Resolution: "In a timely manner" [I'd like to see text] NOTIFICATIONS ------------- Note: Ray extended EMN for lemonade needs; will fold back in to official EMN definition in OMA. Issue: MSGEVENTS draft expired Discussion: It is critically important for the set of events to be reviewed for completeness. Resolution: Chris to resubmit; WG to review. NEED VOLUNTEERS TO REVIEW. Issue: MSGEVENTS are not extendable Discussion: We cannot anticipate future extensions to IMAP, nor can we be sure we have covered everything today. Also, there is a legitimate business need for proprietary extensions for use in proprietary environments. Resolution: Ray will investigate creating an extensible mechanism for notification events. Special Note: We will make clear that this mechanism for proprietary extensions MUST make it explicit what kind of notifications are acceptable to go over the wire with this mechanism. In particular, we are talking about stuff we don't care if it gets lost or where a duplicate delivery doesn't harm anything. I think that like the Pork example in the Torah, we should explicitly call out LOCKDOWN as a message that is wholly inappropriate for this mechanism and MUST NOT be sent as an extension message. LOCKDOWN, purge all messages, purge your cache, et al. are all messages that fall into the category of "do not use notifications." Issue: We had two mechanisms, out-of-band (oob) and in-band (ib) for notifications. However, it can be very difficult to decide if a user is actually connected. Discussion: Don't want to have multiple code paths, especially if the choice to go ib can turn out to be wrong. On the other hand, the technology of ib (use TCP) and oob (use, e.g., SMS), can have very different cost profiles. Discussion: Independent of message state, it can be useful to have both mechanisms. Resolution: We will split NOTIFICATIONS into two drafts, on ib and one oob. Alexey will write the ib draft. New draft must be done by June 19. Issue: Server-to-Server (S2S) text in draft does not bind the messages to a transport protocol. Is this OK? Discussion: Might not want to make a binding, so the server can natively interface with SIMPLE Server, XMPP Server, SMSC, MMSC, etc. Rejoinder: Some folks do not care about mobile notifications and even if they do they do not want to have to implement a bunch of notification server protocols. Resolution: We will choose a single transport binding. Stephane will provide text in next revision of NOTIFICATIONS draft, due June 19. Issue: Should lemonade S2S document be explicitly limited to lemonade / messaging environments? Discussion: Do not want to boil the ocean - generic notifications are a BIG computer science problem. Moreover, the whole reason for having a lemonade S2S document is for the purposes of having a baseline, easy-to-implement protocol for lemonade servers to use. Resolution: Randy and Stephane will provide appropriate text, by June 19. DEPLOYMENTS ----------- Issue: Dave was going to supply figures for reconnection costs. Resolution: Dave WILL supply figures for reconnection costs. Issue: Current draft references Profile-bis and NOTIFICATIONS Discussion: They will hold up publication. Discussion: What about TCP-Challenged Environments? Resolution: Drop NOTIFICATIONS, don't reference TCP-Challenged, and reference Profile. Put them back when we do DEPLOYMENTS-bis. Update by June 9. The document will be ready for WGLC at that point. Reminder: We are publishing this as a BCP. TCP-CHALLENGED ENVIRONMENTS --------------------------- Issue: So we are not circumventing firewall policy, HTTP PDUs will have a header to indicate the payload is really a mobile message. Current draft uses X-HTTP-Binding. Resolution: Use something descriptive, like HTTP-Mobile-Email and do not use X-. Issue: The draft enumerates five different approaches to making lemonade work in environments without TCP. Should we choose one? Discussion: While HTTP tunneling provides 100% of the lemonade functionality, HTTP tunneling will not work in all TCP-challenged environments. REST will work in all TCP-challenged environments, but will not provide 100% of lemonade functionality. Resolution: Mandate REST. Not providing 100% of lemonade functionality is a feature, not a bug. Using REST allows lemonade to work in all environments, including high-value environments like satellite e-mail. In addition, not providing 100% of lemonade functionality gives operators that are TCP-challenged an incentive to properly implement their network. Note: We will keep the text for the other methods, to explain why we are not using them. Note: Ray to review how XMPP specifies operation over TCP and fall-back to HTTP. [References to this are in the Jabber logs (pardon the irony).] Chair's note: Ensure there is NO normative language in any of the text for the other methods, and move them to appendices. Make it clear that REST is the only approved (and specified) method available. STREAMING --------- Issue: How to do VCR controls (fast-forward, rewind, speed-up, slow-down, pause)? Discussion: MSCML and MSML have the bulk of the market. This problem is being examined informally by the mediactrl interest group (see ). RAI (TSV, historically) didn't have pressure to examine this work. MSCML is on RFC Editor Queue. Resolution: We will press RAI to solve this issue for us, as it is a SIP control thing. Our document will not reference VCR controls. Issue: Server location is important. Discussion: Neil is working on a proposal. Resolution: Neil's text will go into Profile-bis. PROFILE-BIS ----------- Editorial: Need to update bis to reflect decisions on compression, encryption, and reconnect. Issue: What about streaming? Is it mandatory to implement? Discussion: Streaming is purely a client issue. Server only needs to support URLAUTH and URLFETCH. Resolution: Remove streaming appendix from bis and reference streaming draft. OMA LIAISON =========== Document Progress ----------------- We will tell OMA about our progress by enumerating RFC's published and documents in or about to be in WGLC or IETF LC. LC documents include FUTUREDELIVERY, CONVERT, WITHIN, METADATA (ANNOTATEMORE), ESEARCH, and deployment issues. We will not include RECONNECT, as we need to nail down server-side versus client-side state storage first. Interoperability Testing ------------------------ Reasons for Interop: Marketing Moving to IETF Draft standard Compliance Input to OMA IOP We will focus on #2 and help on #4. Plan is to have the following interoperability events: A Private Interop Event (under NDA). Participants: Developers (only) Venue Requirements: Close to the most developers / travel constrained developers; excellent Internet connectivity, as some developers will participate remotely or their servers may be remote Location: UK Dates: October 23-27 [tentative] Goal: Get working implementations of lemonade suite. Prove accuracy / viability of IETF I-D's before RFC publication and moving to IETF Draft Standard from Proposed standard. Results will NOT be published, to encourage folks with alpha code and prototypes. A Market-Focused Interop Event, Highlighting Lemonade Interoperability. Participants: Field Folks Venue Requirements: High visibility venue that will generate customer and press buzz. Location: Telecom 2006, Hong Kong Dates: December (first week?) A Market-Focused Interop Event, Highlighting Mobile Messaging Paricipants: Field Folks Venue Requirements: High visibility venue that is mobile-oriented that will generate customer and press buzz. Location: 3GSM, Barcelona Dates: February 12 - 17, 2007 (?) To make the marketing events happen, we need outside coordinator. Stephane volunteered EIMG group. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade