Hi Iñaki, Thanks for the quick reply. Please find responses inline. On 04/16/2013 04:40 AM, Iñaki Baz Castillo wrote: > 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.
Great. > > > >> * 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? I saw Robert's response on the same topic and I will reply to that. If the WG's consensus is to go incremental, please stick with that. I just want to ensure that there is no ambiguity as to the final result. > > > >> * Section 5.2.2 >> >> RFC4168 does not update transport-param. Is this a copy and paste error? > > Yes, will be fixed. OK. > > > >> * 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. > ---------------- Looks good. Thanks Suresh _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
