Subject: [Sip] draft-ietf-sip-sips-03.txt

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 Apr 2007 17:26:50 -0500

Hi all,

I have submitted draft-ietf-sip-sips-03.
 
I have integrated all the agreements of the Prague meeting. Including
the change to Standards Track draft, and the RFC 2119 wording changes,
as well as the restructure of the document with Normative requirements
for UA and Proxy separated. Also the deprecation of the last hop
exception.

I also have attempted to capture the suggestions for improvements
and consensus from the mailing list.

There are two remaining issues that I have documented in Annex C.

Those 2 issues are what we need to focus on:

  1.  Do we deprecate the "last hop retarget upgrade exception"?  The
       document currently assumes that it IS deprecated, as this is the
       preference of the author.

  2.  Do we need the sips option tag? The current document assumes that
       we do use the option tag, and that is the preference of the
author.
       (There is at least one dissenting voice on that one: Hisham).

Please comment on those two open issues, and use a proper Subject for
the
topic.

If you have other comments, please use appropriate Subject fields to
make
the thread easier to follow.

Please also not repeat topics that have been beaten to death already.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, April 16, 2007 12:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-03.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol 
> Working Group of the IETF.
> 
> 	Title		: The use of the SIPS URI Scheme in the 
> Session Initiation Protocol (SIP)
> 	Author(s)	: F. Audet
> 	Filename	: draft-ietf-sip-sips-03.txt
> 	Pages		: 54
> 	Date		: 2007-4-16
> 	
> This document provides clarifications and guidelines concerning the
>    use of SIPS URI scheme in the Session Initiation Protocol 
> (SIP).  It
>    also makes normative changes to SIP.  This document also provides a
>    discussion of possible future steps in specification.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> "get draft-ietf-sip-sips-03.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-sip-sips-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 17 Apr 2007 16:25:34 -0500

>Please also not repeat topics that have been beaten to death already.

Though I have not seen any ENGINEERING reason coming so far on this. I
welcome any light coming even with heat too to enable me cross the
HURDLES. IMHO, SIPS has been beaten to death couple of times. 

I have read very closely couple of times the meeting minutes sent by
Dean. It nowhere mentions that it will be adopted as STANDARDS track
document. It might be decision in the Prague, but afterwards on the
list, I have not seen any UNANIMITY on the list to pursue this as
standard track document. 

Dean himself mentioned that SIPS is LARGELY broken, but we owe the
explaination to the community which is using it. So I have still my
objection to proceed it as STANDARDS track, where chairs also seem to be
aligned. Please correct me, if my interpretation is incorrect.

Thx
Samir

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 20:20:57 -0700

>        (There is at least one dissenting voice on that one: Hisham).

I'm confused on why we would need it and would want to understand why  
it is needed before commenting on this. I don't buy the needing it to  
enforce deprecate of last hop rule - I see problem in that it leads  
to two bits that mean the same thing and we have to deal with all the  
corner cases of when they conflict. It also makes me wonder if there  
are problems when a URI is copied from one situation to another and  
the REquires: sips header is not.

Cullen <with my individual hat on>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 Apr 2007 15:16:15 -0500

(Copying Dean and Jon and Hisham, because they are the main people who
expressed 
an opinion on this).

The issue is how do we handle backward-compatibility, i.e.,
implementations that
have implemented sips according to RFC 3261 but not to this draft.

Because of the many issues highlighted in the draft, those
implementations are
likely to do proprietary "cheats" to handle SIPS, and they are also
likely to 
have things that are not really legal. Presumably, the option-tag would
allow UAs and Proxies to know if an implementation is "clean" or not.
You could then
provide alternative treatment for the "un-clean" implementation (i.e.,
don't allow
registration, protocol fix-up, manufacturer-specific stuff, record an
aler, etc.). 
There are certainly other ways of doing this, and this is largely
theoretical 
anyways because it's not like there is a large numbers of
implementations out there.

The second issue (perhaps more importantly) is the actual changes that
we 
are making to RFC 3261. Specifically, the various deprecation of last
hop ugrades/
downgrades.

The option-tag (with Proxy-required) allows for the sender of the
request to
enforce the deprecation of the last hop exception, i.e., the session
will fail
with 420 if a proxy doesn't understand that it is supposed to support
sips
properly as per the new draft. 

I was thinking about the originator of the request as the entity that
would want
to enforce no-last-hop-exception, but Cullent points out that maybe it's
also
something that's up to the owner of the SIPS URI to decide, in which
case the
option-tag is not useful (of course if you are that worried about it,
you
could do "sips:[email-masked]?Proxy-Required:sips".

So....

I actually don't really care either way. Really. I'm fine either way.

Maybe we should do a virtual "hum".

1a - For the option-tag (but I could go either way)
1b - For the option-tag (and I really insist on it)
2a - Against the option-tag (but I could go either way)
2b - Against the option-tag (and I really insist on it)
3 - I really don't care

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Sunday, April 22, 2007 20:21
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]
> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
> 
> 
> I'm confused on why we would need it and would want to 
> understand why it is needed before commenting on this. I 
> don't buy the needing it to enforce deprecate of last hop 
> rule - I see problem in that it leads to two bits that mean 
> the same thing and we have to deal with all the corner cases 
> of when they conflict. It also makes me wonder if there are 
> problems when a URI is copied from one situation to another 
> and the REquires: sips header is not.
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 Apr 2007 09:10:04 -0500

I don't think we need an option tag for this - we are not fundamentally 
changing or extending RFC 3261.  The intent of 3261 was that a sips call 
have encrypted signaling end-to-end, we are just clarifying how this 
should be done.

Also, since there are no deployments of sips, there is no backwards 
compatibility issue.

Thanks,
Alan

---

From: Dean Willis <[email-masked]>
Date: Wed, 25 Apr 2007 12:59:21 -0500

>  Also, since there are no deployments of sips, there is no backwards

Ok, here's a silly question for you.

Given, there are no big deployments of SIPS that we've heard of.

However, many of the implementations we've been made aware of
support SIPS, or can at least be configured to react differently to
SIPS requests (whether that implies supporting SIPS is debatable).

If we have a deployment of the "new and improved" SIPS, the traffic
it produces is likely to hit some of those old implementations that
we don't currently consider "deployed" for SIPS.

What happens? Do things break? Or are we confident that those
older implementations of SIPS are all configured "off"?

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Apr 2007 13:58:17 -0500

It's a good question.

You are asking what happens if SIPS is used but somehow terminate on an
interface that
does not support SIPS.

In the best case, it will reject it properly because it will inspects
the scheme,
does't recognize it, and sends 416. That's ok.

Another case is where the last proxy used the last hop exception because
it
was not compliant to this RFC. That's the case where we say that there
is not
much real existing deployment of this. Presumably, that proxy is mucking
around
to make it work (changing contacts or whatever), as we discussed
earlier. This 
may be a theoretical problem more than a real one. I think we all agree
on that.

The case I think you are asking about is if the request goes to the UAS
but the
UAS somehow doesn't parse properly the scheme and accepts it. I think
this is fairly
likely actually. 

The question is do we need to solve this problem by adding an
option-tag? This is 
a problem of buggy implementation of RFC 3261. Or are we happy with the
originator 
of the request figuring it out and tearing down the session?

I'm now tempted to change opinion again and argue that it is not worth
it to try
to solve buggy RFC 3261 implementations with an option-tag (maybe
they'll be buggy
on the option-tag too). The UAC should be able to detect that (looking
at 
Contact and From for example) and clear the session.

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 10:59
> To: Alan Johnston
> Cc: Audet, Francois (SC100:3055); Cullen Jennings; Peterson, 
> Jon; [email-masked]; Keith Drage
> Subject: Interaction of SIPS with old implementations that 
> weren't really using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
> 
> Alan Johnston wrote:
> support SIPS, or can at least be configured to react 
> differently to SIPS requests (whether that implies supporting 
> SIPS is debatable).
> 
> If we have a deployment of the "new and improved" SIPS, the 
> traffic it produces is likely to hit some of those old 
> implementations that we don't currently consider "deployed" for SIPS.
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 25 Apr 2007 14:43:56 -0500

>
>I'm now tempted to change opinion again and argue that it is 
>not worth it to try to solve buggy RFC 3261 implementations 
>with an option-tag (maybe they'll be buggy on the option-tag 
>too). The UAC should be able to detect that (looking at 

That's right path of thinking. Could you please clarify how Contact and
>From can fix that. Also as far as I understand option tags are for
extending the new functionality. And not for fixing the broken
protocols. Purists ?

Thx
Samir

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 25 Apr 2007 12:59:17 -0700

Agree with Alan .... If this document was extending SIP then I would  
understand the need for an option tag but the draft would not need to  
update 3261.

On Apr 25, 2007, at 7:10 AM, Alan Johnston wrote:

> I don't think we need an option tag for this - we are not  
> fundamentally changing or extending RFC 3261.  The intent of 3261  
> was that a sips call have encrypted signaling end-to-end, we are  
> just clarifying how this should be done.
>
>> expressed an opinion on this).
>>
>> likely to have things that are not really legal. Presumably, the  
>> option-tag would
>> aler, etc.). There are certainly other ways of doing this, and  
>> this is largely
>> theoretical anyways because it's not like there is a large numbers of
>> we are making to RFC 3261. Specifically, the various deprecation  
>> of last
>> hop ugrades/
>> downgrades.
>>
>>> From: Cullen Jennings [mailto:[email-masked]] Sent: Sunday,  
>>> April 22, 2007 20:21
>>>>        we do use the option tag, and that is the preference of  
>>>> the author.
>>> I'm confused on why we would need it and would want to understand  
>>> why it is needed before commenting on this. I don't buy the  
>>> needing it to enforce deprecate of last hop rule - I see problem  
>>> in that it leads to two bits that mean the same thing and we have  
>>> to deal with all the corner cases of when they conflict. It also  
>>> makes me wonder if there are problems when a URI is copied from  
>>> one situation to another and the REquires: sips header is not.
>>>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Apr 2007 16:27:55 -0500

On your first question: If I send you a request using a SIPS URI, and
you 
accept it even if you don't support SIPS (because you are a buggy
implemenation),
you will nevertheless put SIP in the various URIs in your response,
e.g., in the
Contact header. You may even muck-up the From or To. If you send me
mid-call 
requests later, you will most probably use SIP URIs in From. If I detect
something 
like that, I can probably figure out something is wrong. Some of this is
already 
covered in the draft and in RFC 3261. 

On your second question. It's not the protocol that is broken but the 
implementation.   

> From: Srivastava, Samir (SC100:8826) 
> Sent: Wednesday, April 25, 2007 12:44
> To: Audet, Francois (SC100:3055); Dean Willis; Alan Johnston
> Cc: Cullen Jennings; [email-masked]; Keith Drage; Peterson, Jon
> Subject: RE: Interaction of SIPS with old implementations 
> that weren't really using SIPS (was Re: [Sip] 
> draft-ietf-sip-sips-03.txt)
> 
>  
> 
> >
> not worth 
> >it to try to solve buggy RFC 3261 implementations with an option-tag 
> >(maybe they'll be buggy on the option-tag too). The UAC 
> should be able 
> >to detect that (looking at Contact and From for example) and 
> clear the 
> >session.
> 
> That's right path of thinking. Could you please clarify how 
> Contact and From can fix that. Also as far as I understand 
> option tags are for extending the new functionality. And not 
> for fixing the broken protocols. Purists ?
>  
> 
> Thx
> Samir
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 25 Apr 2007 16:49:10 -0500

> You are asking what happens if SIPS is used but somehow terminate  

Actually, I'm asking what happens when such a request lands on  
something that THINKS it supports SIPS:, but doesn't really because  
what it supports is some part (and unlikely to be correct) of what  
SIPS was before we fixed it.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Apr 2007 17:08:51 -0500

Hi All,

I looks like we are about ready to close on the 2 remaining opened
issues in 
Appendix C of draft-ietf-sip-sips-03.

   1.  Do we deprecate the "last hop retarget upgrade exception"?  

	It appears that we DO have a concensus that we do deprecate the
last
	hop retarget upgrade exception, as the remaining concerns have
been
	addressed to the satisfaction of the person who expressed the
concern.

   2.  Do we need the sips option tag?

	My reading of the group is that we have a rough consensus on NOT
to 
	use an option tag. 

Please let me know if there are strong objections on either topics, and
if
not, I will close off the two issues and issue a version -04.

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 25 Apr 2007 17:25:01 -0500

>
>On your first question: If I send you a request using a SIPS 
>URI, and you accept it even if you don't support SIPS (because 
>you are a buggy implemenation), you will nevertheless put SIP 
>in the various URIs in your response, e.g., in the Contact 
>header. You may even muck-up the From or To. If you send me 
>mid-call requests later, you will most probably use SIP URIs 
>in From. If I detect something like that, I can probably 
>figure out something is wrong. Some of this is already covered 
>in the draft and in RFC 3261. 

If it just doesn't support SIPS, It should just return "416 Unsupported
URI scheme".
Very pointed question, why do we want to develop standards for the BUGGY
implementation. At the _most_, we can just say in BCP/INFORMATIONAL
document that if it behaves like this, then it is buggy implementation.
And we don't attempt to fix it in the specification. If we take this
route, we might find numerous others BUGGY implementations of other
parts of SIP specifications also. I just call them BUGS. And bugs are
fixed by their owners during the upgrades/patches etc.
>On your second question. It's not the protocol that is broken but the 
We should not even attempt to fix the broken implementation via another
add-on standards. I don't want to say now as Dean yesterday said season
is over for hunting. Keep trying to fix it. Good luck.

Thx
Samir

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Apr 2007 17:32:48 -0500

I should have known better not to waste my time answering your
questions when you obviously don't care about the answers. 

I won't make that mistake again. 

> Sent: Wednesday, April 25, 2007 15:25
> Cc: [email-masked]'
> URI, and 
> >you accept it even if you don't support SIPS (because you 
> are a buggy 
> >implemenation), you will nevertheless put SIP in the various URIs in 
> >your response, e.g., in the Contact header. You may even muck-up the 
> >From or To. If you send me mid-call requests later, you will most 
> >probably use SIP URIs in From. If I detect something like 
> that, I can 
> >probably figure out something is wrong. Some of this is 
> already covered 
> If it just doesn't support SIPS, It should just return "416 
> Unsupported URI scheme".
> Very pointed question, why do we want to develop standards 
> for the BUGGY implementation. At the _most_, we can just say 
> in BCP/INFORMATIONAL document that if it behaves like this, 
> then it is buggy implementation. And we don't attempt to fix 
> it in the specification. If we take this route, we might find 
> numerous others BUGGY implementations of other parts of SIP 
> specifications also. I just call them BUGS. And bugs are 
> We should not even attempt to fix the broken implementation 
> via another add-on standards. I don't want to say now as Dean 
> yesterday said season is over for hunting. Keep trying to fix 
> it. Good luck.
> 
> Thx
> Samir
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 Apr 2007 00:37:25 -0400

The critical issue here is the backwards compatibility question. If we accept that SIPS as written in RFC3261 (that is, with the last hop exception) is not and will never be implemented, then I suppose an option-tag is redundant. If not, though, then as a UAC sending a request, I would certainly want a proxy server to fail a SIPS request if it didn't understand that the last hop exception could not be invoked. 

As such, in that case I'd see value for the option tag in Proxy-Require. The use of the option-tag in Proxy-Require would of course be at the discretion of the UAC sending a request. But of course, it is always the UAC that is requesting and invoking the protection of SIPS, so that seems like a natural fit.

Jon Peterson
NeuStar, Inc.

