Skip to main content

An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket
draft-ietf-xmpp-websocket-10

Revision differences

Document history

Date Rev. By Action
2014-10-29
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-10-27
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-10-23
10 (System) RFC Editor state changed to RFC-EDITOR from IANA
2014-10-22
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-10-22
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-10-22
10 (System) IANA Action state changed to In Progress from On Hold
2014-10-10
10 (System) RFC Editor state changed to IANA from EDIT
2014-09-22
10 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-09-22
10 (System) RFC Editor state changed to EDIT
2014-09-22
10 (System) Announcement was received by RFC Editor
2014-09-22
10 (System) IANA Action state changed to On Hold from In Progress
2014-09-22
10 (System) IANA Action state changed to In Progress
2014-09-22
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-09-22
10 Amy Vezza IESG has approved the document
2014-09-22
10 Amy Vezza Closed "Approve" ballot
2014-09-22
10 Amy Vezza Ballot approval text was generated
2014-09-22
10 Amy Vezza Ballot writeup was changed
2014-09-22
10 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-09-11
10 Ted Lemon
[Ballot comment]
All of my DISCUSSes and comments have been addressed.  I include the discuss and comments below for future reference, but no further work …
[Ballot comment]
All of my DISCUSSes and comments have been addressed.  I include the discuss and comments below for future reference, but no further work need be done to address them.

Former DISCUSS:
In the security considerations section, it would help to discuss how the security model possible using websockets compares to the security model available for regular XMPP.  I find the lack of any discussion of this frustrating, but don't know enough about websockets to be able to describe the incongruity that seems to exist here.  The action item for this DISCUSS would be either to add some text discussing this.  I realize that that's vague, and so this is subject to negotiation on the call or by email—it's not my goal to hold up the document on this, just to see if it's possible to get more clarity.

The thing that leads me to worry about this is the inability of the client to actually know who it is talking to; the current text that talks about web host metadata (second paragraph) is useful, but leaves me wanting a bit more detailed discussion.

Aside from this and the comments below, the document is very clear and easy to follow.  Thanks for doing it!

Former comments:

I agree with Pete's comment.

In section 3.4, the example response does not include a "to" attribute as required by RFC 6120 section 4.7.2.  Am I missing something?

In section 3.5, are we sure that there are no connection initiation requests that could result in an error that would make it impossible to send a second frame?  Also, what does the client do if it receives a badly-formed open response, or if it receives something other than an open in response to an open?

In section 3.7, no reason is given for a stream restart being mandated.  Can you add a reference here (I assume this is described in detail in RFC 6120)?

In 3.8, suggest the following rewording:
OLD:
  The use of either of these extensions (or both) MAY be used to
  determine the state of the connection.
NEW:
  Either of these extensions (or both) MAY be used to
  determine the state of the connection.

Similarly in section 4:
OLD:
  Use of web-host metadata MAY be used to establish trust between the
  XMPP server domain and the WebSocket endpoint, particularly in multi-
  tenant situations where the same WebSocket endpoint is serving
  multiple XMPP domains.
NEW:
  Web-host metadata MAY be used to establish trust between the
  XMPP server domain and the WebSocket endpoint, particularly in multi-
  tenant situations where the same WebSocket endpoint is serving
  multiple XMPP domains.
2014-09-11
10 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss
2014-09-11
10 Stephen Farrell
[Ballot comment]

Thanks for handling my discuss, the result looks fine to me.

--- OLD comments below, I didn't check 'em.

- 3.1 you should …
[Ballot comment]

Thanks for handling my discuss, the result looks fine to me.

--- OLD comments below, I didn't check 'em.

- 3.1 you should explain the |thing| notation (or reference an
explanation)

- 3.6.1 - does the see-other-uri interact with the SOP if
running say a JS client in a browser? How? (Is such an
implementation a target?)

- 3.8 - looks to me that this makes those two XEPs normative
references. Just saying MAY does not mean that you don't have
to read them to implement, you do. I hope that's not a problem
for you but don't see that it should be since those are stable
enough references I guess.

- 3.9 - you say a "server" MUST NOT advertise TLS - that seems
a bit wrong - perhaps that'd be better as "a websocket
server's listener MUST NOT..." since I could have another
listener in the same process even that does native
xmpp/tls/tcp as well, right?
2014-09-11
10 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2014-09-10
10 Lance Stout New version available: draft-ietf-xmpp-websocket-10.txt
2014-08-13
09 Stephen Farrell
[Ballot discuss]

