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

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

[Sorry, that mail went off before it was written. Here's the actually 
intended content.]

On 2018/12/10 18:11, Martin J. Dürst wrote:
> 
> 
> 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.

For the record, I totally agree with Larry's statement that the reason 
for the WG to not advance was a lack of activity. However, "never had 
any disagreements" is probably an understatement.


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

If you know about any specific example where this is actually the case, 
please tell us. As coauthors of the current mailto: RFC 
(https://tools.ietf.org/html/rfc6068), we should be able to fix this. 
The usual fix would be to say in the mailto: spec that the actual 
address has to confirm to the limits of the EAI specs.

Please note that I plan to reissue RFC 6068 when we can officially 
submit drafts including non-ASCII characters. The purpose will be two-fold.

First, to have the examples with the real characters, so that we can 
eliminate one level of escaping (we already have to deal with escaping 
rules in email addresses and in IRIs/URIs, and so it's very helpful if 
we can discard the additional escaping needed to represent non-ASCII in 
ASCII-only RFCs).

Second, we actually currently don't refer to EAI. Percent-encoding in 
the local part is currently only constrained as follows: "When a
<local-part> containing non-ASCII characters will be used to compose a 
message, the <local-part> MUST be transformed to conform to whatever 
encoding may be defined in a future specification for the 
internationalization of email addresses.". That future has already 
arrived (spec-wise) and is arriving implementation-wise, so I plan to 
change this oblique reference to an actual reference.

All of the above work is independent of the draft under discussion 
currently, and so Patrik's draft should proceed, with wording 
improvements where necessary.

Regards,   Martin.