> Sent: Wednesday, April 25, 2007 12:59 PM
> To: Alan Johnston
> Cc: Francois Audet; Peterson, Jon; [email-masked]; Dean Willis; Keith
> Drage
> >> (Copying Dean and Jon and Hisham, because they are the 
> main people  
> >> who
> understand

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 08:59:48 +0300

Francois Audet writes:

 > issues in  Appendix C of draft-ietf-sip-sips-03.

how about the r-r tls transport issue that was raised a couple of days
ago?  someone said that according to your i-d, my proxy that uses tls
with then next proxy, has to upgrade sip: to sips: over that link.  

if that is true, your draft is badly broken, because my proxy cannot
have any knowledge that sips: is supported on the following hops.  if
that is not true, tell me what kind of r-r(s) my proxy needs to in that
case insert.

-- juha

---

From: Thomas Froment <[email-masked]>
Date: Thu, 26 Apr 2007 09:55:20 +0200

> that is not true, tell me what kind of r-r(s) my proxy needs to in that
Yes, actually, on my side, I did not answer your last remark because I 
think this is NOT related to "double RR" versus "R-R rewriting" question.
You can choose to either double R-R or rewrite, but the question you are 
raising is: are you allowed to continue to use "transport=TLS" or not,
this more a question related to sip/sips clarification: currently this 
is clearly stated in sip/sips that TLS transport parameter should not be 
used...

Thomas

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 11:02:20 +0300

> is clearly stated in sip/sips that TLS transport parameter should not be 

thomas,

yes, i understood that this is not a your problem.  that is why i now
posted the question explicitly to author of sips i-d.  if sips i-d tells
in the case of my example to upgrade sip: to sips: there is a BIG bug in
it.  

for some reason this issue was missing from the issues list that the
author of sips i-d just posted.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 11:00:58 -0500

Yeah, sorry, I missed that thread.

The current draft basically says that it is NOT legal for a proxy
to "upgrade" or "downgrade" from sip to sips or vice versa. It MUST
keep the same scheme.

So, it is "not true" and therefore not badly broken. In fact, that's
the whole point of making that change in the draft: fixing sips so it is
not broken.

The Double Record-Route procedures are nevertheless described in the
draft because people wanted to see "what would happen with theoretical
legacy 3261 implementations that supported sips as per 3261, but not
according to the new draft". 

So: to summarize, with the current draft, the double record-route
procedures
are never used.

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 23:00
> Cc: [email-masked]; Alan Johnston; Keith Drage; Peterson, Jon; 
> Dean Willis
> Subject: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
> 
> Francois Audet writes:
> 
>  > I looks like we are about ready to close on the 2 
> remaining opened  > issues in  Appendix C of draft-ietf-sip-sips-03.
> 
> how about the r-r tls transport issue that was raised a 
> couple of days ago?  someone said that according to your i-d, 
> my proxy that uses tls with then next proxy, has to upgrade 
> sip: to sips: over that link.  
> 
> if that is true, your draft is badly broken, because my proxy 
> cannot have any knowledge that sips: is supported on the 
> following hops.  if that is not true, tell me what kind of 
> r-r(s) my proxy needs to in that case insert.
> 
> -- juha
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 11:03:23 -0500

Yes, transport=tls has been deprecated since RFC 3261. Correct.

draft-ietf-sip-sips-03 simply makes it clearer. It is very true
that the deprecation in RFC 3261 has been missed by many people. 

> From: Thomas Froment [mailto:[email-masked]] 
> Sent: Thursday, April 26, 2007 00:55
> To: Juha Heinanen
> Cc: Audet, Francois (SC100:3055); [email-masked]; Keith Drage; 
> Alan Johnston; Peterson, Jon; Dean Willis
> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of 
> Opened issues
> 
> Juha Heinanen wrote:
> > Francois Audet writes:
> >
> remaining opened  
> couple of days 
> > that is not true, tell me what kind of r-r(s) my proxy needs to in 
> > that case insert.
> >   
> Yes, actually, on my side, I did not answer your last remark 
> because I think this is NOT related to "double RR" versus 
> "R-R rewriting" question.
> You can choose to either double R-R or rewrite, but the 
> question you are raising is: are you allowed to continue to 
> use "transport=TLS" or not, this more a question related to 
> sip/sips clarification: currently this is clearly stated in 
> sip/sips that TLS transport parameter should not be used...
> 
> Thomas
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 19:06:48 +0300

Francois Audet writes:

 > procedures are never used.

thanks for the your interpretation that differs from what i read earlier
on this list.  

in order to make this perfectly clear to proxy implementers, can
someone, please, tell exactly what the proxy should so in terms of r-r
headers and r-uri when request with sip: uri scheme comes in over udp
and goes out over tls.

-- juha

---

From: Thomas Froment <[email-masked]>
Date: Thu, 26 Apr 2007 18:42:37 +0200

> headers and r-uri when request with sip: uri scheme comes in over udp

I think this is exactly in the scope of rr-fix draft to clarify this point.
Just to summarize how it *should* work from the beginning;
1) if your are not sure on what transport is supported by next elements, 
you do not put any transport in your RR header, as specified in sentence 
of item 4 of section 16.6, "The URI SHOULD NOT contain the transport 
parameter unless the proxy has knowledge(such as in a private network) 
that the next downstream element that will be in the path of subsequent 
requests supports that transport")

2) It is assumed the proxy will put a a logical name in Record-Route, 
and then, according to RFC 3263 procedures, any SIP element that
will try to reach your proxy should find an appropriate transport 
following these procedures (section 4.1,
basically:

If the URI specifies a transport protocol in the transport parameter,
   that transport protocol SHOULD be used.

   Otherwise, if no transport protocol is specified, but the TARGET is a
   numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
   for a SIPS URI.  Similarly, if no transport protocol is specified,
   and the TARGET is not numeric, but an explicit port is provided, the
   client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI.  This is
   because UDP is the only mandatory transport in RFC 2543 [6], and thus
   the only one guaranteed to be interoperable for a SIP URI.  It was
   also specified as the default transport in RFC 2543 when no transport
   was present in the SIP URI.  However, another transport, such as TCP,
   MAY be used if the guidelines of SIP mandate it for this particular
   request.  That is the case, for example, for requests that exceed the
   path MTU.

   Otherwise, if no transport protocol or port is specified, and the
   target is not a numeric IP address, the client SHOULD perform a NAPTR
   query for the domain in the URI.

3) So, in your case, if your proxy switch from UDP to TLS, it means the NAPTR records of your proxy should answer with higher priority "TLS" for request coming from your "callee side",
and UDP for requests coming from your "caller side"...

