Subject: [Ltru] Re: Archival of registration forms

From: "Doug Ewell" <[email-masked]>
Date: Fri, 11 May 2007 07:15:12 -0700

John Cowan <cowan at ccil dot org> wrote:

>> I'd rather go the other direction and work on eliminating the rest of 
>> the form or putting less emphasis on it, since, sending two items to 
>> IANA and having them maintain them using separate processes is 
>> potentially cumbersome and adds no value.
>
> A unified process (IANA gets the registration form, archives it 
> publicly, plucks the record out and adds it to the LSR) works for me.

That one worries me.  IANA would be asked to pick item 3 ("Record 
Requested") from the completed form, reformat a long-enough Comment or 
Description to use hex NCRs and 72-character limits and two-space 
continuation, and add their own Added date (along with the File-Date 
which they already change).  Can they do all this automatically?  I'd 
hate to go back to the days when a new Registry got released with errors 
and we had to go back and have them fix it.

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

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 11 May 2007 07:20:28 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> ACK.  Do you need that also for the existing "pre-4646" templates, 
> <http://www.iana.org/assignments/lang-tags/> ?  IMO it would be nice 
> to have all registered templates on your new list, old or new, variant 
> or grandfathered.  Plus all "explicit" (= reviewed by the subtag 
> reviev list) modifications, so far that's Debbie's comment wrt the 
> Channel Islands and IM for the UK record.

The registration forms for tags registered under RFC 1766 and 3066 are 
already archived in the old directory.  I think it would be a mistake 
(not to mention a great deal more work) to try to make those 
registrations fit the new model.  We could, of course, ask IANA to copy 
them as-is to the new archive, but that would raise more questions about 
why "these" forms are so different from "those" forms, and why the old 
ones refer to complete tags instead of subtags (a distinction that is 
already hard enough to communicate to people).

---

From: John Cowan <[email-masked]>
Date: Fri, 11 May 2007 11:17:24 -0400

Doug Ewell scripsit:

> registrations fit the new model.  

+1.  1766 and 3066 were previous epochs: no point in trying to fix
them up now.

-- 
At the end of the Metatarsal Age, the dinosaurs     John Cowan
abruptly vanished. The theory that a single         [email-masked]
catastrophic event may have been responsible        http://www.ccil.org/~cowan
has been strengthened by the recent discovery of
a worldwide layer of whipped cream marking the
Creosote-Tutelary boundary.             --Science Made Stupid

---

From: John Cowan <[email-masked]>
Date: Fri, 11 May 2007 11:18:25 -0400

Doug Ewell scripsit:

> which they already change).  Can they do all this automatically?   

I'm assuming that all this would already be the case, ideally by
the submitter, in practice by the Official Doug.

-- 
You annoy me, Rattray!  You disgust me!         John Cowan
You irritate me unspeakably!  Thank Heaven,     [email-masked]
I am a man of equable temper, or I should       http://www.ccil.org/~cowan
scarcely be able to contain myself before
your mocking visage.            --Stalky imitating Macrea

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 11 May 2007 18:10:04 +0200

Doug Ewell wrote:

> We could, of course, ask IANA to copy them as-is to the new archive

Yes, or leave them where they are.  When I go to their new list with
links it doesn't matter where they really are - as long at the list
offers the tags with working links.

> why "these" forms are so different from "those" forms, and why the
> old ones refer to complete tags instead of subtags (a distinction
> that is already hard enough to communicate to people).

Point.  Maybe their new list could simply offer one link to the old
directory.  This kind of micro-management of the IANA website is of
course no business for 4646bis, it's merely a "feature request":

If users want to know who registered i-lux, or similiar questions.

Frank

---

From: Addison Phillips <[email-masked]>
Date: Fri, 11 May 2007 10:54:15 -0700

> and we had to go back and have them fix it.

