minutes from IETF 74 App Area Open Meeting

[Peter Saint-Andre <[e-mail]>]

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
<http://svn.cometd.org/trunk/bayeux/bayeux.html>. 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 <http://xmpp.org/extensions/xep-0124.html>,
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 [e-mail] 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.

/psa