Re: draft-ietf-sip-record-route-fix-08 Changes

Hello Tomasz,
 
It can be a sips URI but it is not restricted to sips.
 
For example a SIP URI resolving to the TLS transport after executing the
RFC3263 procedures on it is possible.
 
Best regards & thanks,
Ben.
 
RFC3263 Chapter 4.1
"   First, a client resolving a SIPS URI MUST discard any services that
   do not contain "SIPS" as the protocol in the service field.  The
   converse is not true, however.  A client resolving a SIP URI SHOULD
   retain records with "SIPS" as the protocol, if the client supports
   TLS."  
 
[I-D.ietf-sip-sips] Section 3.1.3 ~ "best effort TLS"
 
 


________________________________

	From: Tomasz Zieleniewski [mailto:[email protected]] 
	Sent: dinsdag 11 augustus 2009 13:02
	To: BONNAERENS Ben
	Cc: Elwell, John; [email protected]
	Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes
	
	
	Hello Ben,
	
	Can we say in other words that proxy in such case should 
	indicate used TLS transport by inserting the sips URI in the 
	Record-Route header instead of using transport=tls parameter.
	
	Kind regards,
	- Tomasz Zieleniewski
	
	
	2009/8/7 BONNAERENS Ben <[email protected]>
	

		Hello John,
		

		> Well, I know what this means, but will your average
reader
		> understand it? I think we are trying to say something
along
		> the lines that if the transport protocol changes you
SHOULD
		> use the double Record-Route technique, where the
differences
		> in transport protocol are reflected in different
values of
		> the transport parameter (udp/tcp/sctp) and/or
different
		> values of the URI scheme (sip/sips). Correct?
		
		
		Your phrasing could lead to the understanding that we
suggest that
		only a sips URI can be used to identify the TLS
interface which is not
		correct.
		As the current text suggests, can the TLS interface be
identified by any
		URI
		(sip or sips ; excluding the deprecated transport=tls
parameter) that
		resolves via RFC3263 procedures to the TLS transport.
		
		IMHO leaves your suggested phrasing more room for
ambiguity
		compared to the current text.
		
		Best regards & thanks,
		
		Ben.
		

		> -----Original Message-----
		> From: Elwell, John
[mailto:[email protected]]
		> Sent: donderdag 6 augustus 2009 9:37
		> To: BONNAERENS Ben; [email protected]
		> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08
Changes
		>
		> Well, I know what this means, but will your average
reader
		> understand it? I think we are trying to say something
along
		> the lines that if the transport protocol changes you
SHOULD
		> use the double Record-Route technique, where the
differences
		> in transport protocol are reflected in different
values of
		> the transport parameter (udp/tcp/sctp) and/or
different
		> values of the URI scheme (sip/sips). Correct?
		>
		> John
		>
		> > -----Original Message-----
		> > From: [email protected]
[mailto:[email protected]] On
		> Behalf Of
		> > BONNAERENS Ben
		> > Sent: 05 August 2009 15:23
		> > To: [email protected]
		> > Subject: [Sip] draft-ietf-sip-record-route-fix-08
Changes
		> >
		> > Hi,
		> > version -08 of record-route fix has just been
submitted.
		> >
		> > Change log:
		> > - Changed its status from BCP to PS,
		> > - Take into account IESG reviews and subsequent
comments on the
		> > mailing lists, they were summarized in Robert
Sparks's document
		> > (rrf.txt), so it has been integrated in version -08
with minor
		> > refactoring from the authors (me and Ben).
		> >
		> > The thoughest part was related to the SIP/SIPS
question raised by
		> > Cullen
		>
(http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r
		> > oute-fix/c
		> > omment/98624/),
		> > so here is the text that was added in version -08 to
answer this
		> > question:
		> > "Thus, if the transport protocol changed between its
		> >    incoming and outgoing sides, the proxy SHOULD use
the double
		> >    Record-Route technique and SHOULD add a transport
		> parameter to each
		> >    of the Record-Route URIs it inserts. With the
exception
		> that if TLS
		> > is
		> >    used as the transport protocol on either side of
the
		> proxy, the URI
		> >    chosen to place in the Record-Route header field
value
		> reflecting
		> > the
		> >    interface using TLS will need to leverage the
[RFC3263]
		> mechanisms
		> > to
		> >    indicate that TLS must be used rather attempting
to use the
		> > deprecated
		> >    "transport=tls" URI parameter. See [RFC3261]
Section 26.2.2 and
		> >    [I-D.ietf-sip-sips] Section 3.1.4 for more
discussion."
		> >
		> > Brds,
		> > Thomas & Ben
		> > _______________________________________________
		> > Sip mailing list
https://www.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
		> >
		>
		_______________________________________________
		Sip mailing list
https://www.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

_______________________________________________
Sip mailing list  https://www.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