Re: 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