--> Multiple questions need clarifications here, because people want to be able to switch from one transport to another, use numeric ip addresses, and still
make the RR work. So, that's why I explained a typical "workaround"  is to put a transport parameter on the RR. (if the proxy decides to
make RR rewriting, it will put just one RR with the transport used to reach the next element, and when seeing the 200 OK response, change that transport
to the transport used with the previous element.
It explains you why I said that the "Route set seen by the callee will be different than the Route Set seen by the callee" when rewriting.
Double Record-Routing does not solve that problem at all, this is still a topic to be discussed, and I am open to any suggestion about this issue.

Thomas

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 11:52:05 -0500

Then, only the VIA headers are affected. No impact whatsoever on
Record-Route and 
Request-URI as it is still sip: to sip: 

You should really NOT use the transport parameter in RR or Request-URI.

But you are right, I probably need to make it more explicit in the text.

> Sent: Thursday, April 26, 2007 09:07
> Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of 
> Opened issues
> 
> Francois Audet writes:
> 
>  > So: to summarize, with the current draft, the double 
> record-route  > procedures are never used.
> 
> thanks for the your interpretation that differs from what i 
> read earlier on this list.  
> 
> in order to make this perfectly clear to proxy implementers, 
> can someone, please, tell exactly what the proxy should so in 
> terms of r-r headers and r-uri when request with sip: uri 
> scheme comes in over udp and goes out over tls.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 20:08:24 +0300

Francois Audet writes:

 > Record-Route and Request-URI as it is still sip: to sip: 

and according to rfc 3261 20.42 via will contain SIP/2.0/TLS, right?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 20:12:35 +0300

Thomas Froment writes:

 > --> Multiple questions need clarifications here, because people want
 > to be able to switch from one transport to another, use numeric ip
 > addresses, and still make the RR work. So, that's why I explained a
 > typical "workaround"  is to put a transport parameter on the RR. (if
 > the proxy decides to make RR rewriting, it will put just one RR with
 > the transport used to reach the next element, and when seeing the 200
 > OK response, change that transport to the transport used with the
 > previous element.
 > It explains you why I said that the "Route set seen by the callee
 > will be different than the Route Set seen by the callee" when
 > rewriting.
 > Double Record-Routing does not solve that problem at all, this is
 > still a topic to be discussed, and I am open to any suggestion about
 > this issue.

thanks for the explanation.  today at least openser (which is a VERY
popular sip proxy), does double rr if transport protocol changes, for
example:

Record-Route:<sip:192.98.101.10;transport=TCP;r2=on>,<sip:192.98.101.10;r2=on>

is also uses transport=tls no matter if it is deprecated or not.

but isn't this a local matter within a proxy, i.e., why should anybody
else care?

-- juha

---

From: Thomas Froment <[email-masked]>
Date: Thu, 26 Apr 2007 19:25:16 +0200

> but isn't this a local matter within a proxy, i.e., why should anybody
RR is for sure the matter of SIP proxies, and the question you asked on 
UDP to TLS case is a question that many implementors had one day or another.
Sometimes it raises interoperability problems by making UAs change their 
transport betwen initial and subsequent requests, generally asking the 
proxy implementor: "why the hell you don't put any transport on your 
record route since I contacted you using TCP?"...
So, if the BCP is useful for SIP proxy developers, this is still 
something...
Moreover, it happens that implementations choose bad work-arounds to 
bypass it, for instance by keeping the same transport for the whole 
duration of a dialog (in UAs), whatever the route or RFC3263 says...
Finally, I would like to go back to my initial poll who did not get any 
answer:
who would like to deprecate RR rewriting?
who want to keep it?
who care? ;-)

Regards,
Thomas

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Apr 2007 12:33:02 -0500

> who would like to deprecate RR rewriting?

RR rewriting makes my head hurt, and I always mess up examples that  
use it.

Therefore, I'm in favor of not using it.

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Apr 2007 12:33:28 -0500

Thomas -

Sorry for not directly answering this question earlier.

My position is to not deprecate rewriting.

I do think rewriting is overall a bad idea and that double-RR is a  
much saner approach, and your document does a good job of explaining  
why.
But there are simple environments where rewriting is working in the  
field. I don't see the benefit of making what they're currently doing  
a violation
of the protocol at the moment. Showing them better ways, seeing  
everyone implement them, and later deprecating the behavior seems the  
more
effective way to proceed.

That said, I don't feel strongly about this and I certainly won't  
fight to keep rewriting around.

RjS

On Apr 26, 2007, at 12:25 PM, Thomas Froment wrote:

> RR is for sure the matter of SIP proxies, and the question you  
> asked on UDP to TLS case is a question that many implementors had  
> one day or another.
> Sometimes it raises interoperability problems by making UAs change  
> their transport betwen initial and subsequent requests, generally  
> asking the proxy implementor: "why the hell you don't put any  
> transport on your record route since I contacted you using TCP?"...
> Moreover, it happens that implementations choose bad work-arounds  
> to bypass it, for instance by keeping the same transport for the  
> whole duration of a dialog (in UAs), whatever the route or RFC3263  
> says...
> Finally, I would like to go back to my initial poll who did not get  
> any answer:

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 20:43:05 +0300

