Re: [xmpp] Proposed XMPP Charter Update

["Matt Miller (mamille2)" <[e-mail]>]

We have talked about OTR, but from what I remember, various folks haven't been interested in doing the work to bring it in.  Peter Saint-Andre might be able to speak more on that front.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.

On Feb 25, 2013, at 9:08 AM, Stephen Farrell <[e-mail]>
 wrote:

> 
> Hi,
> 
> I've no objection to this charter but do have a question:
> 
> Q: loads of us use OTR, but there's no mention of that
> in the charter - why don't we just spec that in an RFC?
> 
> Or two RFCs if need be, one for what's done now, one with
> any changes the WG think are needed and will be deployed.
> 
> A quick web search leads me to believe that this [1]
> might be how OTR works, but I could be wrong. Even having
> an informational RFC as a stable reference would seem
> to be an improvement.
> 
> Sorry if there's an obvious answer and I've not got the
> history.
> 
> Ta,
> S.
> 
> [1] http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html
> 
> On 02/21/2013 07:59 PM, Ben Campbell wrote:
>> Hi Everyone,
>> 
>> We need to do a minor charter update to add the XMPP/WebSockets work. 
>> 
>> Here's the proposed new text. This version is the same as before, except it removes the text for XMPP interworking with SIP/SIMPLE, an adds text for WebSockets. The new text is the second to last paragraph.
>> 
>> Please send any feedback to the XMPP mailing list as soon as possible. (If you agree with the text as is, please say that, too :-) )
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> -----------------
>> 
>> The Extensible Messaging and Presence Protocol (XMPP) is an
>> technology for the near-real-time exchange of messages and presence
>> notifications, where data is exchanged over Extensible Markup Language
>> (XML) streams. The original XMPP working group published RFCs 3920-3923.
>> 
>> Implementation and deployment experience since that time has resulted
>> in errata, clarifications, and suggestions for improvement to the core
>> XMPP specifications (RFCs 3920 and 3921). Some technologies on which
>> XMPP depends (e.g., Transport Layer Security and the Simple
>> Authentication and Security Layer) have undergone modifications of their
>> own, which XMPP needs to track. Finally, the group needs to define a
>> sustainable solution to internationalization of XMPP addresses, since
>> the approach taken in RFC 3920 (based on stringprep profiles) is limited
>> to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and
>> draft-saintandre-rfc3921bis-* reflect community input so
>> far regarding these modifications, but the group needs to complete this
>> work, especially with regard to internationalization. Because of the
>> scope of changes involved, it is envisioned that these specifications
>> will be cycled at Proposed Standard.
>> 
>> Although RFC 3923 defines an end-to-end signing and encryption
>> technology for use by XMPP systems, to date it has not been implemented.
>> A goal of the group is to develop an implementable method for end-to-end
>> encryption, preferably based on well known and widely deployed security
>> technologies.
>> 
>> XMPP uses TLS for encryption and the Simple Authentication and Security
>> Layer (SASL) for authentication. In the case of a server-to-server
>> stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism,
>> where each peer presents an X.509 certificate. This model introduces
>> scaling challenges in multi-domain deployments because RFC 3920 requires
>> that a stream cannot be reused for more than one domain, thus
>> necessitating multiple TCP connections. The group will work to overcome
>> these challenges by defining an optional mechanism for using a single
>> connection with multiple identities. It is anticipated that most of the
>> work will consist of defining and providing requirements to the TLS and
>> SASL working groups.
>> 
>> In addition to the TCP binding defined in RFC 6120, the XMPP community
>> has long employed an HTTP binding (XEP-0124 and XEP-0206 published by 
>> the XMPP Standards Foundation).  Given that this binding uses HTTP long 
>> polling, which has many known issues (RFC 6202), it is reasonable to 
>> transition to use of the WebSocket protocol (RFC 6455) instead.  Work has
>> begun on defining a WebSocket subprotocol for XMPP 
>> (draft-moffitt-xmpp-over-websocket).  The group will complete the 
>> definition of such a subprotocol, and coordinate reviews with the HYBI WG 
>> where appropriate.
>> 
>> In completing its work, the group will strive to retain backwards
>> compatibility with RFCs 3920 and 3921. However, changes that are not
>> backwards compatible might be accepted if the group determines that the
>> changes are required to meet the group's technical objectives and the
>> group clearly documents the reasons for making them.
>> _______________________________________________
>> xmpp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xmpp
>> 
>> 
> _______________________________________________
> xmpp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xmpp