Actually, the text is pretty clear: the LSR must send the form with the 
*exact* record (NCRs, line length limits, and all) embedded in it. It is 
"record requested", after all.

I massaged the text in section 5.1 (IANA considerations) to ensure that 
the dates thing was clear. Again, the LSR supplies the *exact* record to 
add/update. Note that the 'Added' field represents the *original* add 
date of the subtag to the registry. A change to the record would not 
change the field.

Given the new version of the instructions (please look and comment as 
appropriate), I actually think IANA's job might even be easier... but 
the LSR (probably via their "Official Doug") need to ensure that they 
follow the RFC......

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 12 May 2007 00:33:21 -0700

John Cowan <cowan at ccil dot org> wrote:

>> Requested") from the completed form, reformat a long-enough Comment 
>> or Description to use hex NCRs and 72-character limits and two-space 
> I'm assuming that all this would already be the case, ideally by the 
> submitter, in practice by the Official Doug.

No, what I mean is this:

Recently the Reviewer and ietf-languages group agreed to register a 
variant subtag for a particular orthography of Belarusian.  To do this, 
we submitted the form below, whose format is specified in RFC 4646, 
Section 3.3:

---begin example---
LANGUAGE SUBTAG MODIFICATION
File-Date: 2007-04-27
%%
Type: variant
Subtag: tarask
Description: Belarusian in Taraskievica orthography
Added: 2007-04-27
Prefix: be
Comments: The subtag represents Branislau Taraskievic's Belarusian
  orthography as published in "Bielaruski klasycny pravapis" by Juras
  Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka (Vilnia-
  Miensk 2005).
%%

---end example---

This form was sent in an e-mail whose Subject line was:

    NEW-INSERT LANGUAGE SUBTAG MODIFICATION for "tarask"

The word "INSERT" is also required by Section 3.3.  If this were a 
change to an existing entry, the Subject line in the e-mail would have 
to contain the word "MODIFY" instead.

Now, in addition to this, we are also sending IANA the complete 
registration form representing this entry, starting from the original as 
submitted by the proposer, but with all necessary amendments to make it 
match the final registration.  That form is specified in Section 3.5, 
and looks like this:

---begin example---
LANGUAGE SUBTAG REGISTRATION FORM
1. Name of requester: Jaska Zedlik
2. E-mail address of requester: jz53 @ zedlik.com
3. Record Requested:

   Type: variant
   Subtag: tarask
   Description: Belarusian in Taraskievica orthography
   Prefix: be
   Comments: The subtag represents Branislau Taraskievic's Belarusian
orthography as published in "Bielaruski klasycny pravapis" by Juras
Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka
(Vilnia-Miensk 2005).

4. Intended meaning of the subtag:

The subtag is intended to represent the Belarusian orthography as
published in "Bielaruski klasycny pravapis" by Juras Buslakou, Vincuk
Viacorka, Zmicier Sanko, and Zmicier Sauka (Vilnia-Miensk 2005).

5. Reference to published description of the language (book or article):

Taraskievic, Branislau. Bielaruskaja gramatyka dla skol. Vilnia: Vyd.
"Bielaruskaha kamitetu", 1929, 5th edition.

Buslakou, Juras; Viacorka, Vincuk; Sanko, Zmicier; Sauka, Zmicier.
Bielaruski klasycny pravapis. Vilnia-Miensk, 2005.

6. Any other relevant information:

Belarusian in Taraskievica orthography became widely used, especially in
Belarusian-speaking Internet segment, but besides this some books and
newspapers are also printed using this orthography of Belarusian.
---end example---

Note that item 3 in this form is mostly equivalent to the finished 
record, except that the Added date is missing (it belongs after 
Description) and the Comments field needed to be reformatted to conform 
to the Registry format.  There is no 72-character line limit in 
registration forms.  Additionally, if this record had included 
characters that had to be escaped with hex NCRs, those might not have 
been present in the registration form and this would have to have been 
fixed.