> UDP to TLS case is a question that many implementors had one day or

i meant why would someone care if proxy does single or double rr,
because UAs only deal with the topmost one and have no way of knowing if
a proxy double rr'ed or not.  same for other proxies.

 > record route since I contacted you using TCP?"...

this is not related to double or single rr, but if transport parameter
is added or not.

 > So, if the BCP is useful for SIP proxy developers, this is still 

yes.

 > who would like to deprecate RR rewriting?

where is rr re-writing specified so that it could be deprecated?  

as i told double rr is widely used in real deployments and we haven't
noticed any major problems.  so if it is not really broken i don't see
any reason to fit it.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 20:46:27 +0300

> procedures are never used.

but as i mentioned in another message, they ARE currently heavily used.
i don't see a point in writing yet another ietf draft that has no
bearing to the real world.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 13:10:39 -0500

You CAN use Double record-route. It doesn't break anything.

This draft does not make any use of it.

I don't understand your poin

Please make concretre point as oppose to rethorical ones. 

> Sent: Thursday, April 26, 2007 10:46
> i don't see a point in writing yet another ietf draft that 
> has no bearing to the real world.
> 
> -- juha
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 13:11:14 -0500

Yes. 

> Sent: Thursday, April 26, 2007 10:08
> Cc: [email-masked]; Keith Drage; Alan Johnston; Peterson, Jon; 
> Dean Willis
>  > Then, only the VIA headers are affected. No impact 
> whatsoever on  > Record-Route and Request-URI as it is still 
> sip: to sip: 
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 13:12:58 -0500

It's ok to use it (the transport parameter and double record-route).

It just means that your are RESTRICTING how you can be reached (i.e.,
you are foccing a specific transport).

