Thanks a lot for your review Suresh. Please read replies inline:
2013/4/16 Suresh Krishnan <[email protected]>: > Summary: This draft is almost ready for publication as a Proposed > Standard, but has some minor issues that need to be fixed. > > * 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? It should be considered a SIP transport error, so a 503 SIP response should be locally generated. This will be added to that section. > * 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 There was a long discussion in SIPCORE WG about this subject and finally it was chosen to use the incremental alternative (so the updated ABNF would be also longer in the future when new SIP transports are defined). Do you consider anyhow that using the fully updated rule is required? > * Section 5.2.2 > > RFC4168 does not update transport-param. Is this a copy and paste error? Yes, will be fixed. > * 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. Yes, such a MAY sounds a look confusing. What the text wants to say is that a SIP WebSocket Client (which obviously implements the SIP WebSocket transport) is not mandated to implement UDP and TCP transports. I wil improve the text by removing the last words and leave it as follows: ---------------- The specification of this transport enables SIP to be used as a session establishment protocol in scenarios where none of other transport protocols defined for SIP can be used. Since some environments do not enable SIP elements to use UDP and TCP as SIP transport protocols, a SIP element acting as a SIP WebSocket Client is not mandated to implement support of UDP and TCP. ---------------- Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
