[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] 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:dean.willis at softarmor.com]
> Sent: woensdag 12 augustus 2009 22:17
> To: Robert Sparks
> Cc: Elwell, John; sip at ietf.org; 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
>
>
>
>