internet-drafts | 21 Apr 02:31 2014

I-D Action: draft-ietf-xmpp-websocket-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : An XMPP Sub-protocol for WebSocket
        Authors         : Lance Stout
                          Jack Moffitt
                          Eric Cestari
	Filename        : draft-ietf-xmpp-websocket-05.txt
	Pages           : 14
	Date            : 2014-04-20

   This document defines a binding for the XMPP protocol over a
   WebSocket transport layer.  A WebSocket binding for XMPP provides
   higher performance than the current HTTP binding for XMPP.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:
(Continue reading)

Lance Stout | 20 Apr 01:04 2014

Fwd: New Version Notification for draft-ietf-xmpp-websocket-03.txt


There are no protocol-affecting changes in this update. It re-organizes the text to give an up-front
description of the framing process, and other editorial cleanup.

Begin forwarded message:

> From: internet-drafts <at>
> Subject: New Version Notification for draft-ietf-xmpp-websocket-03.txt
> Date: April 19, 2014 at 4:00:43 PM PDT
> To: "Lance Stout" <lance <at>>, Eric Cestari <eric <at>>, "Eric Cestari"
<eric <at>>, "Jack Moffitt" <jack <at>>, Lance Stout <lance <at>>, Jack Moffitt <jack <at>>
> A new version of I-D, draft-ietf-xmpp-websocket-03.txt
> has been successfully submitted by Lance Stout and posted to the
> IETF repository.
> Name:		draft-ietf-xmpp-websocket
> Revision:	03
> Title:		An XMPP Sub-protocol for WebSocket
> Document date:	2014-04-19
> Group:		xmpp
> Pages:		13
> URL:  
> Status:
> Htmlized:
> Diff: 
> Abstract:
(Continue reading)

Ben Campbell | 7 Apr 23:29 2014

WGLC of draft-ietf-xmpp-websocket-02

This is a Working Group Last Call of draft-ietf-xmpp-websocket-02. The draft is available at the
following URL:

The WGLC will conclude on 21 April, 2014. Please send your comments to the authors and the XMPP mailing list.


Peter Saint-Andre | 7 Apr 00:08 2014

Fwd: [Stox] WGLC for draft-ietf-stox-groupchat-04


-------- Original Message --------
Subject: [Stox] WGLC for draft-ietf-stox-groupchat-04
Date: Sun, 6 Apr 2014 20:20:39 +0200
From: Yana Stamcheva <yana <at>>
To: stox <at>

The editors and the chairs believe that the following draft is now ready 
and hereby start a 2-week Working Group Last Call for:

