Last Modified: 2003-02-14
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.
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 |
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 Internationalization 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 usage. [ 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 streams - 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 addresses Pete: email localparts aren't case-insensitive. E2E-encryption - 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. |