Some follow-up on -09, where I suggested:

OLD:

  2.  In situations where the domain of the XMPP server does not match
  …
[Ballot discuss]

Some follow-up on -09, where I suggested:

OLD:

  2.  In situations where the domain of the XMPP server does not match
      the web origin of the WebSocket endpoint (such as multi-tenant
      hosting situations, the host-meta process described under
      Section 4) MAY be used to delegate trust from the XMPP server
      domain to the WebSocket origin, as long as the host-meta request
      and response occurred over secure HTTP (with appropriate
      certificate verification as defined in [RFC2818]).

NEW:

  2.  In situations where the user agent has to deal with
      delegation and the domain of the XMPP server does not match
      the web origin of the WebSocket endpoint (such as multi-tenant
      hosting situations, the host-meta process described under
      Section 4) SHOULD be used to delegate trust from the XMPP server
      domain to the WebSocket origin, as long as the host-meta request
      and response occurred over secure HTTP (with appropriate
      certificate verification as defined in [RFC2818]).

(1) section 6, 2nd para: that last "MAY be used" seems broken
or am I wrong? You're saying that the webserver/websocket
listener on ws.example MAY be delegated as trusted for use of
this spec from the not-ws.example xmpp domain. I don't see how
that works without allowing for trivial impersonation. Can you
explain? (Sorry, didn't have time to go through the refs
properly.)
2014-08-13
09 Stephen Farrell Ballot discuss text updated for Stephen Farrell
2014-08-13
09 Stephen Farrell
[Ballot discuss]

(asked follow-up on -09)

(1) section 6, 2nd para: that last "MAY be used" seems broken
or am I wrong? You're saying that …
[Ballot discuss]

(asked follow-up on -09)

(1) section 6, 2nd para: that last "MAY be used" seems broken
or am I wrong? You're saying that the webserver/websocket
listener on ws.example MAY be delegated as trusted for use of
this spec from the not-ws.example xmpp domain. I don't see how
that works without allowing for trivial impersonation. Can you
explain? (Sorry, didn't have time to go through the refs
properly.)
2014-08-13
09 Stephen Farrell Ballot discuss text updated for Stephen Farrell
2014-08-11
09 Lance Stout New version available: draft-ietf-xmpp-websocket-09.txt
2014-07-22
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-07-22
08 Lance Stout IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-07-22
08 Lance Stout New version available: draft-ietf-xmpp-websocket-08.txt
2014-07-14
07 Dan Romascanu Request for Last Call review by GENART Completed: Ready. Reviewer: Dan Romascanu.
2014-07-10
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2014-07-10
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Magnus Nystrom.
2014-07-10
07 Stephen Farrell
[Ballot discuss]

(1) section 6, 2nd para: that last "MAY be used" seems broken
or am I wrong? You're saying that the webserver/websocket
listener on …
[Ballot discuss]

(1) section 6, 2nd para: that last "MAY be used" seems broken
or am I wrong? You're saying that the webserver/websocket
listener on ws.example MAY be delegated as trusted for use of
this spec from the not-ws.example xmpp domain. I don't see how
that works without allowing for trivial impersonation. Can you
explain? (Sorry, didn't have time to go through the refs
properly.)
2014-07-10
07 Stephen Farrell Ballot discuss text updated for Stephen Farrell
2014-07-10
07 Spencer Dawkins
[Ballot comment]
I found the document to be quite easy to read.

I support Ted's Discuss on security.

My apologies for the newbie question, but …
[Ballot comment]
I found the document to be quite easy to read.

I support Ted's Discuss on security.

My apologies for the newbie question, but in this text:

3.5.  Stream Errors

  Stream level errors in XMPP are terminal. 

is "terminal" a term of XMPP art, or does it mean "fatal"?
2014-07-10
07 Spencer Dawkins Ballot comment text updated for Spencer Dawkins
2014-07-10
07 Spencer Dawkins [Ballot comment]
I found the document to be quite easy to read.

I support Ted's Discuss on security.
2014-07-10
07 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-07-10
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-07-10
07 Stephen Farrell
[Ballot discuss]