draft-ietf-stox-groupchat-04 : (Last updated on 

The WGLC ends on April 21, 2014.

Please review the document and bring any remaining issues, or issues 
whose resolution is not satisfactory, to the attention of the Working 
Group on this list before April 21.

If after reviewing the document you find it complete and do not have any 
comments, please send a note to that effect as well!

Yana Stamcheva & Markus Isomaki
stox mailing list
stox <at>
(Continue reading)

Ben Campbell | 27 Mar 05:29 2014

Draft Minutes from London


The _draft_ minutes from the XMPP meeting in London are available at . Please send any corrections to the
chairs as soon as possible.


Ben Campbell | 17 Mar 20:50 2014

WGLC of draft-ietf-xmpp-6122bis-11

This is a Working Group Last Call of draft-ietf-xmpp-6122bis-11. The draft is available at the following URL:

The WGLC will conclude on 31 March, 2014. Please send your comments to the authors and the XMPP mailing list.


Peter Saint-Andre | 10 Mar 21:04 2014

XMPP over WebSocket schemas

As noted during the working group session last week, there's a small 
copy-and-paste error in the schema for the <open/> element: the 
see-other-uri attribute is allowed only on the <close/> element. Thus...


      <xs:element name='open'>
            <xs:extension base='empty'>
              <xs:attribute name='from' type='xs:string'
              <xs:attribute name='id' type='xs:string'
              <xs:attribute name='see-other-uri' type='xs:anyURI'
              <xs:attribute name='to' type='xs:string'
              <xs:attribute name='version' type='xs:decimal'
              <xs:attribute ref='xml:lang'


      <xs:element name='open'>
(Continue reading)

Joe Hildebrand (jhildebr | 8 Mar 12:11 2014

Comments on draft-alkemade-xmpp-iq-validation-00

(no hats)

Section 1: suggest s/it was found//

Before Section 4: suggest adding some examples in a new section.  Good
iq/response, spoofed response with different from (perhaps followed by
real response to make it clear), unexpected 'from' from the server

Section 4: suggest switching the order of 4.1 and 4.2.  current section
4.1 is an edge case, leading with the core mechanism is more understandible

Section 4.1: quote 6120 and 3920 directly if possible.

Section 4.2: we had lots of discussion over "unique".  We'll likely want
some flavor of that discussion in the final text.  For the MUST ignore
text, can the client log an error or notify the user?

Section 6: we'll likely want some security analysis here.

May a server perform this tracking too, and reject things that look like

This doc is a good start.  I think we should adopt it into the working
group immediately.


Joe Hildebrand
Carl Wallace | 6 Mar 16:12 2014

comments on draft-miller-xmpp-e2e-06

Section 1
- This may be in the reqs draft, but seems worth stating here that some
end points for a given recipient may share keys, some may use different
keys, some may have no keys and some may not support encryption or
signature verification at all.

Section 3
- What should the sender do if some end points for a recipient indicate
lack of support for encryption?  Are error responses helpful independent
of confirmation that some end points support encryption?  Is the intent
for messages to only be sent to end points that advertise support?

- Why not include an end point's key in its info results and enable return
of the encrypted SMK (or even CEK) with the encrypted payload (to save a
round trip).  Given a single message could trigger a number of requests
for the SMK, the option to include the encrypted CEK in the payload may be
worthwhile.  Including the encrypted CEK would help with storage too.

- Why is the SID required to be unique for a {sender, recipient, SMK}
tuple?  This would allow for the same SID to be used to name every SMK
used with a recipient.  Suggest unique for each recipient (i.e., SMK's are
uniquely identified by recipient+SID for a given sender).

- Discuss how multiple recipients are handled

- s/optionallly/optionally

- It would be nice to have a summary of new state information the sender
and recipient are required to manage (like SMKs) and significant new
operations (like authorization of key requests where a given recipient may
(Continue reading)

Peter Saint-Andre | 6 Mar 15:19 2014

message size

In the SAAG session just now, Daniel Kahn Gillmor just brought up an 
interesting issue about end-to-end message encryption in XMPP, and Matt 
Miller had an interesting reply. If we wanted to randomly change around 
the size of XMPP messages pre-encryption, we could easily add an XMPP 
extension to the payload and make the XML character data whatever size 
we please.

Stefan Strigler | 4 Mar 18:34 2014

Fwd: JSJac + WebSocket

From my perspective to updated draft looks very good and promising. JSJaC (and MongooseIM) will be updated
soon to reflect the changes.

Greets, Stefan 

Begin forwarded message:

> From: Peter Saint-Andre <stpeter <at>>
> Subject: JSJac + WebSocket
> Date: 25. Februar 2014 23:53:14 MEZ
> To: Stefan Strigler <stefan.strigler <at>>
> Cc: "lance <at>" <lance <at>>
> Hallo Stefan, Lance reports that Prosody and a few client libraries have been updated to reflect the
WebSocket consensus:
> Do you have a sense of when you might be able to update JSJaC? And it would be great if you could post to the
xmpp <at> list to say "the latest version looks good" so that we can show consensus. :-)
> Thanks!
> Peter

Attachment (smime.p7s): application/pkcs7-signature, 7883 bytes
(Continue reading)