In short, the finished record may be editorially different from the way 
the same information is provided in the registration form.

Addison had proposed that we could simply send the registration form to 
IANA and they would be able to extract the record correctly from item 3 
and modify the Registry accordingly.  As I wrote before, that worries me 
because of all the additional editorial work that would NO LONGER be 
done by the Official (or Unofficial) Doug, but by IANA.  Although IANA's 
track record of inserting new and changed records has improved 
considerably in the past year and a half, I worry whether these nitty 
details will be handled correctly.  (I observe again that IANA is 
distributing the Registry with LF-terminated lines, even though RFC 4646 
Section 3.1 specifies CRLF.)

In other words, I suggest that ietf-languages should continue to send 
IANA the registration form and the new record as two separate items, and 
require IANA only to archive the former and add the latter into the 
Registry, as they do now.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 12 May 2007 15:12:01 +0200

Doug Ewell wrote:

> I observe again that IANA is distributing the Registry with
> LF-terminated lines, even though RFC 4646 Section 3.1 specifies CRLF

Cheat:     [[Kids, don't try this on a Mac, *NIX, or Linux box]]
<ftp://ftp.iana.org/assignments/language-subtag-registry;type=a>

Frank

---

From: John Cowan <[email-masked]>
Date: Sat, 12 May 2007 15:54:30 -0400

> the same information is provided in the registration form.

Quite so.  However, there is nothing to stop you doing your editorial
work on the whole registration form and letting IANA extract the
record from it as is, rather than sending the registration form
edited one way and the record edited another way.

> done by the Official (or Unofficial) Doug [...].

Sure it would, just on the whole registration form.

> Registry, as they do now.

I don't actually have a problem either way; I'm just pointing out that
these particular objections don't actually have force.

-- 
Do what you will,                       John Cowan
   this Life's a Fiction                [email-masked]
And is made up of                       http://www.ccil.org/~cowan
   Contradiction.  --William Blake

---

From: Addison Phillips <[email-masked]>
Date: Sat, 12 May 2007 13:18:02 -0700

> these particular objections don't actually have force.

+1

This is why I did it this way. Sending two items to IANA (especially if 
the record is allowed to be different from the form in some way!!) is 
complicated and asking for trouble. Such as: what happens when the 
record and the form differ is some substantive way?

Since the form contains the record, it is better for all concerned if we 
focus attention on the form. Note too that submission of the form is 
different from discussion of the record's contents. This should make it 
easier to track the state of a request (although it appears that Michael 
hasn't paid particular attention to the details of the formal process, 
such as the nature of requests, the time periods, and what he is 
required to do/not do when one comes in).

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 12 May 2007 13:34:03 -0700

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

> This is why I did it this way. Sending two items to IANA (especially 
> if the record is allowed to be different from the form in some way!!) 
> is complicated and asking for trouble. Such as: what happens when the 

I thought that's why we were going to start sending the final form to 
the ietf-languages list for a week-long inspection period.

> Since the form contains the record, it is better for all concerned if 
> we focus attention on the form. Note too that submission of the form 
> is different from discussion of the record's contents. This should 
> make it easier to track the state of a request

If that is preferred, I suggest we reorganize the form so that the 
section that is supposed to contain the actual record (currently section 
3) contains it *precisely*, with no leading spaces, and with 
placeholders for all possible fields, including an "Added" field which 
would be filled in by us before the final inspection period.

I'm just trying to prevent gratuitous editorial discrepancies.  I 
understand you're trying to prevent substantive discrepancies, and both 
of us are right.

If you want to make IANA's job easier in processing these forms, that is 
fine, and if you want to make the list's job easier in understanding and 
verifying them, that is fine too.  Please don't spend too much time 
worrying about making my job easier in preparing them and forwarding 
them to Michael.  It's not that hard.

---

From: Addison Phillips <[email-masked]>
Date: Tue, 15 May 2007 07:04:21 -0700

Doug Ewell wrote:
> done by the Official (or Unofficial) Doug, but by IANA.  

There shouldn't *be* any additional editorial work. While the form in 
the current draft is incomplete, the record requested can have an Added 
date and other fields, making the job one of mere cut-and-paste. I don't 
see why this is that difficult.

On the other hand, I am *very* worried by the idea that we'll be sending 
two versions of the record. If the "record requested" doesn't match the 
"record registered", isn't that a problem?

> Registry, as they do now.

Have you had a chance to study the changes I made in the current draft 
yet? I think I might have address your issues while sticking with a "one 
item send" model.

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 15 May 2007 08:20:00 -0700

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

>> because of all the additional editorial work that would NO LONGER be done 
>> by the Official (or Unofficial) Doug, but by IANA.
>
> There shouldn't *be* any additional editorial work. While the form in the 
> current draft is incomplete, the record requested can have an Added date 
> and other fields, making the job one of mere cut-and-paste. I don't see 
> why this is that difficult.

Formatting the records for the Registry involves making sure that there are 
no physical lines longer than 72 characters, that all non-ASCII characters 
and apostrophe are hex-escaped, that each field starts in column 1, and that 
continuation lines have two leading spaces (though I may be wrong about the 
last two; I don't see them in the RFC or current draft although I know we 
talked about them).

The template in Section 3.5 (RFC and current draft) has three leading spaces 
before each field name, which requires reformatting to conform to Registry 
syntax as I understand it.  There is nothing in the registration 
instructions to address the other points above, so each form -- even the 
most carefully filled-out one -- would require non-trivial editing before 
IANA could simply pluck the record out of it.

> "record registered", isn't that a problem?

But isn't that why you wanted the final form sent to the list for a one-week 
review period?  To ensure it matched the agreed-upon record?

> yet? I think I might have address your issues while sticking with a "one 

I scanned the last half of 3.5  ("study" would not be the word) and didn't 
see anything that addresses my concerns about formatting.  Software that 
reads the Registry and interprets its contents needs to rely on a consistent 
format; that's why we changed from the loose format of RFC 3066.  We should 
arrange things to ensure the best chance of IANA inserting the record 
correctly the first time.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 May 2007 22:04:48 +0200

Doug Ewell wrote:
 
> Formatting the records for the Registry involves making sure
> that there are no physical lines longer than 72 characters,
> that all non-ASCII characters and apostrophe are hex-escaped,
> that each field starts in column 1, and
> that continuation lines have two leading spaces
[...]
> I may be wrong about the last two; I don't see them in the
> RFC or current draft although I know we talked about them

One space to start a folded "continuation" line is enough.  Two
might be clearer for readers, and two are certainly allowed,
like eight would be allowed for a tab-like indentation. 

Yes, a field-name starts in column 1, that's the only (and
therefore important) difference from a folded line.

> The template in Section 3.5 (RFC and current draft) has three
> leading spaces before each field name, which requires 
> reformatting to conform to Registry syntax as I understand it.

The template is organized to be readable.  Cut and paste at the
obvious column (3 or 6) should be simple for the folks at IANA
for a complete record.  They'd then also insert a %%-delimiter 
for new records, or they'd replace an old record between these
delimiters.  And they'd update the file-date "record".  That's
no rocket science, the existing records are a good example how
it's supposed to work.  

They've already "explored" one plausible way to get this wrong,
once.  They've no reason to run into exactly the same problem
again, ever.

> each form -- even the most carefully filled-out one -- would
> require non-trivial editing before IANA could simply pluck
> the record out of it.

Folding at column 3 + 72 = 75 for an effect of 72 after copy
and paste might be non-trivial, but they get a folded recorded
within the form.  If you think that that's too dangerous you
can remove these three extra columns in a submitted form.  You
would also remove the additional three columns introduced by
the RFC layout, if requesters haven't done this already.  

Frank

---

From: Addison Phillips <[email-masked]>
Date: Tue, 15 May 2007 20:53:08 -0700

Doug Ewell wrote:
> 
> The template in Section 3.5 (RFC and current draft) has three leading 
> spaces before each field name, which requires reformatting to conform to 
> Registry syntax as I understand it.  There is nothing in the 
> registration instructions to address the other points above, so each 
> form -- even the most carefully filled-out one -- would require 
> non-trivial editing before IANA could simply pluck the record out of it.

Yes: I believe I said we should fix the form.

> 
>> On the other hand, I am *very* worried by the idea that we'll be 
>> sending two versions of the record. If the "record requested" doesn't 
>> match the "record registered", isn't that a problem?
> 
> But isn't that why you wanted the final form sent to the list for a 
> one-week review period?  To ensure it matched the agreed-upon record?

No. Emphatically no.

I wanted the final form (originally "record", since I championed doing 
away with the form) on the list for some period of time to ensure that 
what was "approved" by the LSR was well-known, clear, and had been 
available for comment by list members. Approval of some form of the 
request unseen--in some cases even by the requester--is not in keeping 
with an IETF process as I understand it. A requester could quite easily 
consider some of the proposals a perversion of their intent.

The form that's approved should contain that record that's approved. 
There should be sufficient time for list members to comment on the 
specific form being registered, not just the general "idea" behind the 
registration.

>> yet? I think I might have address your issues while sticking with a 
>> "one item send" model.
> 
> I scanned the last half of 3.5  ("study" would not be the word) and 
> didn't see anything that addresses my concerns about formatting.  

No, we need to fix the form.

> Software that reads the Registry and interprets its contents needs to 
> rely on a consistent format; that's why we changed from the loose format 
> of RFC 3066.  We should arrange things to ensure the best chance of IANA 
> inserting the record correctly the first time.

The *registry* format is not in question here. It is whether we submit 
the form, the record, the form-and-the-record, or what.

Personally, I think the form is an anachronism, but I want to publish 
4646bis sometime.

If we *must* send the form to IANA, let us not fall into the trap of 
sending two things. Let us fix the form to be suitable and be done with it.

IMHO,

Addison

---

From: John Cowan <[email-masked]>
Date: Wed, 16 May 2007 01:14:00 -0400

> non-trivial editing before IANA could simply pluck the record out of it.

I think we should just go ahead and dump the three leading spaces.

-- 
One Word to write them all,             John Cowan <[email-masked]>
  One Access to find them,              http://www.ccil.org/~cowan
One Excel to count them all,
  And thus to Windows bind them.                --Mike Champion

---

From: Martin Duerst <[email-masked]>
Date: Wed, 16 May 2007 16:03:27 +0900

>I think we should just go ahead and dump the three leading spaces.

Are you proposing that the RFC to be (4646bis) the
LANGUAGE SUBTAG REGISTRATION FORM without leading spaces?

In that case, I think we have to check two things:
1) Check whether (and how) this can be done with xml2rfc.
   Addison, can you give it a try?
