Subject: [Ltru] Re: prefixes for date variants

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Sep 2006 00:09:09 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

>> Existing tag processors will reject the new tags only if they are 
>> utilizing an outdated copy of the Registry.  Such a processor would 
>> also reject the now-valid tag "zza" if its copy of the Registry is 
>> older than 2006-08-29.  The same situation applies to variant 
>> prefixes.
> ...
>
> A reminder - the registry draft says:
>
>   Although the specification of valid subtags for an extension (see:
>   Section 3.7) MUST be available over the Internet, implementations
>   SHOULD NOT mechanically depend on it being always accessible, to
>   prevent denial-of-service attacks.

That passage specifically refers to extension subtags, which would be 
available at whatever URL was specified in the RFC that defines the 
extension.

It's true that processors are not expected to go out to the IANA site 
and download a new Registry on every usage.  (This isn't necessary 
anyway, since an application can check if its copy is up-to-date by 
retrieving the File-Date record from IANA -- only 23 bytes, including 
CRLF -- and comparing it with the local copy.)

> Consequently, as a technical contributor I think "utilizing an 
> outdated copy" should be considered an extremely likely scenario. 
> Furthermore, it may be worth thinking about when (if ever) a 
> validating processor is really needed.

The point I was trying to make was that the problem is not unique to 
variant prefixes; it applies to all subtags.  Addison pointed out that 
the effect is different for pure generic variants, born without a 
prefix, but then I don't think those are such a hot idea anyway.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
Editor, draft-ietf-ltru-initial

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

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Sep 2006 00:31:30 -0700

John Cowan <cowan at ccil dot org> wrote:

> *However* (and I think this has always been "understood" but not 
> expressed) this would *not* apply to any encompassed language that 
> already has a language tag as a consequence of being in 639-1 or 639-2 
> already.  Thus sr, not sh-sr; nn, not no-nn.
>
> Just wanted to get that on record.

This sounds to me like case number 5 from John's fine summary of August 
28:
http://www1.ietf.org/mail-archive/web/ltru/current/msg05265.html

Now that the new charter has been approved, and the due dates for first 
drafts were *NOT* extended as I requested, we have only 21 days to put 
together some 3066ter documents.  In order for me to build a 
registry-initialization draft, we need to determine the rules (as John 
has done here for one such rule).  This includes, at a minimum:

1.  what to do about the Description fields when the 639-2 and 639-3 
descriptions don't match exactly

2.  what to do about sign languages

3.  which grandfathered tags to deprecate in favor of new 639-3-based 
subtags (John tackled this in msg05281.html but I'm not sure about some 
of his conclusions)

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 10:49:18 +0200

Doug Ewell wrote:

> the due dates for first drafts were *NOT* extended as I
> requested, we have only 21 days to put together some 3066ter
> documents.

Don't take these dates *too* serious, no angry ADs asking Randy
and Martin why LTRU is out of line if that takes a few weeks
longer - but admittedly I was ashamed when I stumbled over an
IESG narrative report with a DISCUSS for an ABNF issue in the
matching draft.  Let's please get the ABNF right in 3066ter
before Last Call.  (If we touch the ABNF at all, unlikely)

> we need to determine the rules

Yes.  Don't touch anything in the existing registry unless it
is grandfathered or a variant.  Downgrading language tags to
extlang-s is out.

> 1.  what to do about the Description fields when the 639-2
> and 639-3 descriptions don't match exactly

Keep as is, 639-2 as primary source, 639-3 as supplemental.

> 2.  what to do about sign languages

Would a decree that sgn is a pseudo-macrolanguage help ?  IIRC
there's no chance that sgn will ever be used for something else

> 3.  which grandfathered tags to deprecate in favor of new
> 639-3-based subtags

Same procedure as for grandfathered tags replaced by 639-2 tags

Frank

---

From: John Cowan <[email-masked]>
Date: Fri, 8 Sep 2006 10:07:44 -0400

> http://www1.ietf.org/mail-archive/web/ltru/current/msg05265.html

That summary had to do with the steady-state RFC 3066ter regime; this
point has to do with the transition period when we are getting all the
639-3 code elements into the registry.  It looks like these rules will
do it:

1) If a 639-3 code element is already in the registry, either as itself
or in the form of its 639-1 equivalent, do nothing.

2) If a 639-3 code element represents an unencompassed individual language
(or a macrolanguage, but fortunately there are no such cases), add it
to the registry as a language subtag.

3) If a 639-3 code element represents an individual language encompassed
by a macrolanguage, add it to the registry as an extlang subtag, and
specify the required prefix to be the language subtag in place for that
macrolanguage.  For this purpose, all sign languages are treated as if
encompassed by the macrolanguage "sgn", which is part of 639-2 and the
registry but is not in 639-3.

> descriptions don't match exactly

Keep both.  The 639-3 descriptions have been reviewed more recently and
are more likely to be correct, especially with regard to diacritics;
the 639-2 descriptions should be effectively grandfathered.

> 2.  what to do about sign languages

As above: treat them as encompassed by the macrolanguage "sgn", and
therefore add them as extlang subtags.  Deprecate the grandfathered
equivalents.

> subtags (John tackled this in msg05281.html but I'm not sure about some 

Start picking nits, then.

-- 
John Cowan      [email-masked]        http://www.ccil.org/~cowan
        Is it not written, "That which is written, is written"?

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Sep 2006 12:37:32 -0700

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Friday, September 08, 2006 12:09 AM
> Subject: [Ltru] Re: prefixes for date variants
...
...

As a technical contributor...

If this is how folks understand the words that are there,
then we need to make the language much stronger in the update.
When an application accesses the registry using HTTP, a lot
more than 23 bytes worth of load will be inflicted on IANA's
infrastructure, which is why we put the SHOULD NOT language
in.  The DoS that matters, after all, is the attack on IANA
that such an application would inflict.

Alternatively, if the WG really believes there will be wide-spread use
of validating processors requiring current registrations, then I suggest
we might need to reconsider the use of more robust technologies, such as
those discussed in conjunction with issues like #893, #965, and #968.
(https://rt.psg.com, user and password "ietf")

Randy