Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-sipcore-sip-websocket-08

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Jun 2013 09:49:27 +0200

Hi Suresh,

I reply again to your mail after having new rev 09 submitted:

2013/4/16 Suresh Krishnan <[email-masked]>:

> * Section 4.1
>
> There is no error handling specified. i.e. What happens if the server
> does not send a 101 reply with sip in the Sec-WebSocket-Protocol header?

Addressed in rev 09:

- Improved section "Handshake" (under "The WebSocket SIP
Sub-Protocol") by mentioning the error handling when establishing a
WebSocket connection.

> * Section 5.2
>
> The updated ABNF provided in section 5.2.1. is confusing. e.g. RFC4168
> specifies the entire transport rule as follows
>
> transport         =  "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
>                         / other-transport
>
> while this document just uses an incremental alternative and calls it an
> updated rule. I would have expected an *updated* rule to say
>
> transport         =  "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" / "WS"
>                         / "WSS" / other-transport

This has been explained within current mail thread. I expect then that
using the incremental style is appropriate.

> * Section 5.2.2
>
> RFC4168 does not update transport-param. Is this a copy and paste error?

Addressed in rev 09:

- Mention to RFC 4168 (SIP SCTP) removed from the "SIP URI Transport
Parameter" section.

> * Section 5.2.4
>
> Maybe it is just me, but the way I read it, this section leaves the
> client without any mandatory to implement transport protocol for SIP
> since it relaxes the need to implement UDP and TCP, as well as allowing
> the implementation of the websocket transport using a MAY.

Addressed by rev 09:

- "SIP transport implementation requirements" section clarified by
removing the "MAY" keyword and exact section from RFC 3261 section 18
amended.

Hope those actions address all the issues you reported.

Thanks a lot for your help and comments.

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