Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too?

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 01 Aug 2011 19:06:48 +0900

Hello Mark,

Many thanks for your quick answer.

On 2011/08/01 10:52, Mark Davis ☕ wrote:
> I'm glad you're submitting this; a thoughtful analysis, as I'd expect from
> you.
>
> The UTC will be discussing this during this week, but I thought I'd say a
> few things now.
>
> On the bidi algorithm issues:
>
>     - first, the committee approaches the UBA very carefully -- it has proven
>     to be quite sensitive, and any changes have to be done carefully. I expect
>     any actions at this meeting to still be in a proposal state. The earliest
>     possible point for any release is U6.1, which is in February. There are 2
>     F2F meetings before then.

Good to hear. I really think this needs time.

>     - we've seen a number of major companies extending or wanting to extend
>     the BIDI algorithm for display.
> http://unicode.org/reports/tr9/#HL3permits this, but what we really
> don't want to happen is for the extensions
>     to be incompatible. That's really what is driving this; and probably any
>     change would be in the form of a defined extension, which would have a more
>     or less strong recommendation (depending on what the committee decides). It
>     may be cast as 'experimental' -- we'll just have to see.

I understand that there is some pressure, and that it is better to let 
the pressure go into a channel than explode all over the place.

> On the feedback issue: One area where the ed committee has been moving to is
> using the Unicode forum, which provides for much nicer archival and
> searching than an email list.

The forum may work well, in particular if the mailing list archive isn't 
very good. I know that the W3C spent quite a bit of time on getting a 
rather usable archive, but it still has problems such as linking threads 
across months/quarters. The Unicode archive 
(http://www.unicode.org/mail-arch/unicode-ml/) is slightly better than 
the IETF archives because it's organized by month.

What would be really nice with the forum would be to have a (voluntary, 
of course) facility to get email notifications. Otherwise, one has to 
poll for new comments actively, with is really a big pain. Most bug 
trackers provide email notification, but I haven't found it in the 
forum. Maybe I overlooked something?

> We could do a lot more, and also make it clearer that we want discussion to
> go on via email and forum discussions, but then want specific proposals that
> sum up different viewpoints to be submitted for the committee.

That would be great. That's actually not that different from how the 
IETF works.

Another thing that I mentioned in my mail is that there is a need for 
coordination between the IETF, the W3C, and Unicode on this issue, so 
that we can have an overall idea of what needs to be done to address the 
overall problem and who will deal with what parts of the problem. If you 
can give us your take on this coordination issue, that would also be 
appreciated.

Regards,   Martin.

> Mark
> *— Il meglio è l’inimico del bene —*
>
>
> On Fri, Jul 29, 2011 at 03:35, "Martin J. Dürst"<[email-masked]>wrote:
>
>> [This is a copy of a comment that I submitted via the Unicode Review Form
>> and posted on the member-only Unicode mailing list. I'm sending it here to
>> have a public record, because this's the mailing list where most of the
>> discussion about this draft in the IETF happened, as far as I'm aware of.]
>>
>>
>> Context
>> =======
>>
>> I'm an individual Unicode member, but I'll paste this in to the reporting
>> form because that's easier. Please make a 'document' out of it (or more than
>> one, if that helps to better address the issues raised here). I apologize
>> for being late with my comments.
>>
>>
>> Substantive Comments
>> ====================
>>
>> On substance, I don't agree with every detail of what Jonathan Rosenne,
>> Behdad Esfahbod, Aharon Lanin and others have said, I agree with them in
>> general. If their documents/messages are not properly submitted, I include
>> them herewith by reference.
>>
>> The proposal is an enormous change in the Bidi algorithm, changing its
>> nature in huge ways. Whatever the details eventually may look like, it won't
>> be possible to get everything right in one step, and probably countless
>> tweaks will follow (not that they necessarily will make things better,
>> though). Also, dealing with IRIs will increase the appetite/pressure for
>> dealing with various other syntactical constructs in texts.
>>
>> The introduction of the new algorithm will create numerous compatibility
>> issues (and attack surfaces for phishing, the main thing the proposal tries
>> to address) for a long period of time. Given that the Unicode Consortium has
>> been working hard to address (compared to this issue) even extremely minor
>> compatibility issues re. IDNs in TR46, it's difficult for me to see how this
>> fits together.
>>
>>
>> Taking One Step Back
>> ====================
>>
>> As one of the first people involved with what's now called IDNs and IRIs, I
>> know that the problem of such Bidi identifiers is extremely hard. The IETF,
>> as the standards organization responsible for (Internationalized) Domain
>> Names and for URIs/IRIs, has taken some steps to address it (there's a Bidi
>> section in RFC 3987 (http://tools.ietf.org/html/**rfc3987#section-4<http://tools.ietf.org/html/rfc3987#section-4>),
>> and for IDNs, there is http://tools.ietf.org/html/**rfc5893<http://tools.ietf.org/html/rfc5893>
>> ).
>>
>> I don't think these are necessarily sufficient or anything. And I don't
>> think that the proposal at hand is completely useless. However, the proposal
>> touches many aspects (e.g. recognizing IRIs in plain text,...) that are
>> vastly more adequate for definition in another standards organization or
>> where a high-bandwidth coordination with such an organization is crucial
>> (roughly speaking, first on feasibility of various approaches, then on how
>> to split up the work between the relevant organizations, then on
>> coordination in details.) Without such a step back and high-bandwidth
>> coordination, there is a strong chance of producing something highly
>> suboptimal.
>>
>> (Side comment on  detail: It would be better for the document to use
>> something like
>> http://tools.ietf.org/html/**rfc3987#section-2.2<http://tools.ietf.org/html/rfc3987#section-2.2>rather than the totally obscure and no longer maintained
>> http://rfc-ref.org/RFC-TEXTS/**3987/chapter2.html<http://rfc-ref.org/RFC-TEXTS/3987/chapter2.html>,
>> in the same way the Unicode Consortium would probably prefer to have its own
>> Web site referenced for its work rather than some third-party Web site.)
>>
>>
>> Taking Another Step Back
>> ========================
>>
>> I mention 'high-bandwidth' above. The Unicode "Public Review" process is
>> definitely not suited for this. It has various problems:
>> - The announcements are often very short, formalistic, and cryptic
>>   (I can dig up examples if needed.)
>> - The announcements go to a single list; forwarding them to other
>>   relevant places is mostly a matter of chance. This should be improved
>>   by identifying the relevant parties and contacting them directly.
>> - To find the Web form, one has to traverse several links.
>> - The submission is via a Web form, without any confirmation that the
>>   comment has been received.
>> - The space for comments on the form is very small.
>> - There is no way to make a comment public (except for publishing it
>>   separately).
>> - There is no official response to a comment submitted to the Web form.
>>   One finds out about what happened by chance or not at all.
>>   (compare to W3C process, where WGs are required to address each
>>    comment formally, and most of them including the responses are
>>    public)
>> - The turnaround is slow. Decisions get made (or postponed) at UTCs
>>   only.
>> Overall, from an outsider's point of view, the review process and the
>> review form feel like a needle's ear connected to a black hole.
>>
>> [I very much understand that part of the reason the UTC works the way it
>> works is because of its collaboration with ISO/IEC committees. And I don't
>> think any other standards organization has a perfect process. But what's
>> appropriate for one part of the UTCs work may not be appropriate for other
>> parts of its work (such as the matter at hand).]
>>
>>
>>
>> Conclusion
>> ==========
>>
>> I herewith very strongly recommend that the UTC, besides using the upcoming
>> meeting to advance discussion on the technical issues that the proposal
>> raises,
>> a) Postpone the decision to adopt any of the proposed changes, independent
>> of details, until such time as point b) is implemented and executed.
>> b) Swiftly take the necessary steps for a much better, high-bandwith
>> coordination of this topic and the various issues it encompasses, both using
>> the existing liaison mechanism and using public discussion on an appropriate
>> forum (e.g. one of the relevant IETF mailing lists (idna/eai/iri)).
>> c) Seriously work on improving the process for soliciting and addressing
>> comments from the public and relevant stakeholders.
>>
>>
>> Regards,    Martin.
>> ______________________________**_________________
>>
>> IMA mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/ima<https://www.ietf.org/mailman/listinfo/ima>
>>
>

---

From: Mark Davis ☕ <[email-masked]>
Date: Sun, 31 Jul 2011 18:52:23 -0700

Mark