Message-Id: <6.1.2.0.2.20050408232618.02e9b5a0@mail.jefsey.com>
Date: Fri, 08 Apr 2005 23:32:45 +0200
To: "Addison Phillips" <addison.phillips@quest.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] Format for extension registry
In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEF0348@irvmbxw01.quest.c
 om>
References: <634978A7DF025A40BFEF33EB191E13BC0AEF0348@irvmbxw01.quest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ltru@ietf.org
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Addison,
everything you propose in term of your format is fine. You know what you want.

Just stop claiming your solution is universal in wanting your document to 
become the BCP 047. Explain how your format will be used by applications, 
to understand the load on the IANA.

We will stop being harassed by your proposition and develop our own system 
quietly for what your proposition does not address and we work on... There 
is room for everyone and for innovation.

jfc

On 22:36 08/04/2005, Addison Phillips said:
>content-class: urn:content-classes:message
>Content-Type: text/plain;
>         charset="utf-8"
>
>It was pointed out that there is no definition of the extensions registry. 
>Currently the draft says:
>
><t>IANA will maintain a registry of allocated single-letter subtags.
>     This registry contains the following information:
>     letter identifier; name; purpose; RFC defining the subtag namespace and
>     its use;
>     and the name, URL, and email address of the maintaining authority.</t>
>
>I would like to modify this to say:
>
><t>IANA will maintain a registry of allocated single-letter (singleton) 
>subtags. This registry will use the record-jar format described in Section 
>3.1, using the ABNF  (RFC2234bis) in that section. Upon publication of an 
>extension as an RFC, the maintaining authority defined in the RFC must 
>forward to iana@iana.org the registration form defined in this section and 
>required in the extension's RFC for inclusion into the registry. </t>
>
>We would then define the records as follows:
>
>%%
>Identifier: (letter identifying the extension)
>Description: (name and purpose of the extension)
>Comments: (comments)
>Added: (date in ISO 8601 full-date format when this record added)
>RFC: (RFC defining the extension)
>Authority: (name of the maintaining authority)
>Email: (email of the maintaining authority)
>URL: (URL of the extension)
>%%
>
>
>Comments/suggestions?
>
>Addison
>
>Addison P. Phillips
>Globalization Architect, Quest Software
>http://www.quest.com
>
>Chair, W3C Internationalization Core Working Group
>http://www.w3.org/International
>
>Internationalization is not a feature.
>It is an architecture.
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru