2.1.4 Extensible Messaging and Presence Protocol (xmpp)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-14

Pete Resnick <presnick@qualcomm.com>
Lisa Dusseault <lisa@xythos.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
Mailing Lists:
General Discussion: xmppwg@jabber.org
To Subscribe: xmppwg-request@jabber.org
In Body: subscribe
Archive: http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg
Description of Working Group:
XMPP is an open, XML-based protocol for near real-time extensible messaging and presence. It is the core protocol of the Jabber Instant Messaging and Presence technology which is currently deployed on thousands of servers across the Internet and is used by millions of people worldwide. The XMPP working group shall adapt the XMPP for use as an IETF Instant Messaging and Presence technology.

The working group will use XMPP (as described in draft-miller-xmpp-*) as the basis of its work. The final specifications will be consistent as much as practical with both the requirements given in RFC2779 and the interoperability details in the final version of the CPIM specification (draft-ietf-impp-cpim). Note: If a requirement of RFC2779 or the final CPIM specification cannot be met, the working group will document why this requirement cannot be met.

A major goal of the working group will be to extend the current XMPP protocols to provide finished support for RFC 2779-compliant security mechanisms, including authentication, privacy, access control and end-to-end as well as hop-by-hop message security. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability.

The working group shall also add support for internationalization and localization to XMPP.

Instant messaging differs from email primarily by requiring relatively short delivery latency guarantees and, typically, less robust transport service. In addition, instant messaging includes the notion of presence information so authorized users can determine if their correspondents are available.

BCP 41 will be the basis for working group consideration of the transport implications of the XMPP design with respect to network congestion.

Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them.

There are facilities, such as chat rooms, shared white-boards and similar services that are not currently discussed in RFC2778 and RFC2779. When designing security mechanisms, the working group will keep in mind that XMPP may be extended or adapted to facilitate these additional services, so that design decisions can be made that will not preclude providing these services in the future.

