Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-05.txt

From: [email-masked]
Date: Sun, 21 Oct 2012 13:03:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

	Title           : The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)
	Author(s)       : Inaki Baz Castillo
                          Jose Luis Millan Villegas
                          Victor Pascual
	Filename        : draft-ietf-sipcore-sip-websocket-05.txt
	Pages           : 21
	Date            : 2012-10-21

Abstract:
   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.  This document normatively updates RFC 3261.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-websocket-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 21 Oct 2012 22:09:52 +0200

> http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-websocket-05

Hi all.

This new version of the draft includes the following changes given the
feedback given for the previous version 04:

- atlanta.com is replaced with example.com in flow examples.

- Abstract now mentions that this specification updates RFC 3261 and
Introduction gives more details.

- New requests in IANA Considerations section for the "SIP/SIPS URI
Parameters" Sub-Registry, "Header Fields" Sub-Registry and "Header
Field Parameters and Parameter Values" Sub-Registry.

As always your comments are welcome. Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Oct 2012 20:48:53 +0200

Random comments:

- If the RFC adds NAPTR records, should it update RFC 3263 as well?

- Section 9.1: I suggest using normative language and change "SIP traffic transported over
a websocket connection SHOULD be protected by using a WebSocket connection over TLS."

- Section 10.3 should propably mention "WS/WSS" transport identifiers - or?

I suggest that GRUU support is upgraded to a MUST. It's required for SIP subscriptions,
for transfers and many other operations that involve the Contact - which is quite a 
useless URI. All operations that involve the contact should hit the proxy.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Oct 2012 23:15:45 +0200

> - If the RFC adds NAPTR records, should it update RFC 3263 as well?

Hi, RFC 4168 (SIP SCTP transport) does not update RFC 3261 nor RFC
3263 (while it defines a new SIP transport and new NAPTR records).
I think that adding new NAPTR records does not mean that RFC 3263
should be updated since all what is said in RFC 3262 is still true and
does not change at all due to the addition of new NAPTR records. Am I
wrong?

> a websocket connection SHOULD be protected by using a WebSocket connection over TLS."

No RFC states that "SIP over TCP-TLS SHOULD be used" so I can't
understand the reason to mandate WebSocket over TLS. Thoughts?

> - Section 10.3 should propably mention "WS/WSS" transport identifiers - or?

As Robert explained in a previous mail: "the URI parameter registry
lists the names of the URI parameters, but not the values":

http://www.iana.org/assignments/sip-parameters

BTW take into account that this spec just defines a single value for
;transport parameter which is "ws". WSS justs exists in the Via header
(in the same way that TLS over TCP is represented with ;transport=tcp,
SIPS schema and TLS in the Via header).

> useless URI. All operations that involve the contact should hit the proxy.

While I mostly agree, this was already discussed in Paris some months
ago and there was consensus not to mandate GRUU (nor Outbound which
also makes sense).

Thanks a lot for your feedback.

-- 
Iñaki Baz Castillo
<[email-masked]>