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

From: "Doug Ewell" <[email-masked]>
Date: Sat, 23 Feb 2008 13:50:20 -0800

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
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: Michael Everson <[email-masked]>
Date: Sat, 23 Feb 2008 22:38:29 +0000

At 13:50 -0800 2008-02-23, Doug Ewell wrote:

>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 
>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.

Michael objects to pointless busywork. The reviewing process should 
not be made more difficult for the Reviewer. He should Review.

>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.
>

-- 
Michael Everson * http://www.evertype.com
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Sat, 23 Feb 2008 19:07:16 -0500

Doug Ewell scripsit:

> Michael and me

I agree, and think this should be undone.  ISO-based changes are their
own justification: we don't need the detailed information that the
registration form provides.

-- 
We call nothing profound                        [email-masked]
that is not wittily expressed.                  John Cowan
        --Northrop Frye (improved)
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: Addison Phillips <[email-masked]>
Date: Sat, 23 Feb 2008 16:42:02 -0800

> noticed this change sooner.

Probably a lot sooner :-), since it was in draft-06 that this sentence 
makes its first appearance:

--
Usually this requires that the Language Subtag Reviewer fill in and 
submit the registration form found in Section 3.5 (Registration 
Procedure for Subtags) for the new or updated record.
--

IIRC, this was done as part of clarifying the public review process and 
time periods for the automatic registrations. RFC 4646 didn't say very 
explicitly whether Michael was going to submit information to the list, 
for how long he was obliged to wait for commentary, and that sort of thing.

> store.  Recall that ISO-based changes often come several at a time.

I am not fond of the registration forms. I think their preparation and 
archiving is a lot of busy work for IANA, Doug, and the LSR--and they 
are difficult and annoying for most applicants to use. Personally, I 
wish we'd do away with the form and just require the necessary 
information be submitted with the record.

Nonetheless, some people like the forms very much.

I note that every registration coming from the LSR will bear the exact 
same information each and every time and most of this information has to 
be sent to the list anyway. Items 4 and 5 in the reg form don't apply to 
items required by BCP 47. So the work involved would be extremely small.

> RFC 4646, as quoted above.

You're correct and my comment above is wrong.

The problem here is that CEW's comment exposes one reason why these 
changes were made: if you use the registration forms, it's kind of weird 
not to see all insertions and modifications archived.

 > Recall that ISO-based changes often come several at a time.

Good point: should we relax the restriction on the LSR sending them as a 
  batch to IANA?

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 23 Feb 2008 17:03:13 -0800

Hi -

As a technical contributor, I object to special-casing the archival
requirements.  *All* changes, regardless of source, should
be archived, in my opinion.  However, I do agree that creating
registration forms for ISO-trigged changes does seem a bit
like busy work.  If folks thing that ISO changes are so frequent
that this busy work is truly onerous,  I think IANA could satisfy
the spirit of the requirement by simply archiving the relevant email
message in those cases.

Randy

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 23 Feb 2008 19:47:23 -0800

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

> IIRC, this was done as part of clarifying the public review process 
> and time periods for the automatic registrations. RFC 4646 didn't say 
> very explicitly whether Michael was going to submit information to the 
> list, for how long he was obliged to wait for commentary, and that 
> sort of thing.

I agree with improving the review process, particularly with regard to 
transparency and timeliness.  I don't agree with some of the other ideas 
that came out of that effort, such as term limits for the Reviewer 
(which apparently never made it into any draft) or the need to formally 
reconfirm the Reviewer when 4646bis is published (which we never did for 
4646 or 3066).  And I don't agree about registration forms for ISO-based 
changes, as you know.

> Nonetheless, some people like the forms very much.

Question for those people: What is the specific benefit of forms for 
ISO-based changes?

> same information each and every time and most of this information has 
> to be sent to the list anyway. Items 4 and 5 in the reg form don't 
> apply to items required by BCP 47. So the work involved would be 
> extremely small.

I don't see a problem with saying:

1.  There are two types of subtags, those that come from individual 
requests and those that come from ISO or UN standards.  You can tell 
which are which from the syntax; you don't even need to look at the 
Registry.

2.  New subtags and changes that come into being from individual 
requests have registration forms; those that come from ISO or UN 
standards do not.

> Good point: should we relax the restriction on the LSR sending them as 
> a batch to IANA?

Speaking as the one who prepares things for Michael to send to IANA, and 
occasionally the one who sends them, I don't support this.  Surprised? 
While it might be a good idea and save us some work, it would be a 
non-trivial change in procedure, and now that we're in WG Last Call I 
think the pain and delay of debating such a change is greater than the 
potential benefit.  Look how much we argued over whether IANA could be 
trusted to put UTF-8 characters into the Registry correctly.

---

From: Addison Phillips <[email-masked]>
Date: Sun, 24 Feb 2008 11:09:00 -0800

Doug Ewell wrote:
>  or the need to formally
> reconfirm the Reviewer when 4646bis is published 
 > (which we never did for 4646 or 3066).

Actually, that's not true. There was "reconfirmation" (prehaps that is 
too strong a word) of Michael as the reviewer at least in the 3066->4646 
changeover.

> which are which from the syntax; you don't even need to look at the 

This point is superfluous, as we'll see in a second.

> requests have registration forms; those that come from ISO or UN 
There are two types of *registration*. There are registrations required 
by rule and there are registrations by request. The latter includes a 
process for registering changes to ISO-assigned codes, which has 
actually been used. These changes appear in the archive. Registrations 
by rule do not.

> trusted to put UTF-8 characters into the Registry correctly.

Hmm... I don't think it would be that big a change. In fact, it is 
limited to a single sentence in Section 3.3, which currently reads:

--
Each individual subtag affected by a change MUST be sent to the 
ietf-languages list with its own registration form and in a separate 
message.
--

... to which we would add:

--
Additions of new records MAY be batched together for submission to IANA 
as a set.
--

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 24 Feb 2008 20:13:44 -0800

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

>> or the need to formally reconfirm the Reviewer when 4646bis is 
>> published (which we never did for 4646 or 3066).
>
> too strong a word) of Michael as the reviewer at least in the 
> 3066->4646 changeover.

True, IETF did confirm Michael in the position of Language Subtag 
Reviewer, in their response to one of the many appeals against 4646. 
They were never asked to solicit nominees anew, however, as they will be 
now.

> There are two types of *registration*. There are registrations 
> required by rule and there are registrations by request. The latter 
> includes a process for registering changes to ISO-assigned codes, 
> which has actually been used. These changes appear in the archive. 
> Registrations by rule do not.

I'm sure there is an important distinction between my description of the 
situation and Addison's, and furthermore I'm sure Addison's description 
is better.  I'm not sure the difference matters in this context.  Under 
4646, registration forms for "registrations by rule" do not appear in 
the archive, because there are no such forms.  Under draft-4646bis, they 
do exist and are archived.

> Additions of new records MAY be batched together for submission to 
> IANA as a set.
> --

If that is all we need to say, and there is no *requirement* to change 
things, and nobody feels the need to fine-tune this provision to death, 
then I have no problem with it,  Again, cc'ing Michael to make sure he 
sees it.