2) Check with the RFC Editor whether they'd allow this,
   assuming that the WG (and if necessary the AD and the IESG)
   support it for good reasons.

Once we get your confirmation, we have checked 1), and I don't hear
anything strongly again this direction, I'll check with the RFC Editor.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Addison Phillips <[email-masked]>
Date: Wed, 16 May 2007 11:10:49 -0700

>    Addison, can you give it a try?

You mean in the generated text format (the way RFCs are formatted)? 
Nope. But somehow the claim that removing the three spaces from the 
record is "non-trivial editing" seems kind of lame.

There are all sorts of ways to address this issue. We can write lint 
tool, for example. Since the requested record is embedded in %% markers, 
it should be easy to run a tool to fix escapes, line breaks, and to fold 
(or unfold) whitespace as needed.

Some other alternatives occur to me:

1. Eliminate the form by incorporating the additional information into 
the record itself. Some of the information in the form is redundant. I 
think we could break it down to adding:

  Requested-by: Addison Phillips <[email-masked]>
  Reference: Reference to published description
    of the language (book or article) which may include
    URIs, ISBNs, ISSNs, or other information. Like Comment
    only different.

2. Eliminate the form by adding support for file-level comments in the 
registry. These file level comments would contain the form fields. IANA 
could include them in the registry or remove them and just include them 
in the registration request archive:

