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

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

RjS

On Aug 11, 2009, at 7:21 AM, Elwell, John wrote:

>
>
>> -----Original Message-----
>> From: BONNAERENS Ben [mailto:[email protected]]
>> Sent: 11 August 2009 12:44
>> To: Elwell, John
>> Cc: [email protected]; Thomas Froment
>> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes
>>
>> Hello John,
>>
>> What we are trying to say is that the URI, identifying the TLS
>> interface, placed
>> in the Record-Route header must, after executing the RFC3263 DNS
>> procedureson it,
>> result in the TLS transport being selected.
>>
>> This can be a sips URI or a sip URI (so called "best effort TLS" in
>> [I-D.ietf-sip-sips] chapter 3.1.3)
>> but we suggest to not use the deprecated "transport=tls" parameter.
> [JRE] So if you want to ensure TLS, either you use a sips URI or you
> populate your DNS records such that a sip URI always resolves to TLS
> transport - correct?
> If so, I think the average reader would have a hard time deducing this
> from the present text.
>
> John
>
>>
>> Best regards &Thanks,
>>
>> Ben
>>
>> RFC3263 Chapter 4.1
>> "   First, a client resolving a SIPS URI MUST discard any
>> services that
>>   do not contain "SIPS" as the protocol in the service field.  The
>>   converse is not true, however.  A client resolving a SIP URI SHOULD
>>   retain records with "SIPS" as the protocol, if the client supports
>>   TLS."
>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]] On
>>> Behalf Of Elwell, John
>>> Sent: dinsdag 11 augustus 2009 10:44
>>> To: BONNAERENS Ben; [email protected]
>>> Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes
>>>
>>> In that case, I obviously misunderstood the text in the
>> current draft.
>>> What exactly is the meaning of "will need to leverage the
>>> [RFC3263] mechanisms"?
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: BONNAERENS Ben [mailto:[email protected]]
>>>> Sent: 07 August 2009 14:57
>>>> To: Elwell, John; [email protected]
>>>> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes
>>>>
>>>> Hello John,
>>>>
>>>>> Well, I know what this means, but will your average reader
>>>>> understand it? I think we are trying to say something along the
>>>>> lines that if the transport protocol changes you SHOULD use the
>>>>> double Record-Route technique, where the differences in
>> transport
>>>>> protocol are reflected in different values of the transport
>>>>> parameter (udp/tcp/sctp) and/or different values of the
>>> URI scheme
>>>>> (sip/sips). Correct?
>>>>
>>>> Your phrasing could lead to the understanding that we
>> suggest that
>>>> only a sips URI can be used to identify the TLS interface
>>> which is not
>>>> correct.
>>>> As the current text suggests, can the TLS interface be
>>> identified by
>>>> any URI (sip or sips ; excluding the deprecated transport=tls
>>>> parameter) that resolves via RFC3263 procedures to the TLS
>>> transport.
>>>>
>>>> IMHO leaves your suggested phrasing more room for ambiguity
>>> compared
>>>> to the current text.
>>>>
>>>> Best regards & thanks,
>>>>
>>>> Ben.
>>>>
>>>>> -----Original Message-----
>>>>> From: Elwell, John [mailto:[email protected]]
>>>>> Sent: donderdag 6 augustus 2009 9:37
>>>>> To: BONNAERENS Ben; [email protected]
>>>>> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes
>>>>>
>>>>> Well, I know what this means, but will your average reader
>>>>> understand it? I think we are trying to say something along the
>>>>> lines that if the transport protocol changes you SHOULD use the
>>>>> double Record-Route technique, where the differences in
>> transport
>>>>> protocol are reflected in different values of the transport
>>>>> parameter (udp/tcp/sctp) and/or different values of the
>>> URI scheme
>>>>> (sip/sips). Correct?
>>>>>
>>>>> John
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email protected] [mailto:[email protected]] On
>>>>> Behalf Of
>>>>>> BONNAERENS Ben
>>>>>> Sent: 05 August 2009 15:23
>>>>>> To: [email protected]
>>>>>> Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes
>>>>>>
>>>>>> Hi,
>>>>>> version -08 of record-route fix has just been submitted.
>>>>>>
>>>>>> Change log:
>>>>>> - Changed its status from BCP to PS,
>>>>>> - Take into account IESG reviews and subsequent
>> comments on the
>>>>>> mailing lists, they were summarized in Robert
>> Sparks's document
>>>>>> (rrf.txt), so it has been integrated in version -08
>> with minor
>>>>>> refactoring from the authors (me and Ben).
>>>>>>
>>>>>> The thoughest part was related to the SIP/SIPS question
>>> raised by
>>>>>> Cullen
>>>>> (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r
>>>>>> oute-fix/c
>>>>>> omment/98624/),
>>>>>> so here is the text that was added in version -08 to
>> answer this
>>>>>> question:
>>>>>> "Thus, if the transport protocol changed between its
>>>>>>   incoming and outgoing sides, the proxy SHOULD use
>> the double
>>>>>>   Record-Route technique and SHOULD add a transport
>>>>> parameter to each
>>>>>>   of the Record-Route URIs it inserts. With the exception
>>>>> that if TLS
>>>>>> is
>>>>>>   used as the transport protocol 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 leverage the [RFC3263]
>>>>> mechanisms
>>>>>> to
>>>>>>   indicate that TLS must be used rather 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."
>>>>>>
>>>>>> Brds,
>>>>>> Thomas & Ben
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> 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
>>>
>>
> _______________________________________________
> 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

_______________________________________________
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