The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-websocket-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-01-29
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-01-23
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-01-10
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-12-24
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-12-20
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-12-19
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-12-19
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-12-10
|
10 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-12-09
|
10 | (System) | RFC Editor state changed to EDIT |
2013-12-09
|
10 | (System) | Announcement was received by RFC Editor |
2013-12-09
|
10 | (System) | IANA Action state changed to In Progress |
2013-12-09
|
10 | Cindy Morgan | State changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2013-12-09
|
10 | Cindy Morgan | IESG has approved the document |
2013-12-09
|
10 | Cindy Morgan | Closed "Approve" ballot |
2013-12-09
|
10 | Cindy Morgan | Ballot approval text was generated |
2013-12-09
|
10 | Cindy Morgan | Ballot writeup was changed |
2013-12-01
|
10 | Pete Resnick | [Ballot comment] Thanks for addressing all of my comments. One suggestion for the new text in 4.2: If there is at least … [Ballot comment] Thanks for addressing all of my comments. One suggestion for the new text in 4.2: If there is at least one non-UTF-8 symbol in the whole SIP message (including headers and body) then the whole message MUST be sent within a WebSocket binary message. Just for clarity, I suggest instead: If there is any non-UTF-8 text data (or any non-textual data) in the any part of the SIP message (including headers and body) then the whole message MUST be sent within a WebSocket binary message. |
2013-12-01
|
10 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
2013-11-29
|
10 | Stephen Farrell | [Ballot comment] Thanks for handling my discuss. I think there was one more thing from the mail on that, but am not sure if that … [Ballot comment] Thanks for handling my discuss. I think there was one more thing from the mail on that, but am not sure if that needs to be included or not. The issue was how to know to which server you're supposed to be connected. Would it be better if 5.5 last para also said that when NAPTR/SRV can't be used if you want to make a call to "sips:joe@example.com" then your browser script should start with: "var conn = new WebSocket('wss://example.com:443')" Or is that stated somewhere else? (Or is it wrong maybe;-) -- old comments below write-up nit: AD should now be Richard I guess - Abstract: I don't get why this "updates" 3261? Isn't it ok to implement 3261 without this? I guess that's down to section 3 changing a 3261 MUST, but that still doesn't seem to require a 3261 implementer to do something different if they're not doing WS. (In which case, how is section 3 non-normative? Is the ref to section 3 in section 1 correct actually?) Aha! Is it 5.2 that you mean and is the reason for the updates because you're adding to the ABNF and don't want someone else to add a conflicting thing later? If so, saying that in section 1 would be good. (And its a fine reason to update 3261.) - 4.1: what is version 13? - Is 5.2.4 really an update to 3261? It doesn't seem like one to me, but rather you're saying that implementations of this are ok if they only do WS. That is a difference from, but not an update to, 3261. - 9.1 s/recommended/RECOMMENDED/ would be better if you do mean the 2119 term. - 10.2 - what's D2W mean? No harm explaining. - 9.2 seems to imply that 5246 needs to be a normative reference. |
2013-11-29
|
10 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-11-28
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-11-28
|
10 | Inaki Castillo | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-11-28
|
10 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-10.txt |
2013-07-31
|
09 | Adam Roach | Document shepherd changed to Paul Kyzivat |
2013-06-24
|
09 | Suresh Krishnan | Request for Telechat review by GENART Completed: Ready. Reviewer: Suresh Krishnan. |
2013-06-18
|
09 | Barry Leiba | [Ballot comment] I like this document, and think this extension to SIP will be useful. Substantive comments; these are non-blocking, but please consider them seriously, … [Ballot comment] I like this document, and think this extension to SIP will be useful. Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- General -- _This section is non-normative._ I understand that the WebSockets document does this, but... is this really necessary? The IETF manages to publish a large number of normative documents that contain non-normative sections, examples, and so on. Most of them don't have this silliness in them. This is non-blocking -- I can't justify a DISCUSS on this point -- but I *really* ask you not to do this. -- Section 4.1 -- In the description of the handshake, you say that the Sec-WebSocket-Protocol header must "include" and "contain" the string "sip". Does that mean that there might also be other things in the value of that header? Or should these say "consist of"? -- Section 5.2.4 -- I suggest wrapping this up by being explicit about the change to the 3261 text. Like this: ADD The sentence quoted above from [RFC3261] section 18 is thus amended as follows: All SIP elements MUST implement at least one of the following: * Both UDP and TCP * SIP WebSocket SIP elements MAY implement other protocols. END -- Section 6 -- Can you add any explanation of the differences among the various keepalives, and any advice about how one might choose which to use? Is there any reason to use multiple of them? If so, please explain; if not, please say so. ======== Other comments; no need to respond to these. Take them or modify them as you please: -- Section 4.2 -- I find this section very odd, though, I suppose, not objectionable. I expected he third sentence to say something like, "Therefore, everything's A-OK, and we can do SIP over WebSockets. But no, you simply say that the SIP clients and servers you're defining here are just like any other SIP clients and servers. Is this really necessary to say? Would anyone possibly imagine that, say, they could write a client that didn't do binary? -- Section 7 -- For many web applications the value of such a Cookie is provided by the web server once the user has authenticated themselves to the web server Oof. Can we avoid singular usage of "themselves"? It should work fine to say, "once the user is [or has] authenticated to the web server," leaving off the reflexive pronoun. |
2013-06-18
|
09 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2013-06-18
|
09 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2013-06-14
|
09 | Barry Leiba | [Ballot comment] I like this document, and think this extension to SIP will be useful. Substantive comments; these are non-blocking, but please consider them seriously, … [Ballot comment] I like this document, and think this extension to SIP will be useful. Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- General -- _This section is non-normative._ I understand that the WebSockets document does this, but... is this really necessary? The IETF manages to publish a large number of normative documents that contain non-normative sections, examples, and so on. Most of them don't have this silliness in them. This is non-blocking -- I can't justify a DISCUSS on this point -- but I *really* ask you not to do this. -- Section 4.1 -- In the description of the handshake, you say that the Sec-WebSocket-Protocol header must "include" and "contain" the string "sip". Does that mean that there might also be other things in the value of that header? Or should these say "consist of"? -- Section 5.2.3 -- Given draft-ietf-appsawg-http-forwarded (in the RFC Editor queue), which defines the HTTP "Forwarded" header, shouldn't this protocol also specify that if "received" *is* used, information should be taken from the handshake's "Forwarded" header if there is one? -- Section 5.2.4 -- I suggest wrapping this up by being explicit about the change to the 3261 text. Like this: ADD The sentence quoted above from [RFC3261] section 18 is thus amended as follows: All SIP elements MUST implement at least one of the following: * Both UDP and TCP * SIP WebSocket SIP elements MAY implement other protocols. END -- Section 6 -- Can you add any explanation of the differences among the various keepalives, and any advice about how one might choose which to use? Is there any reason to use multiple of them? If so, please explain; if not, please say so. ======== Other comments; no need to respond to these. Take them or modify them as you please: -- Section 4.2 -- I find this section very odd, though, I suppose, not objectionable. I expected he third sentence to say something like, "Therefore, everything's A-OK, and we can do SIP over WebSockets. But no, you simply say that the SIP clients and servers you're defining here are just like any other SIP clients and servers. Is this really necessary to say? Would anyone possibly imagine that, say, they could write a client that didn't do binary? -- Section 7 -- For many web applications the value of such a Cookie is provided by the web server once the user has authenticated themselves to the web server Oof. Can we avoid singular usage of "themselves"? It should work fine to say, "once the user is [or has] authenticated to the web server," leaving off the reflexive pronoun. |
2013-06-14
|
09 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2013-06-14
|
09 | Stephen Farrell | [Ballot discuss] Updated for -09: I think disuss points 1 & 2 are still not resolved. (1) I don't get why section 7 is non-normative? … [Ballot discuss] Updated for -09: I think disuss points 1 & 2 are still not resolved. (1) I don't get why section 7 is non-normative? Don't you (practically) have to require some method for user authentication? And if so, doesn't something have to be MTI so that a random client and a random server can choose that option and get interop? Also, depending on the fact that digest auth in SIP is MTI would only be right if that's actually used - is it? This also relates to the ongoing discussion generated by Yaron's secdir review [1] with which I mostly agree. That discussion is treading now well-worn ground about the difference between MTI and mandatory to use but looks like its heading in the right direction and the authors have said they'll be updating the draft because of it. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03890.html (2) 9.1 "probably not be appropriate" seems very vague. Can't you do better? Maybe say that different private keys SHOULD be used for these (as they're at different layers of the s/w stack). And you also need to consider how the subject name in the certificate(s) needs to (or doesn't need to) match any SIP identifiers. This was also raised in the secdir review. on Barry's discuss: HTTP Forwarded (and XFF) headers have some privacy considerations. If you are going to add text about using those, then you may need to also consider that. (I've not thought through whether it'd expose something that is sometimes better not always exposed in this case.) |
2013-06-14
|
09 | Stephen Farrell | [Ballot comment] write-up nit: AD should now be Richard I guess - Abstract: I don't get why this "updates" 3261? Isn't it ok to implement … [Ballot comment] write-up nit: AD should now be Richard I guess - Abstract: I don't get why this "updates" 3261? Isn't it ok to implement 3261 without this? I guess that's down to section 3 changing a 3261 MUST, but that still doesn't seem to require a 3261 implementer to do something different if they're not doing WS. (In which case, how is section 3 non-normative? Is the ref to section 3 in section 1 correct actually?) Aha! Is it 5.2 that you mean and is the reason for the updates because you're adding to the ABNF and don't want someone else to add a conflicting thing later? If so, saying that in section 1 would be good. (And its a fine reason to update 3261.) - 4.1: what is version 13? - Is 5.2.4 really an update to 3261? It doesn't seem like one to me, but rather you're saying that implementations of this are ok if they only do WS. That is a difference from, but not an update to, 3261. - 9.1 s/recommended/RECOMMENDED/ would be better if you do mean the 2119 term. - 10.2 - what's D2W mean? No harm explaining. - 9.2 seems to imply that 5246 needs to be a normative reference. |
2013-06-14
|
09 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2013-06-13
|
09 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-06-13
|
09 | Benoît Claise | [Ballot comment] - Agreed with Barry's comment on Section 3 " _This section is non-normative._" I see Section 3 as a useful introductory text, exactly … [Ballot comment] - Agreed with Barry's comment on Section 3 " _This section is non-normative._" I see Section 3 as a useful introductory text, exactly like Section 1. And ... Section 1 doesn't have "_This section is non-normative._ ". I wonder why if I follow your logic? If the Section 3 content was included in section 1, would this required "_This section is non-normative._If "? You see, " _This section is non-normative._" leads to so more questions than clarifications. Like Barry (and others), "I *really* ask you not to do this. " - - As far as I can tell at https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name, SIP will be the first RFC-specified assignment. From 6455 10. The request MAY include a header field with the name |Sec-WebSocket-Protocol|. If present, this value indicates one or more comma-separated subprotocol the client wishes to speak, ordered by preference. The elements that comprise this value MUST be non-empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616] and MUST all be unique strings. The ABNF for the value of this header field is 1#token, where the definitions of constructs and rules are as given in [RFC2616]. Should this document explain what happens if some other subprotocols are requested at the same time? Disclaimer: I'm not an expert in Websocket, and this comment might just prove it. In other words, if this is a stupid comment, don't bother replying. - Any reason why second paragraph of Section 4.1 is indented. I looks like a quotation Same remark for the last paragraph of section 5.1 |
2013-06-13
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-06-13
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-06-13
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-06-12
|
09 | Inaki Castillo | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-06-12
|
09 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-09.txt |
2013-06-12
|
08 | Ted Lemon | [Ballot comment] Joel noticed this in his comment: wss = tls in 5.2.1 sips + ws = port 443 in 5.3. wouldn't it … [Ballot comment] Joel noticed this in his comment: wss = tls in 5.2.1 sips + ws = port 443 in 5.3. wouldn't it be wss? If this is in fact a problem, the same problem might exist in 10.2: Services Field Protocol Reference -------------- -------- --------- SIP+D2W WS TBD: this document SIPS+D2W WS TBD: this document I am saying this not because I know it's wrong but because it looked like it might be, so no need to respond if this is in fact correct. I agree with Barry's comment on "_this section is non-normative_", and would tend to echo Pete's recommendation not to use UTF-8 transport. Overall, the document looks good—thanks for doing this work! |
2013-06-12
|
08 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-06-12
|
08 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-06-12
|
08 | Sean Turner | [Ballot comment] Support Stephen's discuss positions. |
2013-06-12
|
08 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-06-11
|
08 | Jari Arkko | [Ballot discuss] Suresh Krishnan's Gen-ART review caused some discussion between Suresh and the authors in April. My understanding is that changes were agreed. For instance, … [Ballot discuss] Suresh Krishnan's Gen-ART review caused some discussion between Suresh and the authors in April. My understanding is that changes were agreed. For instance, Suresh raised an issue about Section 5.2.2 mixing "transport" and "transport-param". I think it would be important to get this and possibly other agreed changes into the draft before the final approval. Will we see a -09 soon? |
2013-06-11
|
08 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2013-06-11
|
08 | Pete Resnick | [Ballot discuss] 4.2: There are two cases where I'm very worried about using UTF-8 framing for SIP messages: The first is for binary content, which … [Ballot discuss] 4.2: There are two cases where I'm very worried about using UTF-8 framing for SIP messages: The first is for binary content, which though relatively unused in SIP is still possible. For a binary body, you'd have to figure out some sort of encoding that could go into UTF-8 framing. The other case is body Content-Types that have non-ASCII and non-UTF-8 charsets. Again, rare, but I would hate to see how implementers deal with putting an ISO-2022-JP body into a UTF-8 frame. I think you've got two solutions: 1) Say "MUST NOT use UTF-8 framing for non-ASCII/UTF-8 data; or 2) Say "MUST use binary framing". I have a slight inclination towards simply requiring binary framing; it's simpler for the implementer and allowing UTF-8 framing at all makes it possible to accidentally do the wrong thing. But either one will do. |
2013-06-11
|
08 | Pete Resnick | [Ballot comment] I agree with Barry and Stephen regarding the labeling of non-normative sections, and go one step further: Your use of the word normative … [Ballot comment] I agree with Barry and Stephen regarding the labeling of non-normative sections, and go one step further: Your use of the word normative is pretty bogus. There are lots of statements throughout otherwise unlabeled sections that are not normative (i.e., do not describe a standard of behavior), and there are places in labeled non-normative sections that clearly do describe a standard of behavior. Please get rid of these labels. Describe what things need to be done for interoperability's sake with MUSTs and SHOULDs and use other descriptive text for the rest. At best, these are unnecessary distractions. At worst, their existence will have implementers ignoring important information. (Yes, this is just a COMMENT; I'm not going to pitch a fit if I end up in the rough on this point. But you're hearing from a few people that these statements are a problem and I hope you take that into account.) Abstract: This document normatively updates RFC 3261. What would it be to non-normatively update a document? Delete the word "normatively". 4.1: The WebSocket messages transmitted over this connection MUST conform to the negotiated WebSocket sub-protocol. This is a little ambiguous. Do you mean, "Messages other than SIP requests and responses MUST NOT be transmitted over this connection."? That makes a bit more sense to me. I'm not sure what the current sentence means. 5.1: Content-Length header in SIP messages is optional when they are transported using the WebSocket sub-protocol. The word "optional" sounds like a 2119 use to me. Any reason it's lowercase? (Note: Please don't just change it blindly. Maybe it's not meant as a 2119 use. In that case, you might want to change it to "not necessary". But I thought you might want to check it.) 5.2.3: I agree with Stephen that there's no need to update 3261, but rather say that SIP-over-Websocket simply relaxes a requirement of 3261. |
2013-06-11
|
08 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2013-06-11
|
08 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-06-10
|
08 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-06-10
|
08 | Stephen Farrell | [Ballot discuss] (1) I don't get why section 7 is non-normative? Don't you (practically) have to require some method for user authentication? And if so, … [Ballot discuss] (1) I don't get why section 7 is non-normative? Don't you (practically) have to require some method for user authentication? And if so, doesn't something have to be MTI so that a random client and a random server can choose that option and get interop? Also, depending on the fact that digest auth in SIP is MTI would only be right if that's actually used - is it? This also relates to the ongoing discussion generated by Yaron's secdir review [1] with which I mostly agree. That discussion is treading now well-worn ground about the difference between MTI and mandatory to use but looks like its heading in the right direction and the authors have said they'll be updating the draft because of it. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03890.html (2) 9.1 "probably not be appropriate" seems very vague. Can't you do better? Maybe say that different private keys SHOULD be used for these (as they're at different layers of the s/w stack). And you also need to consider how the subject name in the certificate(s) needs to (or doesn't need to) match any SIP identifiers. This was also raised in the secdir review. on Barry's discuss: HTTP Forwarded (and XFF) headers have some privacy considerations. If you are going to add text about using those, then you may need to also consider that. (I've not thought through whether it'd expose something that is sometimes better not always exposed in this case.) |
2013-06-10
|
08 | Stephen Farrell | [Ballot comment] write-up nit: AD should now be Richard I guess - Abstract: I don't get why this "updates" 3261? Isn't it ok to implement … [Ballot comment] write-up nit: AD should now be Richard I guess - Abstract: I don't get why this "updates" 3261? Isn't it ok to implement 3261 without this? I guess that's down to section 3 changing a 3261 MUST, but that still doesn't seem to require a 3261 implementer to do something different if they're not doing WS. (In which case, how is section 3 non-normative? Is the ref to section 3 in section 1 correct actually?) Aha! Is it 5.2 that you mean and is the reason for the updates because you're adding to the ABNF and don't want someone else to add a conflicting thing later? If so, saying that in section 1 would be good. (And its a fine reason to update 3261.) - 4.1: what is version 13? - Is 5.2.4 really an update to 3261? It doesn't seem like one to me, but rather you're saying that implementations of this are ok if they only do WS. That is a difference from, but not an update to, 3261. - 9.1 s/recommended/RECOMMENDED/ would be better if you do mean the 2119 term. - 10.2 - what's D2W mean? No harm explaining. - 9.2 seems to imply that 5246 needs to be a normative reference. |
2013-06-10
|
08 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-06-09
|
08 | Barry Leiba | [Ballot discuss] I like this document, and think this extension to SIP will be useful. I have one blocking point that should be easy to … [Ballot discuss] I like this document, and think this extension to SIP will be useful. I have one blocking point that should be easy to sort out, and then a few non-blocking comments that I hope you'll consider. -- Section 5.2.3 -- Given draft-ietf-appsawg-http-forwarded (in the RFC Editor queue), which defines the HTTP "Forwarded" header, shouldn't this protocol also specify that if "received" *is* used, information should be taken from the handshake's "Forwarded" header if there is one? |
2013-06-09
|
08 | Barry Leiba | [Ballot comment] Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- General -- … [Ballot comment] Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- General -- _This section is non-normative._ I understand that the WebSockets document does this, but... is this really necessary? The IETF manages to publish a large number of normative documents that contain non-normative sections, examples, and so on. Most of them don't have this silliness in them. This is non-blocking -- I can't justify a DISCUSS on this point -- but I *really* ask you not to do this. -- Section 4.1 -- In the description of the handshake, you say that the Sec-WebSocket-Protocol header must "include" and "contain" the string "sip". Does that mean that there might also be other things in the value of that header? Or should these say "consist of"? -- Section 5.2.4 -- I suggest wrapping this up by being explicit about the change to the 3261 text. Like this: ADD The sentence quoted above from [RFC3261] section 18 is thus amended as follows: All SIP elements MUST implement at least one of the following: * Both UDP and TCP * SIP WebSocket SIP elements MAY implement other protocols. END -- Section 6 -- Can you add any explanation of the differences among the various keepalives, and any advice about how one might choose which to use? Is there any reason to use multiple of them? If so, please explain; if not, please say so. ======== Other comments; no need to respond to these. Take them or modify them as you please: -- Section 4.2 -- I find this section very odd, though, I suppose, not objectionable. I expected he third sentence to say something like, "Therefore, everything's A-OK, and we can do SIP over WebSockets. But no, you simply say that the SIP clients and servers you're defining here are just like any other SIP clients and servers. Is this really necessary to say? Would anyone possibly imagine that, say, they could write a client that didn't do binary? -- Section 7 -- For many web applications the value of such a Cookie is provided by the web server once the user has authenticated themselves to the web server Oof. Can we avoid singular usage of "themselves"? It should work fine to say, "once the user is [or has] authenticated to the web server," leaving off the reflexive pronoun. |
2013-06-09
|
08 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-06-06
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Suresh Krishnan |
2013-06-06
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Suresh Krishnan |
2013-06-06
|
08 | Joel Jaeggli | [Ballot comment] draft-ietf-sipcore-sip-websocket 5.2.1 vs 5.3 wss = tls in 5.2.1 sips + ws = port 443 in 5.3. wouldn't it be wss? In … [Ballot comment] draft-ietf-sipcore-sip-websocket 5.2.1 vs 5.3 wss = tls in 5.2.1 sips + ws = port 443 in 5.3. wouldn't it be wss? In the absence of DNS SRV resource records or an explicit port, the default port for a SIP URI using the "sip" scheme and the "ws" transport parameter is 80, and the default port for a SIP URI using the "sips" scheme and the "ws" transport parameter is 443. |
2013-06-06
|
08 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-06-05
|
08 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-06-05
|
08 | Spencer Dawkins | [Ballot comment] I did have one question. In this text: 3. The WebSocket Protocol The WebSocket connection handshake is based on HTTP [RFC2616 … [Ballot comment] I did have one question. In this text: 3. The WebSocket Protocol The WebSocket connection handshake is based on HTTP [RFC2616] and utilizes the HTTP GET method with an "Upgrade" request. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, client and server agree on the application protocol to use on top of the WebSocket transport. Such application protocol (also known as a "WebSocket sub-protocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (as the WebSocket SIP sub-protocol defined in this document). Once the HTTP 101 response is processed both client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this ^^^^^^ ^^^^^ ^^^^ I think I understand what's meant here, but this statement doesn't seem quite right, when viewed through http://tools.ietf.org/html/rfc2616#section-8.1, which describes Persistent Connections. Could you look for more precise wording for this statement? connection is persistent and can be used for multiple message exchanges. |
2013-06-05
|
08 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2013-06-04
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-06-04
|
08 | (System) | IANA Review state changed to IANA - Review Needed from IANA OK - Actions Needed |
2013-06-04
|
08 | Richard Barnes | Ballot has been issued |
2013-06-04
|
08 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-06-04
|
08 | Richard Barnes | Created "Approve" ballot |
2013-06-04
|
08 | Richard Barnes | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-06-04
|
08 | Richard Barnes | Placed on agenda for telechat - 2013-06-13 |
2013-04-29
|
08 | Suresh Krishnan | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Suresh Krishnan. |
2013-04-15
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-04-11
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer. |
2013-04-04
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2013-04-04
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2013-04-04
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-04-04
|
08 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-sipcore-sip-websocket-08. 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-sipcore-sip-websocket-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA understands that, upon approval of this document, there are six actions which IANA must complete. First, in the WebSocket Subprotocol Name Registry in the WebSocket Protocol Registries located at: http://www.iana.org/assignments/websocket/websocket.xml a new sub-protocol will be registered as follows: Subprotocol Identifier: sip Subprotocol Common Name: WebSocket Transport for SIP (Session Initiation Protocol) Subprotocol Definition: [ RFC-to-be ] Reference: [ RFC=to |
2013-04-04
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2013-04-04
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2013-04-01
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-04-01
|
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The WebSocket Protocol as a Transport … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)) to Proposed Standard The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)' 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 2013-04-15. 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 The WebSocket protocol enables two-way realtime communication between clients and servers in web-based applications. This document specifies a WebSocket sub-protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in web-oriented deployments. This document normatively updates RFC 3261. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-04-01
|
08 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-04-01
|
08 | Amy Vezza | Last call announcement was generated |
2013-04-01
|
08 | Richard Barnes | Last call was requested |
2013-04-01
|
08 | Richard Barnes | Ballot approval text was generated |
2013-04-01
|
08 | Richard Barnes | State changed to Last Call Requested from AD Evaluation::AD Followup |
2013-03-20
|
08 | Richard Barnes | Ballot writeup was changed |
2013-03-20
|
08 | Richard Barnes | Ballot writeup was generated |
2013-03-20
|
08 | Richard Barnes | Last call announcement was generated |
2013-03-13
|
08 | Cindy Morgan | Shepherding AD changed to Richard Barnes |
2013-03-11
|
08 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-08.txt |
2013-02-17
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-02-17
|
07 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-07.txt |
2012-11-27
|
06 | Robert Sparks | State changed to AD Evaluation::Revised ID Needed from Publication Requested |
2012-11-09
|
06 | Cindy Morgan | > This is a request to publish draft-ietf-sipcore-sip-websocket-06.txt > as an RFC. I am acting as shepherd for this document. The document > shepherd write-up … > This is a request to publish draft-ietf-sipcore-sip-websocket-06.txt > as an RFC. I am acting as shepherd for this document. The document > shepherd write-up follows. Thanks. > > Paul Kyzivat > SIPCORE Co-Chair > > ---------------------------------------------------------------------- > > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? > > Standards Track > > Why is this the proper type of RFC? > > This document makes a normative revision to RFC 3261. > That requires a standards track document. > > Is this type of RFC indicated in the title page header? > > Yes > > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: > > Technical Summary > > The WebSocket protocol enables two-way realtime communication between > clients and servers. This document specifies a new WebSocket sub- > protocol as a reliable transport mechanism between SIP (Session > Initiation Protocol) entities to enable usage of SIP in new > scenarios. > > Working Group Summary > > The introduction, adoption, and last call of this document went > unusually smoothly and quickly. It has been amazingly uncontroversial. > > Document Quality > > Are there existing implementations of the protocol? > > Yes. At least two. > > Have a significant number of vendors indicated their plan to > implement the specification? > > At least two. There is a difference of opinion in the community > regarding the desirability of implementing SIP in a browser. > That portion of the community that is interested seems to be > planning to go ahead. It is entirely fine that some want to do > this and some do not. It simply reflects different philosophies > for construction of web-based services. > > Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? > > No. > > If there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? > > There is nothing in this document that calls for an > expert review. > > Personnel > > Who is the Document Shepherd? > > Paul Kyzivat > > Who is the Responsible Area Director? > > Robert Sparks > > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. > > I have followed this document throughout its evolution. > I also did a final read-through while preparing this writeup. > And I ran IdNits on it. > > I believe this doc is ready for forwarding to the IESG. > > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? > > No. It has been thoroughly reviewed. > > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. > > The use of web sockets changes how security works in subtle ways. > So careful review of that aspect would be helpful. > > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? For example, perhaps he or she is uncomfortable > with certain parts of the document, or has concerns whether there really > is a need for it. In any event, if the WG has discussed those issues and > has indicated that it still wishes to advance the document, detail those > concerns here. > > It's not really a concern, but this doc is unusual in changing the > mandatory to implement transports for SIP. After considerable > discussion we decided to handle this as a one-off revision that > is narrowly scoped. An alternative would have been to make a more > generic relaxation of the rules in 3261. > > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. If not, explain why. > > Yes > > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. > > None filed. > > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > Strong. As noted above, some consider this useful and some do not. > But there has been good support for the work and no objections. > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) > > No one has indicated extreme (or, AFAIK, any) discontent. > > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. > > There are a few spurious warnings about weird spacing. > These occur in examples, and are not errors. > > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. > > None of these apply to this document. > > (13) Have all references within this document been identified as > either normative or informative? > > Yes. > > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? > > No. > > (15) Are there downward normative references references (see RFC 3967)? > If so, list these downward references to support the Area Director in > the Last Call procedure. > > No. > > (16) Will publication of this document change the status of any > existing RFCs? > > Yes > > Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? > > Yes, yes, yes. > > If the RFCs are not > listed in the Abstract and Introduction, explain why, and point > to the > part of the document where the relationship of this document to the > other RFCs is discussed. If this information is not in the document, > explain why the WG considers it unnecessary. > > There is an entire section of the document entitled > "Updates to RFC 3261" > > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes > are associated with the appropriate reservations in IANA registries. > Confirm that any referenced IANA registries have been clearly > identified. Confirm that newly created IANA registries include a > detailed specification of the initial contents for the registry, that > allocations procedures for future registrations are defined, and a > reasonable name for the new registry has been suggested (see RFC 5226). > > No new registries are created. > The extensions are properly documented via existing IANA > registries. Those registries are all properly referenced. > > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. > > None > > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. > > None > |
2012-11-09
|
06 | Cindy Morgan | Note added 'Paul Kyzivat (pkyzivat@alum.mit.edu) is the document shepherd.' |
2012-11-09
|
06 | Cindy Morgan | Intended Status changed to Proposed Standard |
2012-11-09
|
06 | Cindy Morgan | IESG process started in state Publication Requested |
2012-11-09
|
06 | (System) | Earlier history may be found in the Comment Log for draft-ibc-sipcore-sip-websocket |
2012-11-06
|
06 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-06.txt |
2012-10-21
|
05 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-05.txt |
2012-10-01
|
04 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-04.txt |
2012-09-07
|
03 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-03.txt |
2012-07-30
|
02 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-02.txt |
2012-06-27
|
01 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-01.txt |
2012-05-05
|
00 | Inaki Castillo | New version available: draft-ietf-sipcore-sip-websocket-00.txt |