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

["Asmus Freytag (c)" <[e-mail]>]

On 2/18/2019 3:56 PM, John C Klensin wrote:
>
> --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".

By "unrestricted by default" I mean an IDN table where this code point 
simply
appears in the list of allowed code points for the registry without any
LGR WLE or context rules or without being limited to a sequence.

I'm sorry if you misconstrued this.

> 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.

Yes, no argument.

I was addressing the case where registries simply do not add any
restrictions of their own, even though they most probably should have.


>    If we want
> to give (or point to) additional advice and can figure out how
> to do that, fine,

good (both alternatives)


>
> 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".

Or about "a framework for advice to registries on label generation rules 
". (*)

That's how I am thinking about this.

(*) it's not just character selection.

>
> * 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.

I think we should still have a bit more of a discussion of what I call the
"framework" -- this has more to do with the types of actions that would
be appropriate and the types of character categories.

Also, about the way all of this can be related to other Unicode properties.

Even if we end up pushing this as a request to ICANN, it would help if we
got a better idea of what we would like to see. It can't just be to ask 
ICANN
to "publish advice to registries".

>
> * 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.

That would work for me.


>
>    --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.


Understand your reasoning for being cautious - but I thought with the
i18ndir we have at least the start of an attempt for IETF to become serious
about issues like this.

A./

PS: about "urgency" - as it stands 5892 applies to all of Unicode. With each
version, the "automatic" propagation of properties will become more of
the standard way to handle Unicode and the IANA parameters will become
less relevant.

You could say, as long as Patrik's draft doesn't contain any new exceptions
we don't need it. Not sure I buy that.



>
> _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
>
>
>