%% Requested by: Addison Phillips
%% mailto:[email-masked]
%% Reference: Reference to published description
%%   of the language (book or article) which may include
%%   URIs, ISBNs, ISSNs, or other information. Like Comment
%%   only different.
%%
Type: variant
Subtag: ...
...
%%

3. Continue to archive request forms, but archive all of them, with 
their disposition. The LSR only forwards the record (as today) to IANA 
for inclusion in the subtag registry. Ideally, a tool is used to 
generate and submit requests so that IANA doesn't have to monitor the 
ietf-languages list. That, or the LSR must submit the request forms. 
This would mean reformatting the request form a bit to aid tracking:

====
LANGUAGE SUBTAG REGISTRATION FORM
1. Record Requested:
%%
Type:
Subtag:
Description:
Added:
Prefix:
Preferred-Value:
Deprecated:
Suppress-Script:
Comments:
%%
2. Name of requester:
3. E-mail address of requester:
4. Date of Request:
5. Reference to published description
    of the language (book or article):
6. Any other relevant information:

To be filled in by IANA or LSR:

7. Status: (accepted, rejected, open)
8. Action Date:
=====

Any others?

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 16 May 2007 23:16:25 -0700

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

> You mean in the generated text format (the way RFCs are formatted)? Nope. 
> But somehow the claim that removing the three spaces from the record is 
> "non-trivial editing" seems kind of lame.

