Skip to main content

Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF)
RFC 7355

Yes

(Alissa Cooper)
(Richard Barnes)
(Spencer Dawkins)

No Objection

(Adrian Farrel)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)

Note: This ballot was opened for revision 01 and is now closed.

(Alissa Cooper; former steering group member) Yes

Yes (for -01)

                            

(Richard Barnes; former steering group member) Yes

Yes (for -01)

                            

(Spencer Dawkins; former steering group member) Yes

Yes (for -01)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (for -01)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2014-06-21 for -01)
-- Section 1 --
The HTTP reference needs to change to RFC 7230.

-- Section 5.1 --
A tiny point: it seems to me that the code snippet would be better in an appendix, referred to from here and from Section 5.2.  It seems an unnecessary distraction here.

-- Section 6 --
The string "draft-ietf-sipcore-sip-websocket" is a vestige, and should now be "RFC 7118".  Better, though, more useful, would be a change such as this:

OLD
   Any security considerations specific to the WebSocket protocol or its
   application as a transport for SIP are detailed in the relevant
   specifications (RFC 6455 [RFC6455] and draft-ietf-sipcore-sip-
   websocket [RFC7118]) and are considered outside the scope of this
   document.
NEW
   Any security considerations specific to the WebSocket protocol or its
   application as a transport for SIP are detailed in the relevant
   specifications (the WebSocket potocol [RFC6455] and SIP over
   WebSockets [RFC7118]) and are considered outside the scope of this
   document.
END

-- Section 7 --
The reference document for the IANA registration shouldn't really be this document, as this document doesn't say much.  The right reference is RFC 7118, where people who want to understand SIP over WebSockets need to go.  Or, if you prefer, you can list both documents ("[RFC_XXXX_], [RFC7118]").

(Benoît Claise; former steering group member) No Objection

No Objection (2014-06-24 for -01)
Am I correct that this document doesn't update RFC 6872,  because it only adds a new value for the "Transport Flag" field (as opposed to a new field), and therefore the information model is not updated?

From idnits:

  -- Obsolete informational reference (is this intentional?): RFC 2616
     (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)

(Jari Arkko; former steering group member) No Objection

No Objection (for -01)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -01)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -01)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -01)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2014-06-25 for -01)
The document shepherd actually got one bit incorrect: This is simply a registration in a registry that only requires "IETF Review", not "Standards Action", so Informational would be perfectly appropriate for this document. It's never going to advance to Internet Standard, and I see no particular reason to have another Proposed Standard hanging around, so we should just make this Informational (which we can simply do on the call). I'm certainly not willing to hold things up if anyone objects, but it seems like a reasonable thing.

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-06-25 for -01)
- section 4: Surely this is badly stated: "SIP messages
transported over both a plain and secure WebSocket
connection can be completely and uniquely represented by
appropriately setting these two flag fields." I read that as
saying that two flags can uniquely represent a specific
message.

(Ted Lemon; former steering group member) No Objection

No Objection (2014-06-26 for -01)
Rather than providing perl code to unpack base64, you could just reference RFC 3548, which explains how to do it.   Having perl code and uudecode preambles is odd, given that uudecode won't actually decode the text, which is indented.   The perl code will work, since it strips leading spaces and doesn't require the begin and end markers to be at the beginning of the line.