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

2009/8/7 BONNAERENS Ben <ben.bonnaerens at alcatel-lucent.be>

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
> >
>
_______________________________________________
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