> Sent: Thursday, April 26, 2007 10:13
> To: Thomas Froment
> Cc: [email-masked]; Alan Johnston; Audet, Francois 
> (SC100:3055); Keith Drage; Peterson, Jon; Dean Willis
>  > --> Multiple questions need clarifications here, because 
> people want  > to be able to switch from one transport to 
> another, use numeric ip  > addresses, and still make the RR 
> work. So, that's why I explained a  > typical "workaround"  
> is to put a transport parameter on the RR. (if  > the proxy 
> decides to make RR rewriting, it will put just one RR with  > 
> the transport used to reach the next element, and when seeing 
> the 200  > OK response, change that transport to the 
> transport used with the  > previous element.
>  > It explains you why I said that the "Route set seen by the 
> callee  > will be different than the Route Set seen by the 
> callee" when  > rewriting.
>  > Double Record-Routing does not solve that problem at all, 
> this is  > still a topic to be discussed, and I am open to 
> any suggestion about  > this issue.
> 
> thanks for the explanation.  today at least openser (which is 
> a VERY popular sip proxy), does double rr if transport 
> protocol changes, for
> example:
> 
> but isn't this a local matter within a proxy, i.e., why 
> should anybody else care?
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 21:34:56 +0300

> This draft does not make any use of it.

ok, sorry, i misunderstood your reply.

by the way, why does your sips draft say that transport=tls is
deprecated when uri scheme is NOT sips?  please clean your draft of
EVERYTHING that is not strictly related to use of sips uri scheme.

in real life transport=tls is NOT deprecated.  also, in my opinion, if
tls can be used in via header, it should also be usable as transport
parameter value.

tell me, why is tls (instead of tcp) needed in via when uri scheme is
sips?  cannot tls/tcp be concluded if transport is tcp and uri scheme is
sips.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 13:38:02 -0500

It is RFC 3261 that deprecated transport=tls, not my draft.

The reason why my draft talks about it is that, as you mention, it
is clearly something that was missed in the industry, causing 
interoperability problems. 

> Sent: Thursday, April 26, 2007 11:35
> by the way, why does your sips draft say that transport=tls 
> is deprecated when uri scheme is NOT sips?  please clean your 
> draft of EVERYTHING that is not strictly related to use of 
> sips uri scheme.
> 
> in real life transport=tls is NOT deprecated.  also, in my 
> opinion, if tls can be used in via header, it should also be 
> usable as transport parameter value.
> 
> tell me, why is tls (instead of tcp) needed in via when uri 
> scheme is sips?  cannot tls/tcp be concluded if transport is 
> tcp and uri scheme is sips.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 21:44:07 +0300

> It is RFC 3261 that deprecated transport=tls, not my draft.

yes, but as i told, transport=tls is heavily used for good reasons and
if might make sense to deprecate the deprecation.  if you want to bring
the issue up in your draft, we can also make that change (since the
draft makes changed anyway).

 > interoperability problems. 

no, it was not missed by the industry.  industry is not that stupid.
transport=tls is used, because there is VALUE in using it.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 13:47:08 -0500

Actually, it offers no value. It just makes it more likely that it will
fail.

We've been through this already. You know that a UAC supports TLS by the
fact
that it used TLS to register. It's the "implicit indication". 

The draft however tells you how to be backward compatible with UAs that 
use transport=tls.

> Sent: Thursday, April 26, 2007 11:44
> yes, but as i told, transport=tls is heavily used for good 
> reasons and if might make sense to deprecate the deprecation. 
>  if you want to bring the issue up in your draft, we can also 
> make that change (since the draft makes changed anyway).
> 
>  > The reason why my draft talks about it is that, as you 
> mention, it  > is clearly something that was missed in the 
> industry, causing  > interoperability problems. 
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Apr 2007 21:53:57 +0300

Francois Audet writes:

 > fact that it used TLS to register. It's the "implicit indication".

my example dealt with proxy-to-proxy communication.

 > The draft however tells you how to be backward compatible with UAs that 

how about proxies?

you still have not answered my question why in your world is tls needed
in via header instead of just tcp.

-- juha

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 26 Apr 2007 13:58:18 -0500

Another wacky thread developing. Do we need more evidence ? It's better
to realize SIPS is dead-end.

It may be far fetched idea, Cost of Dealing with two URI (SIP/SIPS) for
printing on Business Cards, SIP Directories etc. etc...  for coming
generations to use it ... Where we can deal with single URI. Vendors who
have implemented, I request you to give up, and let us work on the clean
complete solution... 

This thread is just talking about TLS. What about DTLS ? SIPS is broken
with respect to secure protocol development. It is no future proof
there.  People who don't buy future proofing, looks to me they wrote the
software with Y2K bug.

Thx
Samir

PS: Sorry Dean, I cannot check my temptation on the hunting as dog is
barking again and again.

>Sent: Thursday, April 26, 2007 11:44 AM
>Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
>
>Francois Audet writes:
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Apr 2007 16:02:43 -0500

On Apr 26, 2007, at 12:43 PM, Juha Heinanen wrote:

>> asked on

If you're trying to invert a recorded route for use in a service- 
route, the lack of reversibility induced by rewriting breaks things.

So this is NOT just an in-the-proxy issue. Double recording is more  
likely to make things work.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Apr 2007 16:09:31 -0500

> tls can be used in via header, it should also be usable as transport

There's enough of a consensus that it's just going to be that way.  
I'm sorry you disagree. You may very well be perfectly correct, but  
after a whole lot of discussion, the working group decided to deprecate.

In this working group, transport=tls IS deprecated. Whether or not  
that affects real-life remains to be seen, but I'd bet that it  
eventually will.

> sips?  cannot tls/tcp be concluded if transport is tcp and uri  

I've always wondered about this one myself. What about TLS/SCTP and  
DTLS, which might serve as transports for SIPS?

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 16:28:49 -0500

> scheme is 
> > sips?  cannot tls/tcp be concluded if transport is tcp and 
> uri scheme 
> > is sips.
> 
> I've always wondered about this one myself. What about 
> TLS/SCTP and DTLS, which might serve as transports for SIPS?

VIA already supports SCTP, TLS-SCTP. And the draft provides the 
references to RFC 4168 that defines it.

DTLS is defined in
http://tools.ietf.org/wg/sip/draft-jennings-sip-dtls-03.txt.

On the question of "why we are using VIA in the first place?" instead or
replying to where the request came from, well, I don't know. It wasn't
me
who wrote RFC 3261. This is a widely known characteristic described
in RFC 3581.

It's completely out of scope of this draft.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 26 Apr 2007 16:48:18 -0500

> references to RFC 4168 that defines it.

We've had this conversation before.

That is all well and fine for Vias (responses), but what about
requests triggered by a R-URI?

> http://tools.ietf.org/wg/sip/draft-jennings-sip-dtls-03.txt.

dtls-03 says that a SIP URI to be sent over DTLS should
look like the following:

    sip:[email-masked];transport=dtls-udp

Two questions:
   1/ should it not be "sips" scheme here?
   2/ If we are endorsing "transport=dtls-udp" in a SIP URI, then
      saying that you should not put "transport=tls" in a SIP URI
      seems silly. (Note that I personally do not like how
      implementations have continued to use "transport=tls"
      despite rfc3261 deprecating this.  But questions will arise
      in the future that why are we allowing "transport=dtls-udp"
      and not "transport=tls"?)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 16:49:55 -0500

Yes, that draft is wrong and needs to be fixed. 

The correct behavior is 1/

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Thursday, April 26, 2007 14:48
> That is all well and fine for Vias (responses), but what 
> about requests triggered by a R-URI?
> 
> > DTLS is defined in
> dtls-03 says that a SIP URI to be sent over DTLS should look 
> like the following:
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 26 Apr 2007 17:07:25 -0500

Hi,

The refernece draft mentions in the section 4 that SIPS can be used with
DTLS.

Whereas 3261 has tied SIPS to SIP over TLS.

While 3261 mentions in section 4, page 10

"An example would be sips:[email-masked].  A call
   made to a SIPS URI guarantees that secure, encrypted transport
   (namely TLS) is used to carry all SIP messages from the caller to the
   domain of the callee"

"3261/ Section 19.1 SIP and SIPS Uniform Resource Indicators"  states

"A SIPS URI specifies that the resource be contacted securely.  This
   means, in particular, that TLS is to be used between the UAC and the
   domain that owns the URI."

So my objection was with reference to 3261, which your draft attempt to
clarify what SIPS means. The above text specifically states TLS only. So
it will be better to clarify the above. And give reference to the
mentioned draft.

Also on the related note on the defintion of transport parameter of the
referenced draft
   transport         =  "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
                        "DTLS-DCCP" / "DTLS-UDP"
                        / other-transport

Transport attempts to put DTLS-DCCP but there is no separate DCCP . And
a related question why cannot we have TLS-TCP instead of implicitly
meaning that. Is it just the backward compatibility to 3261.

I would rather have a parameter 

Secure-Protocol = TLS/DTLS/ etc 
Transport = TCP/UDP/DCCP/SCTP/ ...
Instead of clubbing them together and having all permutations .. Bad
modeling.

Now I have still my biggest burning question. If IPSEC tunnel exists
between two SIP addressable entities, we have encryption twice. What
kind of application will shape in future (I don't have idea), where they
might want to tunnel all traffic through a single IPSEC tunnel. Don't we
need some more secure awareness in the application protocol SIP.

Thx
Samir

>From: Audet, Francois (SC100:3055) 
>Sent: Thursday, April 26, 2007 2:29 PM
>To: Dean Willis; Juha Heinanen
>Cc: [email-masked]
>VIA already supports SCTP, TLS-SCTP. And the draft provides 
>the references to RFC 4168 that defines it.
>
>DTLS is defined in
>On the question of "why we are using VIA in the first place?" 
>instead or replying to where the request came from, well, I 
>don't know. It wasn't me who wrote RFC 3261. This is a widely 
>known characteristic described in RFC 3581.
>
>It's completly out of scope of this draft. 
>
>
>
>
>
>

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Apr 2007 09:18:03 +0300

> route, the lack of reversibility induced by rewriting breaks things.

where did rewriting come from?  i was just talking about a proxy double
r-r'ing a request and asked why would someone care.  there is no
rewriting in rfc3261 and there should not be in the future either.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Apr 2007 09:29:54 +0300

>       and not "transport=tls"?)

because that is what "we" (the god) decided.

-- juha

---

From: Robert Sparks <[email-masked]>
Date: Fri, 27 Apr 2007 09:33:43 -0500

Juha -

Rewriting, as the term is being used in this conversation, _is_  
specified in 3261.
See section 16.7 Item 8 on page 107 with details starting on page  
112. If you
mean something else by rewriting, please make it explicit.

RjS

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Apr 2007 17:50:34 +0300

Robert Sparks writes:

 > 112.

robert,

thanks for the pointer.  the text is quite confusing though, because in
the list point 8 is OPTIONAL and also the first paragraph on point 8
says that a proxy MAY choose to do some re-writing and then the next
paragraph says that a proxy MUST do rewriting and change uri scheme
depending on transport.

anyway, i still don't understand what does it matter to upstream or
downstream elements if proxy is adding more than one r-r header to the
request.

-- juha

---

From: Robert Sparks <[email-masked]>
Date: Fri, 27 Apr 2007 09:55:44 -0500

I agree fully that the text is confusing. That's why we've got such a  
rat's nest of threads around this. Thomas' draft is trying to make it  
better.

I also think you and dean (at least) have been talking past each  
other. There is no prohibition in 3261 against a proxy adding more than
one RR value. And there is definitely nothing from the vantage point  
of elements on either side that would break if it did so (assuming it
put appropriate values in of course).

RjS

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Apr 2007 18:02:04 +0300

> put appropriate values in of course).

