Re: [Ltru] RE: ISO 639-2 decision: "mis"

Hi -

As a technical contributor....

> From: <Karen_Broome@spe.sony.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Friday, June 15, 2007 5:20 PM
> Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis"
...
> There's a difference between "fully supporting" BCP 47 and being compliant 
> with BCP 47. I don't think there's any organization that has a real-life 
> use for fully supporting BCP 47. These codes are frequently used in 
> databases; if a developer limits the size of that field such that the most 
> granular private use tag imaginable does not fit the space allocated, you 
> consider that to an implementation "based on" BCP 47 even if all tags in 
> the system are valid?

RFC 4646 says support for a maximum of at least 33 characters is a MUST,
42 characters is a SHOULD.  Anything less is not BCP 47.

> I don't think what you suggest is a useful or realistic way of looking at 
> this. If I only need en, fr, de, and it, I think that's fully compliant 
> with BCP 47. Must I support gsw-Hant-BV-x-chicago-mwbstr14-spoken to claim 
> to be aligned with BCP 47? 

If someone designs a protocol, and it can only handle the language tags
en, fr, de, and it, that protocol, in my judgement, would not be compliant
with BCP 47.  This doesn't say anything about the tags that a particular
application using that protocol might *generate*.  I'm just saying that it
must be able to cope with receiving valid tags of up to 33 characters in
length.

I'm urging folks to think about where this specification sits in the "food chain".
It specifies an element that is used by other protocols.  If other protocols
can claim to use this specification, without actually being able to carry the
full range of values, there will be little value to having this specification or to
claiming to support it.  It'd be like claiming to support ASCII, but not permitting
use of the letter "Z".  I fully recognize that for good historical reasons there
will be protocols that are restricted to a subset.  However, I'd strongly urge
against claiming that such protocols "supported" or were "aligned with",
much less "conformant with" BCP 47.

I think part of the disconnect is that some have been thinking about databases,
rather than protocols.

Randy

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