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 |