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.wil...@softarmor.com] > Sent: woensdag 12 augustus 2009 22:17 > To: Robert Sparks > Cc: Elwell, John; sip@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 > > > > _______________________________________________ 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
