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

Hello Dean,

Sorry to make your head hurt ;-)

To me the -09 sentence was clear but I do think you have a point on the
compound sentences.

Still I would like to comment on the "only" in following sentence of the
text you proposed:
"The second is for the URI placed in the Record-Route to be constructed
such that application of  RFC  
3263 resolution procedures to that URI produces a result reachable only
using TLS."

Why should that URI _only_ be reachable via TLS?
The DNS for that URI can be populated with NAPTR records
for multiple transports with TLS as preferred I assume.

I would also replace "sips: URI" by "SIPS URI" to be consistent across
the document.

Resulting in following updated text:
"When TLS is used on the transport on either side of the proxy,
the URI placed in the Record-Route header field  MUST encode 
a next-hop that will be reached using TLS. There are two  
ways for this to work. The first way is for the URI placed in the  
Record-Route to be a SIPS URI.The second is for the URI placed in  
the Record-Route to be constructed such that application of  
[RFC3263] resolution procedures to that URI results in TLS being
selected. 
Proxies compliant with this specification MUST NOT use a "transport=tls"

parameter on the URI placed in the Record-Route because the  
"transport=tls" usage was deprecated by RFC 3261."

Can we agree on this text?

Best regards & Thanks,

Ben.

> -----Original Message-----
> From: Dean Willis [mailto:[email protected]] 
> Sent: woensdag 12 augustus 2009 22:17
> To: Robert Sparks
> Cc: Elwell, John; [email protected]; BONNAERENS Ben
> Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes
> 
> 
> On Aug 11, 2009, at 8:35 PM, Robert Sparks wrote:
> 
> > 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
> >
> 
> 
> That makes my head hurt!
> 
> Compound sentences should make sense even with clauses redacted.
> 
> Let's play some games with this mind twister:
> 
> 
> First I'll try to scope the sub-clauses:
> 
> > (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).
> >
> 
> One reduction to see if it makes sense:
> 
> > When TLS is used the URI chosen to place in the Record-Route header 
> > field value 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.
> 
> 
> Let's pull some smaller pieces out of this:
> 
> > When TLS is used the URI chosen to place in the Record-Route header 
> > field value will need to use a sips: URI.
> 
> 
> "chosen to place" is clumsy. Let's substitute "placed", add a comma  
> for the subordination,  and see if it gets better.
> 
> > When TLS is used, the URI placed in the Record-Route header field  
> > value will need to use a sips: URI.
> 
> What does it mean for a URI to use a URI? I think perhaps it 
> needs to  
> BE a SIPS URI.
> 
> Rewritten:
> 
> > When TLS is used, the URI placed in the Record-Route header field  
> > value will need to be a sips: URI.
> 
> Now lets look at the other half of that clause:
> 
> > When TLS is used, the URI placed in the Record-Route header field  
> > value will need to 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.
> 
> 
> How does a URI ensure that a ensure something about a URI?
> 
> Maybe you mean:
> 
> > When TLS is used, the URI placed in the Record-Route header field  
> > value MUST resolve (per the procedures of [RFC3263]) to using TLS  
> > rather than attempting to use the deprecated  "transport=tls" URI  
> > parameter.
> 
> 
> I'm still stumbling over "resolve to using TLS rather than 
> attempting  
> to use the deprecated  "transport=tls" URI parameter." So let's just  
> lop off the sentence from "rather than . . ." and move that out.
> 
> What's wrong with
> 
> > When TLS is used, the URI placed in the Record-Route header field  
> > value MUST resolve (per the procedures of [RFC3263]) to using TLS .
> 
> Is "resolve to using TLS" the same thing as "resolve using TLS"? I  
> think they're subtly different, but the complexity still 
> scares me. I  
> think we're trying to say that the application of RFC 3263 
> procedures  
> to the URI must result in a next-hop that is reachable only by TLS.
> 
> So let's try a rewrite based on these assumptions. How about this:
> 
> > When TLS is used, the URI placed in the Record-Route header field  
> > MUST encode a next-hop that will be reached using TLS. 
> There are two  
> > ways for this to work. The first way is for the URI placed in the  
> > Record-Route to be a sips: URI. The second is for the URI 
> placed in  
> > the Record-Route to be constructed such that application of  RFC  
> > 3263 resolution procedures
> > to that URI produces a result reachable only using TLS. Proxies  
> > compliant with this specification MUST NOT use a "transport=tls"  
> > parameter on the URI placed in the Record-Route because the  
> > "transport=tls" usage was deprecated by RFC 3261.
> 
> Does that mean the same thing to you as the original megasentence did?
> 
> --
> Dean
> 
> 
> 
> 
_______________________________________________
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