John Cowan <cowan at ccil dot org> wrote:
If IANA erroneously creates a version of the Registry with a File-Date in the future (and the Official Doug has assured us that this does happen), then the next update may create a situation where the File-Date of the new version is less than the File-Date of the old version.
I fear there may have been a misunderstanding, probably on my part in interpreting the original concern.
IANA has never issued a Registry with a File-Date in the future -- that is, later than the actual date of issue. OTOH, they have often issued a Registry with a File-Date later than the Added date of any of the tags and subtags it contains. This happens when they insert new subtag records with an Added date of X, but don't publish the new file until Y.
Furthermore, as I should have pointed out before, it is *supposed* to happen when there is a round of changes that includes no new subtags, only modifications to existing subtags (because there is no "Modified" date). This might happen, for example, when the only change is to add or delete Suppress-Script fields. The latest round of changes instigated by ISO 639-2 name changes would have been like this, if we also hadn't deferred 'Zinh' until that round.
There was an error once (2007-12-05) where IANA forgot to update the File-Date at all, leaving it at 2007-11-06, the date of the previous update. This was spotted quickly and corrected the next day.
Michael and I do attempt to batch the IANA requests together so they do not receive some today, some tomorrow, some a few days after that, because this would surely lead to confusion on the part of both IANA and users. The two-week review periods, often seen as unnecessary in the case of uncontroversial or mechanical changes, do help us coordinate this.
-- Doug Ewell * Thornton, Colorado, 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 ˆ
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.