Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Aug 2005 22:25:31 +0200

Bruce Lilly wrote:

> While there is some mention of this issue in the document
> under discussion, its treatment and resolving the underlying
> issue in a manner that would minimize the problems are
> lacking.

That's a last call, if you have better ideas than those in the
draft speak up.  Your Content-Script idea is good, but won't
help e.g. in encoded words (2047+2231).  We definitely tried
to minimize especially this problem.  

This is a ready-for-Bruce's-review draft as far as I can judge
this, but for obvious reasons only you can really judge it. ;-)

> Addressing the language range issue is not a WG work item
> and, unfortunately, the algorithm issue is scheduled to be a
> later work item than the registry issue.

Only my personal view of course, but the matching draft offers
a syntactical form for ranges, and the Suppress-Script in the
registry provides for backwards compatibility where possible.

> it is essential that such negotiation issues be considered
> carefully before specifying the format of tags.
> Unfortunately, that has not been done

IBTD, we considered the script issues.  Anything else is as
good or bad as it is with 3066 - some minor problems fixed of
course, if ISO 3166-1 pulls another CS 3066bis will handle it
better than 3066 (no potential worldwide retagging confusion).

> the WG product lacks the "particular care" expected of BCP
> documents (RFC 2026).

IBTD as far as scripts are concerned.

> it appears that management of WG participant conduct has been
> rather lax

IBTD, the WG Chairs and the responsible AD did a very good job.

> as it stands, the document cannot be evaluated for soundness
> of the tag syntax design in the absence of a specification
> that addresses negotiation issues (in a backwards-compatible
> manner with the existing negotiation mechanisms (viz. MIME
> Content- and Accept- fields and feature/filter negotiation).

IBTD, see above.  Your idea to split tag and registry syntax
from all procedural aspects of tag registration is possible,
but you get the same effect by "ignore the procedural stuff
in chapter 3" (= about 14 of the 60 pages in the draft).

> Revision to move the syntax specification to a separate
> document, as mentioned above, would permit evaluation of the
> registration procedures per se

You can also read chapter 3 per se, the mentioned 14 pages
plus 3.1 as introduction (5 pages, format of the registry).

I'm not violently against splitting the document, but it's
IMHO unnecessary.
                  Bye, Frank (also posted on the LTRU list)

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 31 Aug 2005 07:17:01 +0200

Bruce Lilly wrote:
 
> Encoded-words have several characteristics, one of which is
> limited length (in octets).  That has two implications w.r.t.
> script:

> 1. specifying script explicitly is unnecessary; it can be
> determined from the charset (always specified in an
> encoded-word) and the specific octets of the encoded text
> (ISO-8859-1 is latin script, KOI8 is Cyrillic, etc.).

It's not that easy for UTF-8.  We need the ugly scripts after
Unicode replaced the old charsets (the "implicit script" info
of most legacy charsets).  Where that's irrelevant you can of
course use language tags without script, the draft encourages
"taggers" that more is not always better, quite the contrary.

> 2. an encoded-word has limited space available.

[...snipped...]  Yes, we calculated "the most perverse tag" in
all dimensions especially for 2231, I knew that you would kill
the draft otherwise... ;-)  Compare figure 7 in chapter 4.3.1.

> without a concrete specification for negotiation, it is not
> possible to fully assess the proposed syntax changes.

Maybe you can convince the PTB to delay the "last call" until
the matching draft is ready, but I doubt it.  And I disagree
that it's impossible to judge the "data structure" (tags) now,
the syntax is rather simple.

For a general idea what the matching draft probably will be
you could read draft-ietf-ltru-matching-03.
 
>> the WG Chairs and the responsible AD did a very good job.
> As an affected party, I disagree.

Then let's agree to disagree and / or be more specific:  3934
is rather new, and it was used, all parts of it incl. appeal.

IMNSHO it would be desastrous to abuse RfC 3934 as some kind
of killfiling-by-rough-consensus.

                       Bye, Frank