For you and me, definitely trivial.  Perhaps for the new guard at IANA as 
well.

> 1. Eliminate the form by incorporating the additional information into the 
> record itself. Some of the information in the form is redundant. I think 
> we could break it down to adding:
>

Would this go into the Registry along with everything else?

> could include them in the registry or remove them and just include them in 
> the registration request archive:
>

I like file-level comments, but for file-level information, not for 
something like this.  I'm not crazy about the free-text format either. 
Suddenly alternative 1 doesn't look so bad.

> 3. Continue to archive request forms, but archive all of them, with their 
> disposition. The LSR only forwards the record (as today) to IANA for 
> inclusion in the subtag registry. Ideally, a tool is used to generate and 
> submit requests so that IANA doesn't have to monitor the ietf-languages 
> list. That, or the LSR must submit the request forms. This would mean 
> reformatting the request form a bit to aid tracking:
>
> ====

This is exactly what I had in mind.  I totally support this.

---

From: Addison Phillips <[email-masked]>
Date: Wed, 16 May 2007 23:46:47 -0700

...

> Would this go into the Registry along with everything else?

Yes.

>> registry. These file level comments would contain the form fields. 
>> IANA could include them in the registry or remove them and just 
>> include them in the registration request archive:
>>

> Suddenly alternative 1 doesn't look so bad.

Yes, but it is a (vile) alternative.

...

> This is exactly what I had in mind.  I totally support this.

I would just be concerned about the praticality of capturing the forms 
and their status. On the other hand, it might actually help in tracking 
request status. And it would establish a kind of record of what had been 
rejected---not just the things registered.

Addison

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 17 May 2007 21:32:42 +0200

> rejected---not just the things registered.

Keeping records of rejected or open requests makes me nervous, there 
could be various ways to abuse this for DoS attacks.  You likely want 
the opposite effect, requests rejected immediately as "dupe" with a
pointer to the old decision.  But fine-tining the procedures is kind
of pointless at the moment for the known reasons.

Frank