Meeting notes 9:11: agenda bash 9:12: announce of new discussion list name apps-discuss@ietf.org 9:13: APPS area workshop discussions recap: Barry Lind Workshop goals were to examine architectural gaps in Apps, to explore sensible reuse of existing standards, brainstorm, kick off new work. Format was informal. Breakout topics were identified, breakout sessions went into specific topics in detail; then plenary discussion of breakout topics. Breakout topics: use of http for more than web (updating BCP 56); protocol layering, localization and identity, synchronization, XML schemas, URI templates, HTTP authentication, Email re-architecture, push/pull/notify as an alternative to polling In discussion protocol layers, the breakout team was looking at how protocols at the applications layer interact with those at the transport and network layers The Email re-architecture discussion concluded that would it be wise to do some major redesign of email retrieval and storage. The Protocol Architecture Guide: possibly an informational document with what we've learned that works and what we believe does not. 9:22: Pete Resnick's slides:Toward a simpler Email Architecture Not suggesting "replace all of Internet e-mail"! SMTP, Message Format, MIME remain the same. This is about a replacement for IMAP. IMAP was architected at a time when message stores were more limited and in a way that exposed the semantics of existing, deployed server implementations. The IMAP client ends up with Herculean task of guessing what the server implementations are, through the protocol . Main features of a redesigned mail access protocol: No more mailboxes, No more folders. The message store is a database of independently addressable objects. It has 3 object parts: message objects, multipart objects, terminal objects. Objects shared across containers/stores Message objects: contain one multipart of terminal objects, has a uid, source and transport info. Multipart objects= contain one or more message, multipart, or terminal objects, and has type attribute and other info. Terminal objects--contain data, has a type attribute and other information. In this model, having a hierarchy of message containers is entirely a client decision, not a message store forced move. This is an architecture, not an implementation. It doesn't deal with security yet. Likelihood of implementation was discussed at workshop -- currently low. There were various thing said like: should be XML based, it should be done with HTTP; it should be done with a completely new protocol. Tools should be brought to architecture, architecture should not be changed to suit tools. We need at least a couple of implementations to get started. Discussion: - The key thing that he is looking to address are: in IMAP operations assume a select mailbox, then piece of the storage. In IMAP, you mark things for delete, then expunge or servers helpfully expunge them for you. - Do we really have a problem that needs solving? Lisa responded that clients have trouble interoperating at the same time as helping users with filing and load management. E.g. Opera mail and gmail don't play well with other Email clients. - Who might implement and contribute? Pete is looking for prototypers, with architectural bent + knows what a compiler and maybe a product connection (so could think of impact). The server implementors are the ones that might object here; client implementors likely to have strong desire for this of IMAP that don't implement IMAP - Does this make clients more complicated as the cost of making the protocol simpler? Lisa pointed out that pushing complexity around can be very useful -- e.g. if we could create a very low barrier to entry for tools that are not full UAs, e.g. mashups, notification aides, integration with calendaring, blogging, IM and vcards. - Cyrus warned against only looking at past problems of email, but that's a moving target, people looking at new things in email and need to look at forward scope, calendaring - rss - social web - etc. As a client author, want my client to stand out, don't want all clients to act same way. Pete answered with rich semantics, clients can do lots of interesting things - Dave talked about the generality of a protocol for access of data between the user and their data. Sometimes generality is a real problem for progress, but possibly not here. A way to displace the existing protocol might be with generality. As is, the work isn't well enough motivated--the dissatisfaction is evident, but the user base, dissatisfied as it is, will show a take-up problem on the client side. Pete responds that being general enough to deal with mail, atom, calendaring is a different approach. You start with one, then others can use other "primary ontological entities". The main problem, though, is getting folks on board for doing *their* piece. E.g. Chris Newman's message store is very general and happens to have IMAP on it. He could have a parallel access protocol based on this. Parallel pop/imap/new is complicated, but it gives you a way out of the pain. 10:19: Random announcement from Gorry Fairhurst: Transport area is working on a "how to use UDP" draft, and input now would be great. 10:20: Mark Harrison on ESDS: "How to chase a Bull" Discussion: - end-to-end traceability is key, surviving object composition (e.g. assembling a plane or laptop) or decomposition (breaking a container into pallets)