(1) section 6, 2nd para: that last "MAY be used" seems broken
or am I wrong? You're saying that the webserver/websocket
listener on …
[Ballot discuss]

(1) section 6, 2nd para: that last "MAY be used" seems broken
or am I wrong? You're saying that the webserver/websocket
listener on ws.example MAY be delegated as trusted for use of
this spec from the not-ws.example xmpp domain. I don't see how
that works without allowing for trivial impersonation. Can you
explain? (Sorry, didn't have time to go through the refs
properly.)

(2) Just checking: 6.1 calls for e2e xmpp security. Did
someone check that this and that play nice together?  Where
that is either [1] or OTR.

  [1] https://tools.ietf.org/html/draft-miller-xmpp-e2e
2014-07-10
07 Stephen Farrell
[Ballot comment]


- 3.1 you should explain the |thing| notation (or reference an
explanation)

- 3.6.1 - does the see-other-uri interact with the SOP if …
[Ballot comment]


- 3.1 you should explain the |thing| notation (or reference an
explanation)

- 3.6.1 - does the see-other-uri interact with the SOP if
running say a JS client in a browser? How? (Is such an
implementation a target?)

- 3.8 - looks to me that this makes those two XEPs normative
references. Just saying MAY does not mean that you don't have
to read them to implement, you do. I hope that's not a problem
for you but don't see that it should be since those are stable
enough references I guess.

- 3.9 - you say a "server" MUST NOT advertise TLS - that seems
a bit wrong - perhaps that'd be better as "a websocket
server's listener MUST NOT..." since I could have another
listener in the same process even that does native
xmpp/tls/tcp as well, right?
2014-07-10
07 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2014-07-10
07 Ted Lemon
[Ballot discuss]
In the security considerations section, it would help to discuss how the security model possible using websockets compares to the security model available …
[Ballot discuss]
In the security considerations section, it would help to discuss how the security model possible using websockets compares to the security model available for regular XMPP.  I find the lack of any discussion of this frustrating, but don't know enough about websockets to be able to describe the incongruity that seems to exist here.  The action item for this DISCUSS would be either to add some text discussing this.  I realize that that's vague, and so this is subject to negotiation on the call or by email—it's not my goal to hold up the document on this, just to see if it's possible to get more clarity.

The thing that leads me to worry about this is the inability of the client to actually know who it is talking to; the current text that talks about web host metadata (second paragraph) is useful, but leaves me wanting a bit more detailed discussion.

Aside from this and the comments below, the document is very clear and easy to follow.  Thanks for doing it!
2014-07-10
07 Ted Lemon
[Ballot comment]
I agree with Pete's comment.

In section 3.4, the example response does not include a "to" attribute as required by RFC 6120 section …
[Ballot comment]
I agree with Pete's comment.

In section 3.4, the example response does not include a "to" attribute as required by RFC 6120 section 4.7.2.  Am I missing something?

In section 3.5, are we sure that there are no connection initiation requests that could result in an error that would make it impossible to send a second frame?  Also, what does the client do if it receives a badly-formed open response, or if it receives something other than an open in response to an open?

In section 3.7, no reason is given for a stream restart being mandated.  Can you add a reference here (I assume this is described in detail in RFC 6120)?

In 3.8, suggest the following rewording:
OLD:
  The use of either of these extensions (or both) MAY be used to
  determine the state of the connection.
NEW:
  Either of these extensions (or both) MAY be used to
  determine the state of the connection.

Similarly in section 4:
OLD:
  Use of web-host metadata MAY be used to establish trust between the
  XMPP server domain and the WebSocket endpoint, particularly in multi-
  tenant situations where the same WebSocket endpoint is serving
  multiple XMPP domains.
NEW:
  Web-host metadata MAY be used to establish trust between the
  XMPP server domain and the WebSocket endpoint, particularly in multi-
  tenant situations where the same WebSocket endpoint is serving
  multiple XMPP domains.
2014-07-10
07 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2014-07-10
07 Benoît Claise
[Ballot comment]
As noted by Jürgen in his OPS-DIR review:

This document defines how to run XMPP over WebSockets. The intended
status is standards track. …
[Ballot comment]
As noted by Jürgen in his OPS-DIR review:

This document defines how to run XMPP over WebSockets. The intended
status is standards track. I believe the document is in a good shape
and basically ready to go. In particular, I do not see that the XMPP
over WebSockets specification creates any operational issues.

Some editorial nits:

- Sec 1: The term 'raw socket' can be potentially mis-understood,
  perhaps simply remove 'over row sockets' completely (I think the
  message of the sentence remains intact without these words).

- Sec 3.1: The text says that both client and server MUST have |xmpp|
  in the list of protocols for the |Sec-WebSocket-Protocol| header.
  The text does not detail what happens if this is not the case. Is
  there be a defined behavior if this protocol negotiation fails?

- Sec 3.6.1: There is a closing parenthesis missing at the end of the
  first paragraph.

- Sec 3.9: Word missing in "it MUST be enabled the WebSocket layer",
  perhaps you meant "it MUST be enabled _by_ the WebSocket layer"?
2014-07-10
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-07-09
07 Kathleen Moriarty
[Ballot comment]
Thanks for addressing the SecDir comments: http://www.ietf.org/mail-archive/web/secdir/current/msg04891.html

Found a nit:
Section 3.9:  There is a word or two missing in the following sentence: …
[Ballot comment]
Thanks for addressing the SecDir comments: http://www.ietf.org/mail-archive/web/secdir/current/msg04891.html

Found a nit:
Section 3.9:  There is a word or two missing in the following sentence:
  Instead,
  when TLS is used, it MUST be enabled the WebSocket layer using secure
  WebSocket connections via the |wss| URI scheme.  (See Section 10.6 of
  [RFC6455].)
2014-07-09
07 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-07-08
07 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2014-07-08
07 Pete Resnick
[Ballot comment]
Just a comment, not a showstopper by any means:

Some of the MUSTs in this document seem kind of goofy. When I go …
[Ballot comment]
Just a comment, not a showstopper by any means:

Some of the MUSTs in this document seem kind of goofy. When I go to use a MUST, I usually ask myself, "What else could an implementer possibly do?", and if the answer is "If they don't do it, they're not implementing this protocol", then there's no need for the MUST. For example:

3.1:

  During the WebSocket handshake, the client MUST include the
  value |xmpp| in the list of protocols for the |Sec-WebSocket-
  Protocol| header.  The reply from the server MUST also contain |xmpp|
  in its own |Sec-WebSocket-Protocol| header in order for an XMPP sub-
  protocol connection to be established.

What else would an implementer do? Instead, try:

  In order to establish an XMPP sub-protocol connection,  during the
  WebScoket handshake, the client includes the value |xmpp| in the
  list of protocols for the |Sec-WebSocket-Protocol| header, and the
  server includes |xmpp| in its own |Sec-WebSocket-Protocol| header in
  the reply.

There are other examples of these sorts of uses in the document. On the flip side, it is useful to give requirements on the receiving side, like "An implementation MUST reject with an error any frame that does not begin with a '<'". An implementation might not think to do that, and it's important.

The world doesn't end if you don't fix these up; that's why this is only a comment. Implementers will probably figure out that if the spec says, "Foobar MUST be X", they should probably reject foobars that aren't X. But I do think it would help implementers if you used MUSTs where an implementer might get themselves in trouble, not to define some sort of "conformance criteria". I think it's worth having a run through the document and convince yourselves where these are and aren't helpful uses of the term.
2014-07-08
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-07-08
07 Barry Leiba
[Ballot comment]
It would be useful to add a sentence at the end of the introduction that tells people where to find the XSF XEP …
[Ballot comment]
It would be useful to add a sentence at the end of the introduction that tells people where to find the XSF XEP documents, perhaps including a root URI.

-- Section 3.1 --
The mechanism of using vertical bars instead of quotation marks jarred me at first, and I expected to see "|xmpp|" in the protocol.  It didn't take long to figure it out, but, as the notation is different to what we usually write, it might be useful to note it in Section 2, and explain when you use vertical bars and when you use quotes (I think the difference is protocol elements vs. prose).

It also might be useful to have a sentence introducing the example, which says, "The following is an example of a WebSocket handshake followed by an initial XMPP protocol exchange," or some such.  (Or you might make the example a figure, and put that in as a figure caption.)

-- Section 3.3.3 --

