[Ltru] Re: Language tags in the future version of HTTP

Doug Ewell wrote:

>> For 2616bis they could use a simplified syntax in the direction
>> of  tag = primary *( "-" auxiliary )  directly expanded
>> in  tag = 1*8( ALPHA / DIGIT ) *( "-" 1*8( ALPHA / DIGIT ))  with
>> a note in prose that tags are actually supposed to be BCP 47 tags.

> We tried that with the "grandfathered" production in 4646, and
> we got complaints from people unhappy with the loose syntax that 
> appeared, taken out of context, to allow "en-a-b-c-d-e".

2616bis (http) mainly needs to *_transport_* tags, interpreting them
is IMO not the same layer.  We likely agree that 2616bis "MUST NOT" 
copy 4646 syntax, especially not while 4646bis rewrites major parts
of it.  They could try  tag = <as specified in BCP 47>  adding some
valid examples based on the current registry.  It's already clear
that they get rid of any 1*8( ALPHA ), and i-cherokee or en-cockney
in the latest 2616bis draft were also bad ideas.

> Now we have a separate "irregular" production that enumerates all
> the grandfathered tags that don't fit the rest of the syntax.

That list could be trimmed by regulating i-whatever instead of the
zero registered languages matching  5*8( ALPHA )  for i-uniling or
i-liaden.  If a registered language ever needs scripts, or other
subtags, then it most likely already qualifies for a proper 639-3
code.  My crystal ball says, hard to judge based on no real case.

> are we going to remove the extlang production from the syntax
> and add a lot more items to the "irregular" list

I'd hope that we do this.  We could mitigate it by building some
sublists, e.g. sgn-irregular / zh-irregular / other-irregular

> If their home-grown syntax doesn't agree with BCP 47, it's not
> clear which one people will believe.

Well, the generic URI syntax in STD 66 doesn't explain details
for various specific URI schemes, including schemes specified 
in STD 66.  Nothing's wrong with that, just a different level
of abstraction.  If you want to know how many servers handle the
name=value details of queries you're forced to test it with real
servers, it's not specified in STD 66.  If you want to know how
mailto URIs work (if at all) you have to look in Martin's draft,
and after that you've to judge how far away the I-D still is 
from anything related to real mailto-URIs.  But real mailto-URIs
not matching the generic STD 66 syntax are broken, if they work
or not, so it's not quite hopeless... :-)

> Remember how many people thought RFC 1766 and 3066 promised 
> only "xx" and "xx-XX".

Yes, but it wasn't too hard to learn that this wasn't the case,
with beautiful examples such as i-default or en-GB-oed.  If an
implementor doesn't bother to read the spec. trying to improve
the spec. might be a waste of time (unless it's an improvement
towards readability and KISS)

 Frank

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru