Re: [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

[Martin J. Dürst <[e-mail]>]

On 2018/12/10 08:45, Larry Masinter wrote:
> The IRI working group, which I take responsibility for starting, never had
> any disagreements, it just suffered that there was not enough activity.
> 
>> Not such where you are headed.  First of all, "Unicode name" has been the
>> source of a huge amount of confusion caused in part because many of those
>> who use that and similar terms seem to think "Unicode" is an appropriate
>> synonym for "non-ASCII".
> 
> Sure, but you knew what I meant.
> 
>> Second, the rules for email addresses are very clear in the
>> SMTPUTF8 specs.  Probably wrong (and I hope to get to that as soon as we
>> get the issues with draft-faltstrom-unicode11 and the Directorate
> questions
>> nailed down), but very clear.  There is also existing IETF guidance for
> other
>> sorts of name-like things in the PRECIS Identifier class and for another,
>> possibly overlapping, group of identifiers in UAX#31.
> 
> All of these disjoint rules are likely to get out of sync. E.g. the  rules
> for email addresses don't match the rules for mailto: URLs.
> For not very good reasons.
> 
>> Asmus has identified the work that is going on to provide at least a
>> framework for narrowing choices beyond that list, especially when one can
>> identify a particular target audience.
> 
> Yes, the work is fine, important, and valuable. But the applicability needs
> to be extended. From the general perspective of choosing domain names to use
> in email addresses and URLs, the criteria can be expressed operationally,
> and simply as "don't choose names that can't be transcribed easily by your
> target audience" and then point to Asmus work for a detailed analysis of
> reasons why some sequences might have some difficulty.
> 
> But it is easy transcription that was the original requirement for URLs, and
> based on several use cases. If you want IRIs to support those use cases,
> you'll need a spec that defines the rules for the URLs what will survive
> transcription.
> 
> 
>   
>> As I'm certain you remember, the IETF had a WG that was, among other
>> things, supposed to update RFC 3987 but that essentially could not reach
>> consensus and gave up after identifying multiple
>> problems with that spec.   Perhaps we should have moved it to
>> Historic or placed it in a Not Recommended category as a result of that --
>> certainly the language of RFC 2026 would strongly support such an action
>> when there are known technical defects and we don't have a plan for moving
>> forward, but there doesn't seem to have been sufficient energy and
>> consensus to take that action either.
>>
>> So, other than second-guessing work that is supposedly already complete,
>> what do you have in mind?  And when do you expect to get I-Ds posted?
>>
>>   best,
>>      john
>>
>>
>> --On Sunday, December 9, 2018 13:55 -0800 Larry Masinter <[e-mail]>
>> wrote:
>>
>>> I think we're looking at the problem from different ends of the
>>> telescope.
>>>
>>>
>>>
>>> I'm concerned with giving guidance to the use of Unicode in other
>>> naming contexts, including URLs.
>>>
>>> I think we should extend the advice to anyone assigning a "Unicode
>>> name" e.g., email addresses social media handles.
>>>
>>>
>>>
>>> In particular, the  IRI document RFC3987 needs update to align its
>>> recommendations with IDNA and the WHATWG URL "living standard"
>> (which
>>> mainly neglects giving any advice at all
>>> the those choosing URLs.)
>>>
>>>
>>
>>
>>
> 
> 
> _______________________________________________
> i18nRP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i18nrp
> .
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan