Applications Area Open Meeting =========================== MONDAY, March 23, 2009 0900-1130 Morning Session I Imperial B Jabber logs: http://jabber.ietf.org/logs/apparea/2009-03-23.txt Jabber Scribe: Peter Saint-Andre 1. AGENDA BASHING No bashing. 2. HTML 5 (Lisa Dusseault) Lisa provided background information regarding HTML5 efforts, and announced HTTP Bar BOF. 3. IPR and Copyright Update (Lisa Dusseault) Lisa provided background information regarding the recent confusion regarding RFC 5378 and I-D submissions. Participants raised questions/concerns about: - The current outline for a fix might be too broad - Are there anti-trust issues? - This is not an engineering problem, so the IETF does not have expertise or a track record of success - Is there potential for WG to shop between IETF areas for more palatable IPR policies? 4. Resource Discovery (Eran Hammer-Lahav) Eran discussed draft-hammer-discovery-02 (Link-based Resource Descriptor Discovery), which describes a process for obtaining information about a resource identified by a URI. It is based on Extensible Resource Descriptors (XRD), being defined at OASIS. The core idea is to use hypertext links with rel="describedby" and type="application/xrd+xml" to get from a URI to a document that describes the resource. No discussion regarding this topic. 5. Server/service Discovery (Stuart Cheshire) Stuart discussed draft-cheshire-dnsext-dns-sd-05 (DNS-Based Service Discovery), which describes a convention for naming and structuring DNS resource records so that a client can discover a list of named instances matching a given service, using standard DNS queries. Participants raised questions/concerns about: - Isn't this already standardized? - When will the RFCs be published? - What can people in AppArea do to move this along? - Does this violate some core DNS assumptions/practices (in a way bordering on misuse)? Lisa noted that we have seen different AppArea WGs define their own discovery methods, that it would be preferable to use the same underlying technology, and that dns-sd seems like a good fit for AppArea needs. 6. Timezone Definitions (Cyrus Daboo) Cyrus discussed challenges involved in time zone information, and possible solutions. Currently many operating systems and devices rely on the "tz database" (a.k.a. "the zoneinfo database" or "the Olson database) hosted by the U.S. National Institutes of Health and maintained by a small group of volunteers. Challenges: - No guarantee of the longevity of this source. - Other vendors maintain their own databases. - There are interoperability problems. - Different definitions in different products. - Information not always updated properly when there are rules changes. - Information not always updated in a timely fashion when there are data changes. Proposed solutions: (1) IANA registry for publishers of timezone data. (2) Define a timezone services protocol. (3) Work out a succession plan for the Olson database. (4) Make sure timezone data is provided "securely". Participants raised questions/concerns about: - Perhaps just use a wiki? - Use ISOC instead of IANA? (The chapters could help.) 7. SCRAM SASL Mechanism (Alexey Melnikov) Alexey provided some background information about the SCRAM mechanism for SASL and the implications of this work for AppArea efforts. The relevant drafts are draft-newman-auth-scram-10 and draft-newman-auth-scram-gs2-01. The SASL framework (RFC 4422) is used for authentication in IMAP, POP3, LDAP, SMTP, BEEP, XMPP, ManageSieve, etc. (but not HTTP). The existing SASL mechanisms are perceived to be lacking: - PLAIN lacks strong security - CRAM-MD5 is simple to implement but lacks modern features - DIGEST-MD5 is difficult to implement and has led to interoperability problems SCRAM is intended to provide a "better" password-based SASL mechanism (password not sent in cleartext, server auth, i18n, channel bindings to TLS, more modern crypto) that is simpler to implement than DIGEST-MD5. Work on SCRAM is mostly complete in the SASL WG, and early implementations are starting to appear. Need to figure out how to integrate it into HTTP. Participants raised questions/concerns about: - Deprecating CRAM-MD5 given its wide deployment. - It was noted that SCRAM is designed to replace DIGEST-MD5, not CRAM-MD5. 8. Bidirectional HTTP: BOSH, Bayeux, COMET, WebSockets, rHTTP 8a. Comet / Bayeux (Greg Wilkins) Greg summarized the Comet methodology and Bayeux protocol . It is designed to provide two-way messages between a web browser and a web server, using "long polling", a publish-subscribe model, and JSON payloads. This is all "legal" HTTP. The two-connection limit in HTTP is acceptable. Interframe communication and pipeline control would be desirable. Also interested in 1xx responses for better communication of interim status before server returns 2xx response. 8b. XMPP BOSH (Jack Moffitt) Jack summarized BOSH , an HTTP binding for XMPP traffic, originally developed in 2004. Basically emulates TCP over HTTP using "long polling" with 2+ active HTTP request/response pairs at any one time, containing XML payloads. Widely adopted in the XMPP community, with some non-XMPP deployment. Works well for XMPP and has relatively strong security (as strong as TCP, at least), although it could be simplified. 8c. Overview of BiDi HTTP technologies (Mark Lentczner) Mark provided an overview of the major known technologies in this space, comparing Bayeux, BOSH, rHTTP (draft-lentczner-rhttp-00), and Web Sockets (draft-hixie-thewebsocketprotocol) along various dimensions: long polling vs. use of HTTP upgrade, inclusion of a body vs. use of an in-band wire protocol, whether the usage is stateful or stateless, etc. 8d. Discussion Lisa noted that further discussion is welcome on the apps-discuss and httpbis lists (with a dedicated list to follow) and that BOF proposals would be welcome. 9. Intro to MMOX -- David Levine MMOX = Massively Multiparty Online "X" (games and applications). Much recent discussion on the mmox@ietf.org list. BOF at IETF 74. Many existing systems/services/implemenetations. Growing desire for interoperability. Work at the IETF seemed appropriate to various contributors in this space. Topics might include: - Define "shared space". - Real-time content sharing / melding. - Collaboration across trust boundaries. - How to combine graphical and object streaming. - Manage update streams between components. - Manage access to virtual spaces. - Manage access to content. Possible WG approach: - Define use cases and core problems in this space. - Adapt Open Grid Protocol to solve needs in existing ecosystem. - Foster work on future-oriented layers. 10. YAM Preview (Tony Hansen) Pointer to http://trac.tools.ietf.org/bof/trac/wiki/YamCharter for the Yet Another Mail (YAM) BOF. This is work to push a number of email-related specifications from Draft to Final. 11. XMPP Preview (Peter Saint-Andre) Preview of Extensible Messaging and Presence Protocol (XMPP) BOF. Four areas of focus: - Finish revisions to RFCs 3920 and 3921. - Improve server-to-server connections. - Define end-to-end encryption method. - Describe SIP-XMPP interworking. 12. AD Update Outgoing AD Chris Newman recognized for his years of service in the Applications Area.