-----Original Message-----
From: BONNAERENS Ben [mailto:ben.bonnaerens at alcatel-lucent.be]
Sent: 11 August 2009 12:44
To: Elwell, John
Cc: sip at ietf.org; 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
Behalf Of Elwell, John
Sent: dinsdag 11 augustus 2009 10:44
To: BONNAERENS Ben; sip at ietf.org
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:ben.bonnaerens at alcatel-lucent.be]
Sent: 07 August 2009 14:57
To: Elwell, John; sip at ietf.org
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:john.elwell at siemens-enterprise.com]
Sent: donderdag 6 augustus 2009 9:37
To: BONNAERENS Ben; sip at ietf.org
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
Behalf Of
BONNAERENS Ben
Sent: 05 August 2009 15:23
To: sip at ietf.org
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
sip-implementors at cs.columbia.edu for questions on
current sip Use
sipping at ietf.org 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
sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip