[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes



On Aug 13, 2009, at 6:46 AM, BONNAERENS Ben wrote:

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.



Dunno WHY it should say that; that's what I thought I read in the compound sentence I was trying to straighten out.

Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires e2e TLS even more strongly than did 3261 for original sips URIs. So if a URI used in a record-route resolves both TLS and non-TLS, there's a possibility that the return stroke might not use TLS, thereby breaking the e2e TLS requirement. But your proposed wording change seems to have the same effect.


I would also replace "sips: URI" by "SIPS URI" to be consistent across
the document.


That makes sense; I responded in the wording I thought Robert had used. But consistency with the document would be preferred. Your usage is also consistent with draft-ietf-sip-sips.

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?


Looks OK to me.

--
Dean