Subject: [Sip] draft-ietf-sip-sips-05 comments

From: "Eric Tremblay" <[email-masked]>
Date: Wed, 22 Aug 2007 17:20:56 -0400

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
   a@A sends a request to b@B 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 b@B, 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 b@B 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 b@B 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Aug 2007 16:40:50 -0500

Marci. See below.

________________________________

	From: Eric Tremblay [mailto:[email-masked]] 
	Sent: Wednesday, August 22, 2007 14:21
	To: Audet, Francois (SC100:3055)
	Cc: sip List
	Subject: draft-ietf-sip-sips-05 comments

	Salut Francois, 

	Section 3.2, the following paragraph: 
	   Furthermore, consider the problem of using SIPS inside a
dialog.  If
	   a@A sends a request to b@B 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 b@B, 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 b@B 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 b@B 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: 
	
	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