Re: Last Call: 'Tags for Identifying Languages' to BCP

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)

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