Registry fixed (was: Re: Records Missing Required Field: jkp, nph, tvt)

Gordon P. Hemsley gphemsley at
Tue Aug 28 23:30:00 CEST 2012

On Tue, Aug 28, 2012 at 5:09 PM, Doug Ewell <doug at> wrote:
> [IANA: see last paragraph.]
> "Gordon P. Hemsley" <gphemsley at gmail dot com> wrote:
>> However, as far as I can tell, a violation of the field requirements
>> is not a violation of the ABNF. It is merely a violation of the prose
>> of the spec. So it would be acceptable to invalidate the individual
>> record on such a violation, but not the entire Registry.
> Well, I don't agree. IMO, when we are talking about statements like
> "Each record MUST contain at least one of each of the following fields,"
> the prose of the spec carries as much weight as the ABNF. I'd appreciate
> the original authors weighing in on this.

It seems to me that the true ABNF defines the basic or primary syntax,
and the prose defines some sort of secondary syntax or even semantics.
(If you wrote a parser based only the ABNF, for example, there would
have been no violation wrt to the missing Added fields.) This ABNF can
be used to create a registry of many things, not just language
subtags. It's only the prose that limits which fields are required in
order to have a valid record.

Consider future developments: The requirement or optionality of fields
could easily be changed via prose without having to change the ABNF at
all. Thus, a new parser could still parse an old version of the
Registry—or, on the flipside, an old parser could still parse a new
Registry—even if the prose requirements were different.

But I too am curious as to what the original authors had in mind.

>> Using this interpretation, the 2012-08-26 Registry was invalid and
>> could have been corrected without changing the date. Since the syntax
>> correction was instead given a new date version (2012-08-27), the
>> second update to fix the record violations was itself also a violation
>> of the spec.
> (I hasten to add that none of the blame for this violation belongs to
> IANA. They were informed of errors, and they fixed them promptly.)

(And I never intended to blame anyone for anything.)

>> If we feel this is important enough (and perhaps we should, to avoid
>> setting a precedent), we could fix all this simply by changing the
>> Registry version to 2012-08-28 without making any other changes. Then,
>> both versions of the 2012-08-27 Registry would be out of date, and we
>> can retroactively consider the percent-sign update as version
>> 2012-08-27 and the Added update as 2012-08-28.
>> Thoughts?
> I can check with IANA about re-releasing the current Registry with a new
> date. I suspect those of us on this list are among the few who
> downloaded the buggy 08-27 copy before it was replaced by the corrected
> 08-27 copy. But it's possible there are some tools that picked up the
> buggy one, and won't now pick up the new one because the date hasn't
> changed. Given more spare time, I probably would have written such a
> tool myself.

Not sure exactly which kind of tool you meant, but the code that I
maintain is open source (MPL):

It doesn't pick up changes automatically, but I think it does a pretty
good job of parsing the Registry.

To use it, just run:

This will output a bunch of text files that separate out the different
types of subtags, with each field tab-separated. (Though the number of
fields differs based on the subtag type.)

(To get the additional properties files, which are more
Mozilla-centric, you can then run `make`.)

Gordon P. Hemsley
me at

More information about the Ietf-languages mailing list