[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes
> -----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
> >
>