Re: [Ltru] Registration Forms; have we made it clear which are archived

["Doug Ewell" <dewell at roadrunner.com>]

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> I think this quote from an email I sent to CEW isn't clear. The 
> question was whether ISO 639/3166/15924 actions result in registration 
> forms that are archived. It is my opinion, expressed in the quote 
> above and based on text in RFC 4646 (and still preserved in our I-D) 
> that the proper process has these features:
>
> - submission, typically by the LSR, of a registration form for 
> insertion or update of subtags based on ISO actions to the 
> ietf-languages list. This form later forms the submission to IANA 
> registering the change
>
> - that from IANA's point of view there is no difference between an 
> ISO-instigated change and any other type of change to the registry; 
> thus the registration forms must be archived for non-RFC-based 
> registrations

RFC 4646, section 3.3 says that for changes to the Registry prompted by 
changes to ISO standard code lists, the Reviewer sends "the information" 
to IANA in the form of an e-mail.  The description of this is rather 
detailed, down to the wording of subject lines, but it does not say 
anything about sending IANA a "registration form" in the sense we are 
talking about.  Figure 4, shown within Section 3.3, shows what we --  
Michael as Reviewer in charge of linguistic judgment, and I as Reviewer 
in charge of clerical details -- have been sending IANA for the past two 
years since RFC 4646 was approved:

   LANGUAGE SUBTAG MODIFICATION
   File-Date: 2005-01-02
   %%
   Type: variant
   Subtag: nedis
   Description: Natisone dialect
   Description: Nadiza dialect
   Added: 2003-10-09
   Prefix: sl
   Comments: This is a comment shown
     as an example.
   %%

The form we are discussing in this thread isn't even described until 
Section 3.5, and there it is described as follows:

"Only subtags of type 'language' and 'variant' will be considered for 
independent registration of new subtags.  Handling of subtags needed for 
stability and subtags necessary to keep the registry synchronized with 
ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits defined by 
this document are described in Section 3.3."

Note the contrast between the processes for ISO-instigated changes and 
for individual requests.  We have *never* generated boilerplate 
registration forms, with name and e-mail address of requester and 
bibliographical references, for ISO-instigated changes in the past.

The reason for this was simple.  Requests by individuals for new 
language or variant subtags, or for addition of Suppress-Script or 
Description or Comments fields, need to be evaluated by the Reviewer 
(assisted by ietf-languages participants) for suitability and 
correctness.  This is why we have an Expert Reviewer, and this is why 
the bibliographic references and such are necessary and valuable.

For changes triggered by ISO code lists, the only decisions to be made 
are whether the code element conflicts with something already in the 
Registry, or violates some other syntactical rule.  This doesn't require 
a linguistic expert; in fact, his judgment in such cases is irrelevant. 
If ISO 639-2 adds Pig Latin, we have to add it to the Registry.  There 
is nothing in the individual registration form that adds value to this 
process.

I see from draft-4646bis-12, section 3.3 that this is being changed, so 
that Michael and I will have to generate registration forms for 
ISO-based changes, and IANA will have to archive them along with the 
individually requested ones.  This strikes me as pointless busy work for 
Michael and me, but I won't fight to the death over it, since ding so 
seems to have little or no effect of late.  I probably should have 
noticed this change sooner.

I've cc'd Michael on this, so he is aware of the extra work we have in 
store.  Recall that ISO-based changes often come several at a time.

> - "registrations" committed by RFC 4645 or draft-4645bis are a special 
> case for which no forms are created or archived. This is covered in 
> all four relevant RFCs/I-Ds: 4645 4646 4645bis and 4646bis.

I certainly agree with this.

> I don't think any changes to the I-D are being proposed here; I don't 
> think any changes are warranted; and I think that the existing process 
> (as described, but not always practiced very rigorously) is a Good 
> Thing.

The text in draft-4646bis-12 regarding ISO-based changes does not 
reflect the existing process.  The existing process is spelled out in 
RFC 4646, as quoted above.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ


_______________________________________________
Ltru mailing list
Ltru at ietf.org
http://www.ietf.org/mailman/listinfo/ltru