Robert, Yes, that would be a lot better.
Thanks. John > -----Original Message----- > From: Robert Sparks [mailto:rjspa...@nostrum.com] > Sent: 12 August 2009 02:35 > To: Elwell, John > Cc: BONNAERENS Ben; sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > John - > > Would this substitution address your concern? > > When TLS is used on the transport 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 use a sips: URI or > ensure that > a sip: > URI resolves (per the procedures of [RFC3263]) to using > TLS rather > than 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 > > RjS > > On Aug 11, 2009, at 7:21 AM, Elwell, John wrote: > > > > > > >> -----Original Message----- > >> From: BONNAERENS Ben [mailto:ben.bonnaer...@alcatel-lucent.be] > >> Sent: 11 August 2009 12:44 > >> To: Elwell, John > >> Cc: sip@ietf.org; Thomas Froment > >> Subject: RE: [Sip] 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. > > [JRE] So if you want to ensure TLS, either you use a sips URI or you > > populate your DNS records such that a sip URI always resolves to TLS > > transport - correct? > > If so, I think the average reader would have a hard time > deducing this > > from the present text. > > > > John > > > >> > >> 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: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On > >>> Behalf Of Elwell, John > >>> Sent: dinsdag 11 augustus 2009 10:44 > >>> To: BONNAERENS Ben; sip@ietf.org > >>> 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:ben.bonnaer...@alcatel-lucent.be] > >>>> Sent: 07 August 2009 14:57 > >>>> To: Elwell, John; sip@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.elw...@siemens-enterprise.com] > >>>>> Sent: donderdag 6 augustus 2009 9:37 > >>>>> To: BONNAERENS Ben; sip@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-boun...@ietf.org [mailto:sip-boun...@ietf.org] On > >>>>> Behalf Of > >>>>>> BONNAERENS Ben > >>>>>> Sent: 05 August 2009 15:23 > >>>>>> To: sip@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-implement...@cs.columbia.edu for questions on > >>> current sip Use > >>>>>> sipp...@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-implement...@cs.columbia.edu for questions on current sip > >>> Use sipp...@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-implement...@cs.columbia.edu for questions on current sip > > Use sipp...@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-implement...@cs.columbia.edu for questions on current sip Use sipp...@ietf.org for new developments on the application of sip