Editorial:
  The inclusion of XML declarations, however,
  is NOT RECOMMENDED as WebSocket messages are already mandated to be
  UTF-8 encoded and therefore would only add a constant size overhead
  to each message.

The subject of "would only add" is dangling.  I suggest this fix:

NEW
  The inclusion of XML declarations, however,
  is NOT RECOMMENDED, as WebSocket messages are already mandated to be
  UTF-8 encoded.  Inclusion of declarations would only add a constant
  size overhead to each message.
END

-- Section 3.6.1 --
Two nits:
1. "e.g." needs a comma after it (two places).
2. The first paragraph needs a second closing parenthesis before the final period.

A non-nit:
  If the server wishes at any point to instruct the client to move to a
  different WebSocket endpoint (e.g. for load balancing purposes), the
  server MAY send a  element and set the "see-other-uri"
  attribute to the URI of the new connection endpoint

With respect to the "MAY": what are the other ways of accomplishing this?

I think there aren't any; I think the "MAY" applies to the fact that the server can instruct the client, rather than (as written) how it does it. But you already start the whole thing with "If the server wishes," so I suggest that you just change "MAY send" to "sends" (and change "set" to "sets").  (I also think the second "MAY" isn't necessary, but at least it isn't wrong.)

-- Section 3.8 --
Nit: I think you don't need a comma after "sub-protocol" (but you do need commas both before and after "as such").

In the second paragraph, "the use may be used" needs rewording.  Just delete "The use of" to fix that.

-- Sction 3.10 --
The passive voice here leaves a question open: Can either the client or the server initiate this?  Or does it have be done by the client?  It would be good to put it in active voice, I think, as "In order to alleviate the problems of temporary disconnections, the client MAY use the XMPP Stream Management extension...."  And similarly for the second paragraph.

-- Section 6 --
Nit: The last paragraph is missing a closing parenthesis after "[RFC6455]".
2014-07-08
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-07-08
07 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-07-08
07 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-07-07
07 Jari Arkko
[Ballot comment]
Dan Romascanu raised two issues in his Gen-ART review. I have not seen a response yet, but these points should be at least …
[Ballot comment]
Dan Romascanu raised two issues in his Gen-ART review. I have not seen a response yet, but these points should be at least considered before approving the document.
2014-07-07
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-07-07
07 Richard Barnes IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-07-07
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-07-07
07 Richard Barnes Ballot has been issued
2014-07-07
07 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2014-07-07
07 Richard Barnes Created "Approve" ballot
2014-07-04
07 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-07-03
07 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2014-07-03
07 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2014-07-02
07 Dan Romascanu Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu.
2014-06-30
07 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-06-30
07 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-xmpp-websocket-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-xmpp-websocket-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the WebSocket Subprotocol Name subregistry of the WebSocket Protocol Registries located at:

http://www.iana.org/assignments/websocket/

a new subprotocol will be registered as follows:

Subprotocol Identifier: xmpp
Subprotocol Common Name: WebSocket Transport for the Extensible Messaging and Presence Protocol (XMPP)
Subprotocol Definition: [ RFC-to-be ]

Second, in the ns subregistry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns

a new namespace will be registered as follows:

ID: xmpp-framing
URI: urn:ietf:params:xml:ns:xmpp-framing
Filename:
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2014-06-27
07 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder.
2014-06-26
07 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2014-06-26
07 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2014-06-26
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2014-06-26
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2014-06-24
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2014-06-24
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2014-06-20
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-06-20
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An XMPP Sub-protocol for WebSocket) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An XMPP Sub-protocol for WebSocket) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'An XMPP Sub-protocol for WebSocket'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-06-20
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-06-20
07 Richard Barnes Placed on agenda for telechat - 2014-07-10
2014-06-20
07 Richard Barnes Last call was requested
2014-06-20
07 Richard Barnes Ballot approval text was generated
2014-06-20
07 Richard Barnes IESG state changed to Last Call Requested from Publication Requested
2014-06-20
07 Richard Barnes Ballot writeup was changed
2014-06-20
07 Richard Barnes Last call announcement was generated
2014-06-20
07 Richard Barnes Ballot writeup was changed
2014-06-20
07 Richard Barnes Last call announcement was generated
2014-06-20
07 Richard Barnes Ballot writeup was generated
2014-06-17
07 Amy Vezza Notification list changed to : xmpp-chairs@tools.ietf.org, draft-ietf-xmpp-websocket@tools.ietf.org, stpeter@jabber.org
2014-06-17
07 Ben Campbell
Shepherd writeup for draft-ietf-xmpp-websocket-07

