Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes

["Elwell, John" <john.elwell at siemens-enterprise.com>]

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:ben.bonnaerens at alcatel-lucent.be] 
> Sent: 07 August 2009 14:57
> To: Elwell, John; sip at ietf.org
> 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:john.elwell at siemens-enterprise.com] 
> > Sent: donderdag 6 augustus 2009 9:37
> > To: BONNAERENS Ben; sip at ietf.org
> > 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> > Behalf Of 
> > > BONNAERENS Ben
> > > Sent: 05 August 2009 15:23
> > > To: sip at ietf.org
> > > 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 
> > > sip-implementors at cs.columbia.edu for questions on current sip Use 
> > > sipping at ietf.org for new developments on the application of sip
> > > 
> > 
>