Archival of registration forms

Doug Ewell dewell at
Tue Apr 24 17:03:33 CEST 2007

The Language Subtag Registration Form, originally submitted by the 
proposer for additions and changes NOT triggered by change to the core 
standards, is shown in Figure 5 of RFC 4646 (Section 3.5, page 30 in the 
plain-text version).  This form has NOT been sent to IANA thus far.

What we have been sending to IANA is the Language Subtag Modification 
Form shown in Figure 4 (Section 3.3, page 25 in the plain-text version).

My understanding was that the Registration Form was intended for the 
proposer to present the new subtag and explain its usage and context and 
history and references to the ietf-languages list, to help the Reviewer 
and other list members evaluate the subtag and raise questions.  I 
further understood that the *record* to be added or changed in the 
Registry was what was to be sent to IANA:

"When the two-week period has passed, the Language Subtag Reviewer 
either forwards the record to be inserted or modified to iana at 
according to the procedure described in Section 3.3, or rejects the 
request because of significant objections raised on the list or due to 
problems with constraints in this document (which MUST be explicitly 
cited)."  (Section 3.5)

"When either a change or addition to the registry is needed, the 
Language Subtag Reviewer MUST prepare the complete record, including all 
fields, and forward it to IANA for insertion into the registry.  Each 
record being modified or inserted MUST be forwarded in a separate 
message."  (Section 3.3)

It was thought that sending additional information to IANA that was not 
intended for insertion into the Registry, such as the requester's name 
and e-mail address and extensive bibliographic references, would result 
in confusion on the part of IANA and possible errors in the Registry.

I recognize that this conflicts with the wording in in Section 3.5 which 
spurred this thread:

"All approved registration forms are available online in the directory under 'languages'."

It seems to me that if IANA needs to archive (which I assume also means 
"make publicly available") the original registration forms, then there 
is substantial duplication between the two forms in Figure 4 and Figure 
5 that needs to be resolved.  It needs to be clear to IANA which 
information is to be added to the Registry and which is not.  I think 
this is an ideal time to review the two forms and possibly consolidate 
them for RFC 4646bis.

If desired, I can go through the ietf-languages archives and find the 
original Registration Forms for changes made since the launch date 
(October 2005).  It is important to realize that we have *not* been 
making changes to the original form, much less requiring the original 
submitter to make them, to reflect changes to the request that have 
resulted from list discussion.  We will need to decide how to resolve 
any differences, if at all, and we should probably do all of this on the 
list to ensure transparency and openness and avoid disputes, as Addison 
pointed out.

I want to emphasize that any deviations from RFC 4646 for which I am 
responsible, as Michael's unofficial golf caddy, have been in the 
interest of getting the requester's subtags registered and maintaining 
the intended form and function of Registry entries as I understand it. 
Michael and I did edit down the Comments field in Reşat's recenty 
approved subtag, to reduce the number of words while keeping all of the 
alternative names he listed.  I imagine that with IANA archiving of the 
registration forms, for past and future registrations, the perceived 
need to put all of this in the Registry may be reduced.

Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14

More information about the Ietf-languages mailing list