fine, we can then put this discussion into rest (assuming that someone
does not try to in some later document to prohibit double r-r'ing).

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Apr 2007 10:36:52 -0500

Double record-routing is completely othogonal to the topic of sips.

Furthermore, Double record-routing IS the preferred mechanism to use
when you need to switch transport, URI schemes, IPv4/IPv6 mapping, etc.
Double R-R is good (TM), and preferable to rewriting as per 3261.

It's just that this spec does not use it for the purpose of mappping 
between sip to sips,  because it does not support mapping between
sip to sips.

> Sent: Friday, April 27, 2007 08:02
> To: Robert Sparks
> Cc: [email-masked]; Dean Willis
>  > I also think you and dean (at least) have been talking 
> past each  > other. There is no prohibition in 3261 against a 
> proxy adding more than  > one RR value. And there is 
> definitely nothing from the vantage point  > of elements on 
> either side that would break if it did so (assuming it  > put 
> appropriate values in of course).
> 
> fine, we can then put this discussion into rest (assuming 
> that someone does not try to in some later document to 
> prohibit double r-r'ing).
> 
> -- juha
> 
>

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Apr 2007 18:41:09 +0300

> between sip to sips,  because it does not support mapping between

that is good, since it is much better to use transport=tls.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Apr 2007 10:43:30 -0500

It doesn't do anything to use transport=tls. 

You can just pick tls and avoid the parameter.

Anyways, I'm not commenting anymore on this topic. 

> Sent: Friday, April 27, 2007 08:41
> Cc: Robert Sparks; [email-masked]; Dean Willis
>  > It's just that this spec does not use it for the purpose 
> of mappping  > between sip to sips,  because it does not 
> support mapping between  > sip to sips.
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 27 Apr 2007 12:12:25 -0500

On Apr 27, 2007, at 9:55 AM, Robert Sparks wrote:

> I agree fully that the text is confusing. That's why we've got such  
> a rat's nest of threads around this. Thomas' draft is trying to  
> make it better.
>
> one RR value. And there is definitely nothing from the vantage  
> point of elements on either side that would break if it did so  
> (assuming it

Right, I've been trying to say double recording is a better solution  
than rewriting, because rewriting is likely to break stuff, and we  
haven't found anything that breaks from double recording. That's the  
argument for deprecating (at least to a SHOULD level rather than  
prohibiting) rewriting.

I'm not suggesting we prohibit double recording.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 28 Apr 2007 15:09:50 -0700

Francois pointed out this draft was wrong to me a long time ago -  
Nagendra and I agree with him. We just had not got around to fixing it.

---

From: "Xavier Marjou" <[email-masked]>
Date: Mon, 30 Apr 2007 08:56:50 +0200

> Therefore, I'm in favor of not using it.
I agree we should deprecate it.

Xavier