[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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
>