Re: [I18ndir] Hooks - and other non-decomposing diacritics

[John C Klensin <[e-mail]>]

--On Monday, February 18, 2019 01:08 -0800 "Asmus Freytag (c)"
<[e-mail]> wrote:

>...
> However, category Virama, and category Vowel_Dependent do need
> context rules (otherwise you get structurally unsound labels).
> 
> So, you could give them a a category:
> RESTRICTED_CONTEXT_RECOMMENDED
> 
> and likewise for all the other ISC values.
> 
> This works as long as your categories are reasonably generic
> and do not try to delve into "which context rules" would be
> recommended, because that's highly script dependent. We just
> know that you shouldn't allow them unrestricted by default.

But there are no code points, at least no code points outside
the ASCII repertoire, that are "unrestricted by default".
Every code point classified as PVALID and every label containing
code points that are valid by application of appropriate
contextual rules, is _still_ restricted by the rule that
registries (at all levels of the DNS) are required to understand
what they are doing and to be responsible about it.  If we want
to give (or point to) additional advice and can figure out how
to do that, fine, but where the specification is today isn't
"unrestricted by default" and setting that up as a strawman does
not, IMO, help us make progress.

If this were the only issue and we concluded IDNA2008 should not
go further in the direction of advice than it does today, then
the best way to get draft-faltstrom-unicode11 published as
quickly as possible (see below), might include:

* Get draft-klensin-idna-rfc5891bis into shape and ready for
publication.  I think it would require a bit of work to be used
this way.  In particular, make sure it says what we want it to
say about "troublesome".

* Persuade ICANN to release "troublesome" as part of general
advice to registries, especially at the second level but for the
use of anyone who felt like using it.   ICANN's doing that would
avoid IETF constraints about informed community consensus, code
point by code point analysis and listings, and long-term
concerns about maintenance... and would almost certainly be a
lot faster than trying to develop IETF consensus about those
issues.

* Include text in draft-faltstrom-unicode11 that stresses the
upper limit nature of IDNA2008, mentions the requirement that
registries impose their own restrictions and be careful about
it, and point to draft-klensin-idna-rfc5891bis for further
discussion.   If there is really urgency about
draft-faltstrom-unicode11 (see below) I can see ways to make
that reference non-normative so it would not hold up publication
_if_ we were quite confident we were actually going to finish
and publish draft-klensin-idna-rfc5891bis.

  --or-- 

we could try to figure out if the IETF wants to go into the
recommendations business, make a recommendation about a WG or
other mechanism to accomplish that, etc.  However a good idea
that might be, nothing that has occurred in either the last
several months (before and during IETF 102) or the last four and
a half years (since the first posted version of
draft-klensin-idna-5892upd-unicode70) has given me much hope
that it would be quick.

_However_

* I still haven't seen an explanation of why publication of
draft-faltstrom-unicode11 is urgent or who is pushing for it
other than the equivalent of "we've screwed around long enough".
That isn't much of an explanation because we have screwed around
long enough with a fairly long list of i18n documents, none of
which have been singled out in this way.  Some of them haven't
even been mentioned in this discussion including the early 2014
attempt to revise the IETF character set and languages policy
document (draft-sullivan-rfc2277-bis-00).

* The above does not address issues raised and unresolved from
that list of other documents, just the relationship between the
present I-D, "troublesome", and registry responsibility.

best,
   john