Re: draft-ietf-sip-record-route-fix-08 Changes

 

> -----Original Message-----
> From: BONNAERENS Ben [mailto:[email protected]] 
> Sent: 11 August 2009 12:44
> To: Elwell, John
> Cc: [email protected]; 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: [email protected] [mailto:[email protected]] On 
> > Behalf Of Elwell, John
> > Sent: dinsdag 11 augustus 2009 10:44
> > To: BONNAERENS Ben; [email protected]
> > 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:[email protected]]
> > > Sent: 07 August 2009 14:57
> > > To: Elwell, John; [email protected]
> > > 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:[email protected]]
> > > > Sent: donderdag 6 augustus 2009 9:37
> > > > To: BONNAERENS Ben; [email protected]
> > > > 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: [email protected] [mailto:[email protected]] On
> > > > Behalf Of
> > > > > BONNAERENS Ben
> > > > > Sent: 05 August 2009 15:23
> > > > > To: [email protected]
> > > > > 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 
> > > > > [email protected] for questions on 
> > current sip Use 
> > > > > [email protected] 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 
> > [email protected] for questions on current sip 
> > Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip