LEMONADE BOF MINUTES November 21, 2002 Note Well presented Meeting simulcast using the Jabber text discussion room, Grahm Kline is the meeting transcriber. Agenda presented, no suggestions for revision Glenn presented the current list of explicit liaison items to be added to the charter. Charter discussion points #1: Should we expand the charter to cover media content adaptation? This would expand this effort to real-time interactions. SIP and OPES are not currently focused on this topic, Lemonade is another candidate. Informal sentiment suggests not including this effort into lemonade at this time, some suggestions that it may be added back in later. Charter discussion point #2: Should SNAP be part of the Lemonade effort? Is there a need to address more general notification framework that addresses the broader security issues. 3GPP2 is planning completion SIP based notification within a few weeks. That effort is focused on store to server... The questions is whether we need another mechanism on top of the large body of work of IM development. Another question (Lisa) is whether this protocol should be proprietary... that is, there is not a need to standardize all protocols and there is no system-wide disadvantage to a tangle of proprietary protocols in this space. Poll of potential constituency showed little interest (Just Greg and Avi) There are lots of possible mechanisms, why standardize this one in particular. This has some similararity to the WAP push server. A server than wants to push a notification to a client, it uses a PAP? protocol? PAP does not include information necessary for mailbox notification. Three views expressed: SNAP not needed, SNAP needed, SNAP may be needed but need not be standardized. Humm shows consensus that Notification be part of the Lemonade charter, but not clarity as to whether SNAP should be the basis of that work. Charter Status: Ned reports that the charter needs to be reviewed briefly, will be taken to IESG for approval by Ned shortly following this meeting. Requirements Draft : Kue Wong presenting. Draft addresses request from Yokohama to consolidate various requirements drafts into one. First issue, does anything else needed for contributions? None suggested during the meeting. Issue: are there other design principles that should be added: None suggested. Any additional requirements for WUI? AVI has written a document that was too late for consideration at this meeting, but may be a good candidate to merge into this document as well. May be useful to add server-to-server notification. Will add requirements for notifications both server to server and server to client. OMA/3GPP/3GPP2: OMA has subsumed the WAP forun. SyncML, Wireless Village, mobile wireless interent forum, and location interoperability Forum. Randy presented an overview of the 3GPP2 reference model and the various interfaces in the conceptual model. MM1, interface between handset and server, defined by 3gPP as HTTP/WAP, WAP encoding. 3gPP2 supports multiple MM1 interfaces, including HTTP/WAP encodings, HTTM textual encoding, or mobile IMAP. Mobile IMAP included some changes to shorten command, concatenated commands, shortened responses, added message submission into IMAP. Full specification of M-IMAP will be submitted as a contribution to Lemonade. 3GPP2 authentication mechanism is still an open issue. MM4 is the interface between servers.... 3gPP defines as SMTP, but with SMTP envelope in a message header, the whole encapsulated in an MMS envelope. MM3 is the grab-all of protocols to interact with external servers, a collection of protocols for interacting based on particular requirements. SGPP defines SMTP with proprietary changes and IMAP4 with SNAP. SNAP as a mechanism for asynchronous mailbox status change notification. In MMS, no distinction between header and envelope. Interfacing with Internet email looks to recreate the full confusion of years gone by. Two considerations for why MMS has gone backwards architecturally fifteen years... mapping done late at night... Desire to deploy MMS in existing servers as tunneled data without having to upgrade infrastructure. Delivery reports are not internet standard, but may be mapable. Codecs and format are a bit confused. 3GPP's main format is SMIL, sender creates multi-media content with timing and coordination of display set by sender. Might be possible to come up with a non-lossy conversion to MIME. Codecs are an issue, photo's, moving pictures, voice... different handsets have different codecs. Originating handset creates based on it's capabilities, recipient's relay server responsible for changing content into proper form. 3GPP does specify full MIME, but not clear how fully supported in clients. General principle, sender sends what they want, receiver figures out what to do with it. 3GPP will not wait for Lemonade, but once Lemonade is finished, there are many industry participants that would be interested in adopting when it is done. Lemonade work can be retrofitted into 3gPP model. 3gPP3 operators group has mandated that 3GPP2 protocols be complete by December 2002. MediaSize: Protocol extension to address the needs for message store to declare status of quota. Same principle as SMTP size extension, augmented for Media Size. May help to clarify where in the architecture this sits? Not enough interest to resolve issue of which units to use for media type (context vs content-type) Should this mechanism be generalized or constrained to media type? SNAP: Authors believe the protocol is complete, Author perceives vague objections floating about. Draft may still lack in security. Lisa presented a litany of shortcomings ranging from the security model to the use of internationalized text. There was a disconnect between the authors perceived scope of a protocol to be used within multiple components within a walled garden and the community desire to see a protocol for aggregating multiple event sources with possibly multiple event aggregators over the Internet. The author was left with a task to better articulate the role of SNAP in the Internet architecture and to address more concretely the scope of the protocol and justify the provisioning, operational, and security facilities in the context of that scope Binary IMAP is done. Two channel documents are out. Base spec and use cases. Issues on syntax: Alexi proposes that the response from a UID channel indicate that they are UID responses. Channel does not have the concept of sending an entire message via the channel. Suggestion to make the section identification optional. Without objection, accepted. Syntactic change to grouping of sections. If sending via MailTo, then the grouping helps make nested multiparts. Group consensus was to limit mailto to simple forwarding cases and punt more complex cases into a submission/remote composition extension. Future delivery document was not presented since no changes had been made to the document since the last meeting. Randy volunteered that MMS requires future delivery, but does not require retraction... if retraction needed, maybe message tracking based mechanism rather than IMAP based "outbox" concept. There was some hope offered that there may be able to engineer a solution not requiring IMAP based submission. SMTP-Submit vs IMAP Submit... Debate has come up over the years. Adding to IMAP causes IMAP to track the extensions to SMTP. Whole set of things that have to have to go into the mechanism... DNS requests, 8-bit transport requests. Some sentiment to tolerate more feature specific extensions to submit rather than build this new mechanism. There was lots of interest in the question, call for consensus likely premature. IMAP Status counters: Alexi presenting. Provides a more efficient mechanism than retrieving all headers or multiple header searches. No open issued noted by the scribe. Alexi presented IMAP quota draft. Document defines a extension mechanism suitable for message context extension. No open issued noted by the scribe Minutes recorded by Greg Vaudreuil, Jabber transcript of session available at http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/lemonade/2002-11-21.html