Goals and Milestones:
OCT 02  Prepare revised specifications reflecting issues and solutions identified by the working group
NOV 02  Meet at the 55th IETF to discuss current drafts
DEC 02  Prepare final core protocol draft ready for working group last call
JAN 03  Prepare final instant messaging draft ready for working group last call
FEB 03  Prepare final CPIM compliance draft ready for working group last call
MAR 03  Submit revised specifications to the IESG for consideration as standards-track publications
  • - draft-ietf-xmpp-im-05.txt
  • - draft-ietf-xmpp-core-05.txt
  • - draft-ietf-xmpp-e2e-00.txt
  • - draft-ietf-xmpp-resourceprep-01.txt
  • - draft-ietf-xmpp-nodeprep-01.txt
  • No Request For Comments

    Current Meeting Report

    Tue Mar 18 15:53:03 2003 - 56th IETF
    WG: XMPP
    Chairs: Lisa Dusseault
            Pete Resnick
    Monday, March 17th, 2003 19:30-21:00 US/Pacific
    Minutes by: Marshall T. Rose
    Lisa: Agenda
     1930 - Agenda-bashing, find note-taker
     1940 - draft-ietf-xmpp-core: P. Saint-Andre
     	Overview - changes since last meeting 
     	SASL / TLS
     	Error handling
     	How 'core' meets IMPP requirements
     2010 - draft-ietf-xmpp-im: P. Saint-Andre
     	Overview - changes since last meeting
     	Rosters & subscriptions
     	Communications blocking
      	How 'im' meets IMPP requirements
     2040 - draft-ietf-xmpp-*prep: J. Hildebrand
     2050 - draft-ietf-xmpp-e2e: J. Hildebrand
     2110 - draft-hildebrand-xmpp-sdpng: J. Hildebrand 
     2130 - Break for drinks!
    Peter: XMPP Delta (Core and IM 05)
        XMPP Core: Security
            - Channel encryption via TLS during stream negotation 
    client-to-server, server-to-server, usual TLS rules minimum to 
    implement: TLS_RSA_WITH_3DES_EDE_CBC_SHA
            - Authentication via SASL client-to-server, 
    server-to-server, usual SASL rules minimum to implement is DIGEST-MD5
        Eric: If you're going to use TLS for peer-to-peer, you need to 
    explain what parts of the certificate you examine.
        Eric: If TLS negotiation has failed, things are typically hosed 
    because TLS implementations will probably read more than you 
    want.(beyond just the TLS error.)
        Peter: Right, we'll fix those.
        Joe: Let's talk about dialback. Looks like we should yank it from the 
    spec and define it in an informational document describing historic 
        [ scribe's summary ... at this point, many people spoke many times 
    about s2s security, TLS, SASL, and dialback. the two perspectives are 
    probably best summarized as:
        1. dialback doesn't address any actual threat model, but TLS/SASL 
    provides real value when properly provisioned (e.g., a 
    mutually-trusted CA, bilateral passwords, etc.)
        2. some operators may not want to do this provisioning in order to make 
    s2s work. in that case, dialback provides protection against a trivial 
    attack with no cost of provisioning
        of course, these positions aren't necessarily contradictory, e.g., xmpp 
    could require that products implement TLS/SASL, but allow operators don't 
    have to fully provision their use. ]
        ACTION: Discuss and resolve on the mailing list.
        XMPP Core: Internationalization
            - clarified unicode usage and character encodings
            - added stringprep profiles as new I-Ds
            - optional xml:lang attribute on child elements that may contain 
    natural language CDATA
        Martin: The lack of negotiation may be a problem, other protocols 
    allow negotiation.
        Lisa: This isn't a stated requirement.
        Pete: No concensus to add it.
        XMPP Core: Error Handling
            - New extensible syntax superseding DATA error messages for 
            - Classes for address, format, redirect, and server
            - Better than the old HTTP-style error codes for stanzas
            - Classes for access, address, app, format, recipient, and server
        [ scribe's summary ... at this point, there was a long discussion 
    about the need for working groups being able to assign URNs in their 
    documents. ]
        ACTION: The ADs will consult with Michael Mealling.
        XMPP IM: Delta
            - Specified roster/subscription interaction
            - Updated error handling to track XMPP core
            - Modified privacy list protocol to address 2779 
    requirements regarding communications blocking.
        No discussion.
        XMPP IM: Open Issues
            - There are a couple of things in 2779's requirements that need 
    some clarification (5.1.3 & 5.1.4)
        Dale: Are temporary subscriptions supported?
        Lisa: There isn't a requirement for timing out a subscription.
        Joe: But I can show you how to do it with the existing specs.
        Derek: 5.1.3 says that the protocol must support 
    un-authenticated subscription requests (emphasis on 
    un-authenticated request).
        Derek: i *believe* that 5.1.4 can be satisifed by MIC rather than ACK, 
    but further investigation is required.
    Joe: Stringprep, e2e-encryption, and TINS
        Stringprep Profiles
            - the only place where strings are compared are JIDs
            - user: nodeprep (case insensitive, no "@", etc.)
            - host: IDNA (case insensitive, DNS restrictions)
            - resource: resourceprep (case sensitive)
        Sam: Besides JIDs, SASL adds additional string operations, both 
    internally and when mapping to JIDs
        Patrik: What's the relationship to the localpart of email 
        Pete: email localparts aren't case-insensitive.
            - Adding support for replay-protection 
            - Lots of open issues to deal with
            - This is all preliminary
        [ scribe's summary ... at this point, there was considerable 
    discussion about inadequacies in the preliminary approach, not all of 
    which were consistent, e.g., should XMLDSIG be used, or the CPIM 
    format... ]
        ACTION: Discuss and refine on the mailing list.
        TINS: Not a WG item
            - TINS = SDPng over XMPP
            - TINS = Transport for Initiating and Negotiating Sessions
            - SDPng = SDP written using XML
            - Perhaps good for including in an SDPng appendix?
        No discussion.
    Lisa/Pete: Adjourn.


    'Jabber' - *prep, e2e, TINS
    XMPP Delta