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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf