Salut Francois, I had a look at draft-ietf-sip-sips-05 and have a few comments. Apologies if some of these comments were already discussed.
Section 3.2, the following paragraph: Furthermore, consider the problem of using SIPS inside a dialog. If [EMAIL PROTECTED] sends a request to [EMAIL PROTECTED] using a SIPS Request-URI, then, according to [RFC3261 <http://tools.ietf.org/html/rfc3261> ]/8.1.1.8, "the Contact header field MUST contain a SIPS URI as well". This means that [EMAIL PROTECTED], upon sending a new Request within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS URI. If there is no Record-Route entry, or if the last Record-Route entry consist of a SIPS URI, this implies that [EMAIL PROTECTED] must understand SIPS in the first place, and must also support TLS. If the last Record-Route entry however is a sip URI, then b would be able to send requests without using TLS (but b would still have to be able to handle SIPS schemes when parsing the message). In either case, the Request-URI in the request from [EMAIL PROTECTED] to B would be a SIPS URI. According to 3261, the uri type found in the route is ignored if the request-uri is sips: "Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI." RFC3261, section 8.1.2 If my thinking is right, this possibly creates an odd situation if the last hop proxy is a 2543 implementation that does not do loose routing (do these still exist?). My take is that if the proxy is a loose router and inserts a "sip" route, at the UA sending a request, the request-uri is a "sips" URI, then TLS should be used. However, if the proxy is not a loose router and inserts a "sip" route, then at the UA sending a request, the request-URI will no longer be a "sips" URI but a "sip" URI, thus allowing a different resolution mechanism. I wonder if this is worth mentionning in the draft. End of 3.2: SIPS URIs can even be used in other protocols that allow for including SIPS URIs (e.g., HTML). Since HTML is not really a protocol, I would suggest the following sentence: SIPS URIs can even be used in other protocols and documents that allow for including SIPS URIs (e.g., HTML). Section 3.4: When [I-D.ietf-sip-outbound <http://tools.ietf.org/html/draft-ietf-sip-sips-05#ref-I-D.ietf-sip-outb ound> ] is used, a transport parameter in a REGISTER message would normally be ignored since the existing I guess you mean "a transport parameter in a Contact-URI of a REGISTER message..."? Section 4.1.2: If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR MUST be used by the UAC in the REGISTER. Which AOR are we talking abou? I guess you mean here: "..., a SIPS AOR MUST be used in the To header of the REGISTER". It is confusing as there are two AORs in a REGISTER. The To and From, which can potentially be different. Does this whole paragraph applies to both From and To AORs? Best Regards, EricT
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
