Subject: [Iptel] [Fwd: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt]

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 09 Apr 2004 12:53:15 -0400

Folks,

You may have noticed that the IANA registry has been removed from -06.

Generally speaking, the purpose of IANA registries is to avoid conflicts 
that may arise if two different groups/users select the same name for a 
parameter. This is clearly an issue for things like BGP AS numbers, 
which are actually allocated by IANA. For parameters in protocol 
specifications, problems only arise when different specifications 
accidentally use the same name. This is less likely to happen, and its 
likelihood depends on how much extensibility is expeted for the 
protocol. For SIP headers, we deemed it useful because of the large 
number of extensions that were anticipated. However, I do not expect a 
lot of extensions to the tel URI, and thus the IANA registry doesnt add 
a lot of value. Indeed, it is likely to slow up publication of 2806bis 
and add additional load on an already-busy IANA.

Thus, I think it makes sense to drop the iana registry.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

Subject: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Thu, 08 Apr 2004 16:20:16 -0400
List-Id: <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: The tel URI for Telephone Calls
	Author(s)	: H. Schulzrinne
	Filename	: draft-ietf-iptel-rfc2806bis-06.txt
	Pages		: 18
	Date		: 2004-4-8
	
This document specifies the URI (Uniform Resource Identifier) scheme
'tel'. The 'tel' URI describes resources identified by telephone
numbers

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-rfc2806bis-06.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-iptel-rfc2806bis-06.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-iptel-rfc2806bis-06.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.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 12 Apr 2004 17:08:07 -0400

> Thus, I think it makes sense to drop the iana registry.

I've heard this argument a couple of times lately, and I find it hard to accept.
Whenever you have an extensible name space, there is a risk for collissions in that
name space. An IANA registry is the way to avoid those collissions (not to mention that
it provides a convenient way for people to find out what extensions are defined).
Relying on some set of people to "just know" what extensions are already defined is
neither good engineering practice, nor likely to work well in the long run IMO, and
hence I'd much rather that we keep it. Dropping IANA registries as a way of speeding up
things seems like fixing the sympton rather than the problem.

-- Flemming

>   ------------------------------------------------------------------------
>
> CC: [email-masked]
>   ------------------------------------------------------------------------

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 13 Apr 2004 00:48:41 +0100

Hi Flemming, folks,
   I fully agree with Jonathon. Please let's avoid an IANA time trap.

I also sympathise with Flemming - this is fixing the symptom, not the  
problem.
However... we know there's a problem; we know that the problem needs to  
be fixed.
We also live in the real world (i.e. we're Engineers :), and I can't be  
the only
one who believes that RFC2806bis is a major clarification - it's needed  
NOW.

Thus, let's get this thing "out the door", and *in parallel* fix the  
problem.

Do you really think that there will be a lot of parameter specification  
RFCs
that "update" RFC2806bis? If so, then a future task (once IANA has been  
taught
how to set up a registry in less than several years) could be to pull  
in all
the updates and refresh with an IANA considerations section - but,  
please,
don't hold this one hostage (and any that depend on it), unless that's  
the intent.

all the best from an impatient
  Lawrence

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 13 Apr 2004 16:09:46 -0400

Jonathan Rosenberg wrote:

> Thus, unless you or someone else really strongly objects, I'd lack to
> pass -07 to IESG so we can declare this one done.
>

I'm not going to object, but I think we are setting a poor precedent here. Can we perhaps get
an area on the softarmor site where we can list these (unofficially of course) ?

-- Flemming

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 13 Apr 2004 16:01:16 -0400

Flemming Andreasen wrote:
> hence I'd much rather that we keep it. 

This is true in theory, but I'm not sure it will really be an issue 
here, for this spec, in practice. I dont see lots of extensions, and I 
don't see lack of communications amongst authors on extensions. After 
all, the extensions are documented in RFCs - years later someone can 
still find the tel URI extensions and then make sure to define their 
extension to use a different name. Thus, the registry is primarily a 
convenience, and given the latency it will add, it doesnt seem worth it. 
Further, as Lawrence points out, it can easily be added later.

Thanks,
Jonathan R.