Subject: RE: [Ltru] Re: -01 nits

From: "Peter Constable" <[email-masked]>
Date: Tue, 26 Apr 2005 17:57:12 -0700

> From: [email-masked] [mailto:[email-masked]]
On Behalf Of
> Frank Ellermann

> > No, since there is no restriction on how many extlangs there
> > can be currently and the grammar permits them
> 
> That's not possible for the Internet.

RFC 3066 gave no upper bound on the number of subtags that might occur
in a tag, though in practice we knew it was constrained. Clearly RFC
3066 permitted extremely long (even infinite) tags, and equally clearly
that's not possible for the Internet, but also equally clearly such tags
were not going to occur (unless generated by a rogue process, which by
definition flaunts both assumed and explicit conventions).

It's not clear to me why there's a problem if our ABNF doesn't impose an
upper bound on the number of extlang subtags at this point. We know that
we have in mind constraints that will limit how many can be used in
practice (it would be constrained by macrolanguage mappings in 639-3),
and we will have an opportunity while developing 3066ter to define
whatever further constraints we might wish.

> OTOH Peter's example indicates that they might get away with at
> most two extlang as in aaa-bbb-ccc, and that's of course okay,
> the worst "normal" case would then be length 29 instead of 26.

My point was that I cannot guarantee at this time that 639-3 might not
have two or three or n levels of macrolanguage mappings, though I think
it's extremely unlikely there would be more than a few levels, and I
don't have any specific reason to believe that there would ever be more
than one level.

Peter Constable

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 27 Apr 2005 05:32:37 +0200

Peter Constable wrote:
 
> RFC 3066 gave no upper bound on the number of subtags that
> might occur in a tag

And it was written after RfC 2231.  Now RfC 3066 is broken, we
try to fix it.  With an ugly kludges like "Suppress-Script"
this could apparently work, but *("-" extlang) is impossible.

> RFC 3066 permitted extremely long (even infinite) tags

And RfC 2231 cum 2047 doesn't allow this => RfC 3066 is FUBAR
for more than one reason.  BTW, the same is true for RfC 2231.

> It's not clear to me why there's a problem if our ABNF
> doesn't impose an upper bound on the number of extlang
> subtags at this point.

Implementors use the ABNF to write code.  They want limits and
worst cases for their buffers and tables, otherwise they make
them up on the fly, "anything longer than xxx-Ssss-nnn must be
nonsense, let's say 16 to be sure and ignore all longer tags".

That's exactly how I'd implement it, if it's something that
generates 2231 / 2047 encoded words in header fields.  Or if
it's a mail2news gateway desperately trying to get it right
for both sides - okay, maybe I'd add a dummy =?us-ascii?Q??=
to avoid dubious cases of "refolding" for news header fields
(if that's allowed, I haven't checked 2047).
 
> we have in mind constraints that will limit how many can be
> used in practice (it would be constrained by macrolanguage
> mappings in 639-3), and we will have an opportunity while
> developing 3066ter to define whatever further constraints we
> might wish.

Then we could reserve a *2("-" extlang) now, and let 3066ter
reduce it to ["-" extlang] if possible, or remove the complete
idea if ISO 639-3 wants more.  

Maybe Debbie's alpha-4 codes are better for the Internet.  IMHO
anything is better than *("-" extlang).  Even registering all
7000+ Ethnologue codes manually is better than *("-" extlang).

> I cannot guarantee at this time that 639-3 might not have
> two or three or n levels of macrolanguage mappings

But "we" (TINW) can guarantee that something with more than say
two levels is dead on arrival, maybe that helps somehow in your
ISO 639-3 debates (?)
                      Bye, Frank