Skip to main content

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