Re: 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