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

I skipped straight to the end (will come back and read how you got  
there later).
But yes, I think the rewrite you have at the end says the the same  
thing.

RjS
On Aug 12, 2009, at 2:42 PM, Dean Willis wrote:

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