Marci. See below.
________________________________
From: Eric Tremblay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 14:21
To: Audet, Francois (SC100:3055)
Cc: sip List
Subject: draft-ietf-sip-sips-05 comments
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.
My vote is that this is too arcane to discuss.
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).
O k. Will fix.
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..."?
Y es, but this paragraph is being removed from the current version.
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?
Y es, to both. I'll fix.
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
