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

Hello John,

What we are trying to say is that the URI, identifying the TLS
interface, placed 
in the Record-Route header must, after executing the RFC3263 DNS
procedureson it, 
result in the TLS transport being selected.

This can be a sips URI or a sip URI (so called "best effort TLS" in
[I-D.ietf-sip-sips] chapter 3.1.3) 
but we suggest to not use the deprecated "transport=tls" parameter.

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."  

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Elwell, John
> Sent: dinsdag 11 augustus 2009 10:44
> To: BONNAERENS Ben; [email protected]
> Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes
> 
> In that case, I obviously misunderstood the text in the current draft.
> What exactly is the meaning of "will need to leverage the 
> [RFC3263] mechanisms"?
> 
> John
> 
> > -----Original Message-----
> > From: BONNAERENS Ben [mailto:[email protected]]
> > Sent: 07 August 2009 14:57
> > To: Elwell, John; [email protected]
> > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes
> > 
> > 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