2.1.5 Extensible Messaging and Presence Protocol (xmpp)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

Chair(s):
Pete Resnick <presnick@qualcomm.com>
Lisa Dusseault <lisa@xythos.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.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:
Done  Prepare revised specifications reflecting issues and solutions identified by the working group
Done  Meet at the 55th IETF to discuss current drafts
Done  Prepare final core protocol draft ready for working group last call
Done  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
Internet-Drafts:
  • - draft-ietf-xmpp-im-18.txt
  • - draft-ietf-xmpp-core-19.txt
  • - draft-ietf-xmpp-e2e-05.txt
  • - draft-ietf-xmpp-cpim-02.txt
  • No Request For Comments

    Current Meeting Report

    granular.MINUTES  
    XMPP WORKING GROUP
    IETF 58 2003-11-14    09:00 - 11:30 
    
    Chairs: Lisa Dusseault, Pete Resnick Scribe: Marshall T. Rose 
    
    1.  Call to order and administrivia 
    
    The meeting was called to order at 09:03 by the chairs. 
    
    No changes to the agenda were suggested. 
    
    The meeting is being xmpp'cast at xmpp@ietf.xmpp.org. 
    
     2 . Status of Core/IM Documents - 
    http://www.jabber.org/ietf/58/psa 
    
    Peter St.Andre described changes made to the documents since IESG last 
    call. 
    
    The chairs asked if all issues had been addressed. 
    
    Kurt Zeilenga thought some of his minor editorial issues may have been 
    missed and will check. 
    
    Jeff Altman indicated that the SAAG had a discussion regarding 
    sasl/tls, in which tls should be ignored. However, some others in the room 
    weren't sure that the discussion was definitive. He will research the 
    issue further and provide text, if needed. 
    
    Rohan Mahy asked whether SASL was mandatory if TLS was used (if TLS 
    client-side authentication occurs, then SASL EXTERNAL, provides no 
    additional functionality, but does introduce a round-trip). The 
    concensus was that the existing document reflects current practice from a 
    number of appliation protocols, and would not be changed. 
    
    No other issues were arising. 
    
    The chairs indicated that in both cases, these minor changes could be be 
    added during the 48-hour period, if warranted. 
    
    Accordingly, the chairs declared the documents "done". 
    
     3.  Status of E2E/CPIM documents - 
    http://www.jabber.org/ietf/58/psa 
    
    Peter St. Andre described changes made to the documents since IETF57. 
    
    The documents are essentially unaltered for the last three months. 
    
    Ted Hardie indicated that the IMPP DNS SRV document establishes a 
    registry, and that one of the XMPP documents should include a section 
    registering XMPP's IM application. 
    
    No new issues were raised. 
    
    Accordingly the chairs have an action to issue a WG last call on the 
    remaining two documents; further, the editor has an action to add a  
    registration section as discussed above. 
    
     4.  Call for Implementation reports 
    
    Ted Hardie asked whether there were implementation reports of the E2E and 
    CPIM documents, although Perry Metzger questioned whether that was within 
    the scope of the existing charter. Ted Hardie indicated that he thought 
    that common handles would be considered within scope. 
    
    Lisa Dusseault reported that there had been some experience with CPIM, 
    though not with E2E. Cullen Jennings reported that some testing has been 
    done at a SIP interoperability event with an open source s/mime client. 
    
    Different XMPP (nee Jabber) implementors indicated that they were able to 
    successfull integrate the Core and IM documents with their existing 
    implementations. 
    
    Accordingly, Joe Hildebrand took an action to review the state of common 
    handles with respect to XMPP. 
    
    5.  Related Work and Next Steps 
    
    Lisa Dusseault made a brief presentation about several possible areas for 
    extensions, e.g., extended presence, application notifications, and 
    conferencing. 
    
       
    <http://www.sharemation.com/~milele/p
    ublic/notifications/notification-architecture.ppt> 
    
    It is an open issue was to whether these should be pursued in a future XMPP 
    extensions WG, or other WGs. For example, there was considerable 
    discussion regarding possible conferencing overlap with the XCON WG. In 
    particular, XMPP already has a robust, mature multi-user chat (MUC) 
    protocol. 
    
    It was noted that in many cases, an XMPP-centric perspective is 
    appropriate, although this was not universally agreed to. Further, it was 
    noted that moving XMPP-centric efforts into the IETF have value in 
    providing experience with respect to scaling and security, and that this is 
    particularly true for conferencing. 
    
    Accordingly, Lisa Dusseault will introduce an I-D on XMPP-based 
    notifications to the LEMONADE WG; further, the Peter St.Andre will 
    prepare an introduction to XMPP's MUC protocol for submission to the XCON 
    WG. Finally, the chairs took an action to start, on the WG mailing list, a 
    discussion of what kinds of extensions would be appropriate for IETF 
    consideration. 
    
    6.  Adjourn 
    
    The meeting adjourned at 10:25 
    
     
    

    Slides

    None received.