1. Summary

The document shepherd is Peter Saint-Andre.

The responsible Area Director is Richard Barnes.

This document defines a binding for …
Shepherd writeup for draft-ietf-xmpp-websocket-07

1. Summary

The document shepherd is Peter Saint-Andre.

The responsible Area Director is Richard Barnes.

This document defines a binding for the XMPP protocol over a
WebSocket transport layer.  A WebSocket binding for XMPP provides
higher performance than BOSH, the current HTTP binding for XMPP
(which uses HTTP long polling).

The requested publication type is Proposed Standard because the
technology is now ready for wider implementation and deployment,
as well as interoperability testing.

2. Review and Consensus

Work on a WebSocket binding for XMPP began in 2010 with the first
version of draft-moffitt-xmpp-over-websocket and related code in
several XMPP projects. Since then, implementation and deployment
experience has led to several changes, most notably:

a. An explicit framing mechanism for opening and closing XMPP steams
  over the WebSocket binding using complete XML elements, instead
  of the opening and closing  and  tags as in the
  TCP binding specified in RFC 6120.

b. An HTTP-based discovery mechanism using Web Host Metadata (RFC 6145)
  and Web Linking (RFC 5988) with a link relation type of
  "urn:xmpp:alt-connections:websocket" consistent with the Alternative
  XMPP Connection Methods specification (XEP-0156) produced by the
  XMPP Standards Foundation.

The framing mechanism has been a matter, not exactly of controversy, but
at least of discussion. The approach settled on in version -01 of this
document (using complete XML elements instead of opening and closing
tags) gained favor among implementers because it is simpler to code for
the target audience of web developers. Once agreement was reached on
this approach, almost all of the server and client implementations were
quickly updated to follow draft-ietf-xmpp-websocket-01. (There are at
least 6 implementations of this specification.)

Although the document has not generated a great deal of traffic on the
XMPP WG mailing list, discussion at IETF 88 (Vancouver) and afterward
among implementers at XMPP Summit 15 (Brussels) was robust, and further
reviews and revisions occurred soon after IETF 89 (London). Version 07
of the document incorporates all of the feedback receieved during those
discussions.

3. Intellectual Property

All three authors have confirmed that they are not personally aware of
any IPR related to this specification.

4. Other Points

The IANA Considerations section registers a WebSocket sub-protocol name
and a URN sub-namespace; both of these registries have a policy of First
Come First Served (see RFC 6455 and RFC 3688).

2014-06-17
07 Ben Campbell State Change Notice email list changed to xmpp-chairs@tools.ietf.org, draft-ietf-xmpp-websocket@tools.ietf.org
2014-06-17
07 Ben Campbell Responsible AD changed to Richard Barnes
2014-06-17
07 Ben Campbell IETF WG state changed to Submitted to IESG for Publication from WG Document
2014-06-17
07 Ben Campbell IESG state changed to Publication Requested
2014-06-17
07 Ben Campbell IESG process started in state Publication Requested
2014-06-17
07 Ben Campbell Intended Status changed to Proposed Standard from None
2014-06-16
07 Ben Campbell Changed document writeup
2014-06-16
07 Ben Campbell Document shepherd changed to Peter Saint-Andre
2014-06-06
07 Lance Stout New version available: draft-ietf-xmpp-websocket-07.txt
2014-04-22
06 Lance Stout New version available: draft-ietf-xmpp-websocket-06.txt
2014-04-20
05 Lance Stout New version available: draft-ietf-xmpp-websocket-05.txt
2014-04-20
04 Lance Stout New version available: draft-ietf-xmpp-websocket-04.txt
2014-04-19
03 Lance Stout New version available: draft-ietf-xmpp-websocket-03.txt
2014-03-14
02 Lance Stout New version available: draft-ietf-xmpp-websocket-02.txt
2014-02-14
01 Lance Stout New version available: draft-ietf-xmpp-websocket-01.txt
2013-09-05
00 Lance Stout New version available: draft-ietf-xmpp-websocket-00.txt