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 sip-implement...@cs.columbia.edu for questions on current sip
Use sipp...@ietf.org for new developments on the application of sip
