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

["Conroy, Lawrence (SMTP)" <[e-mail]>]

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

On 12 Apr 2004, at 10:08 pm, Flemming Andreasen wrote:

>
>
> Jonathan Rosenberg wrote:
>
>> 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.
>>
>
> 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
>
>>
>> Thanks,
>> Jonathan R.
>> --
>> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>> Chief Technology Officer                    Parsippany, NJ 07054-2711
>> dynamicsoft
>> [e-mail]                     FAX:   [phone]
>> http://www.jdrosen.net                      PHONE: [phone]
>> http://www.dynamicsoft.com
>>
>>    
>> ---------------------------------------------------------------------- 
>> --
>>
>> Subject: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt
>> Date: Thu, 08 Apr 2004 16:20:16 -0400
>> From: [e-mail]
>> To: [e-mail]
>> CC: [e-mail]
>>
>> 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
>> [e-mail] 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:
>>         [e-mail].
>> 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.
>>
>>    
>> ---------------------------------------------------------------------- 
>> --
>
>
> _______________________________________________
> Iptel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iptel
>

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