[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes
Robert,
Yes, that would be a lot better.
Thanks.
John
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks at nostrum.com]
> Sent: 12 August 2009 02:35
> To: Elwell, John
> Cc: BONNAERENS Ben; sip at 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.bonnaerens at alcatel-lucent.be]
> >> Sent: 11 August 2009 12:44
> >> To: Elwell, John
> >> Cc: sip at 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-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> >>> Behalf Of Elwell, John
> >>> Sent: dinsdag 11 augustus 2009 10:44
> >>> To: BONNAERENS Ben; sip at 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.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
> >>>>>>
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> 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
>
>