[Ltru] Re: Frank's comments

["Frank Ellermann" <[e-mail]>]

Doug Ewell wrote:

> I'd really like the chairs to declare consensus on a number of topics, 
> because otherwise this happens: old decisions and non-decisions are 
> revisited over and over again.

Yes.  

Of course it also helps to look into the draft from time to time, I now saw
that  there are no biannual expert reappointments, good riddance.  I had
already visions of bothering NomCom with this business, or  copying
the recall procedure into 4646bis. 

>> It still contains "Latin transliterations of descriptions", without saying 
>> what Latin is,
 
> Do we need to provide a definition of the Latin script?

My definition is simple:  MES-1, optionally plus a few glyphs used on a
"popular" platform.  What's your definition, Latin-1 ?

>> why the subtag review list should create "transliterations" when the
>> source standard didn't bother for whatever reasons.
 
> The source (ISO) standards will always provide Latin-script 
> descriptions

Okay.  So what does the new MUSTard in the draft ?  Is it about the
variants or "registered languages", and why would anybody want say 
some fonipa transliteration in addition to the description(s) offered by
the requester ?  What's special with "Latn" in a broad Unicode sense,
why no Kore, Jpan, or Brai ?  For RFC 4646 we made sure that we 
have _no_ prejudice for Latn, and permit (in theory) all code points.

> We simply need to make sure we don't register 
> "Description: Тарашкевіца"

You hit an example that I can read, therefore I recall that the review
list managed this registration without a new MUST.

> Hopefully the advent of the UTF-8 Registry will put that to an end.

Apart from causing havoc for some users UTF-8 is still Unicode, and
we had that already in RFC 4646.  BTW, some weeks ago you said
that XML is not all.  With the advent of "ooXML" (valid or otherwise)
I'm confident that hex. NCRs will soon work everywhere.

>> It still contains the unused 5*8ALPHA "registered languages"
>> instead of reviving the good tradition of i-whatever tags
>> for this in the times of 639-3 likely unnecessary loophole.
 
> I don't believe there is any popular sympathy, let alone consensus, to 
> change this.  I wonder why you would call out Addison for not changing 
> it.

My list contained only one point wrt consensus, the disputed territories.
It was a summary of my objections + rationale.

> You guys can beat the maximum-theoretical-tag-length issue into the 
> ground if you wish.

Will do.  Actually not 31, it's 35 for  5*8( ALPHA ) registered languages.
 
>> Allegedly it's unclear that a subtag can be "undrepecated" if say (in 
>> theory) ISO 3166-1 revives FX.  Or rather Doug said that it's clearly
>> not allowed, IMO that would be a bug.
 
> I think it's extremely clear in 4646.  Whether that's a bug is another 
> question, one I think deserves serious discussion.  But we should be 
> careful about breaking our own stability promises, and refusing to 
> un-deprecate a subtag was a stability promise.

IIRC we discussed cases of splits later re-uniting again for RFC 4646,
e.g. a new incarnation of YU, or CS.  And I thought that we made sure 
that this will work as everybody would expect it.

>> It still allows "generic" variants without prefix, they're known to be 
>> cumbersome (fonipa + fonupa).
 
> I don't see how they're "cumbersome." 

The "most perverse tag" has two variants.  With fonipa or fonupa it's
in theory three, or even four if a pervert manages to use fonipa and
fonupa simultaneously.

Just an example, for 4646 we discussed generic north south westx
eastx and similar cases arriving at SHOULD NOT, after fonipa and
company I'm ready for MUST NOT.
 
> You're probably more likely to see a 5- to 8-letter registered 
> language subtag before you see an extension.  The barriers to
> creating an extension are just too high.

With a MUST NOT for generic variants folks might manage it.   If
more cases like fonipa + fonupa are identified maybe it will result
in the first extension.   Arguably better than more generic variants,
each extension can have its own rules.  It's hard to decide if 1996
and fonupa in the same tag could make sense or not, and what 
the best order should be.

 Frank



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