Re: Bidi issues

I wrote:

 > > I'm not sure there is a compelling reason, but there are many other
 > > possibilities.  Two that immediately spring to mind:
 > >
 > >  * Segment only on dot.  This means that the rules for what is allowed
 > >    on the LHS and RHS are the same.

Adam Costello wrote:

 > Recall that the motivation for the current segmentation is to
 > support arbitrary existing structure conventions.  [...]  You
 > recently pointed out a hole in this architecture: The bidi check is
 > currently applied to the entire local part, which means that even
 > if foo is valid, owner-foo might be invalid.  [...]

I agree that supporting owner-FOO would be desirable, and I've argued
for this is that past.

Mainly I was just throwing possibilities around.  This whole issue is
much messier than I'd first appreciated.

The problem with segmenting is that although it allows mixed LTR/RTL
labels, it results in much stronger restrictions on RTL labels, since
each RTL segment must now begin and end with an RTL character.  As
previously discussed, A1-2B becomes illegal, for no obviously good
reason, if we choose to segment on hyphen (all examples in logical
order unless otherwise indicated).

More significantly, I think, any approach based on the current
stringprep restrictions prevents an RTL localpart from ending with
digits.  With existing (ASCII) localparts, it is common practice to a
append a number to the user's name or initials in order to
disambiguate users with the same initials or names.  The address
[email protected] is completely unambiguous, but would be disallowed by any
bidi restrictions based on stringprep, for no evidently good reason.

On the other hand, the address [email protected] is ambiguous when rendered,
but would be perfectly legal according to any bidi restrictions based
on stringprep.  (And it's difficult to see how this could ever be
avoided, since some valid IDNs are intrinsically ambiguous.)

I'm tending towards the viewpoint that bidi restrictions on the
localpart (at least those we've considered) achieve too little in
terms of avoiding ambiguity in IMAs, and end up doing too much harm in
terms of disallowing far too many useful constructs.

What ever is decided, users of IMAs (and IDNs and IRIs) will need to
take great care in allocating these identifiers in order to avoid
ambiguity (and subsequent confusion and risk of impersonation).

I started writing some words in reply to this analysing the various
types of ambiguity that can occur in bidi identifiers, recommending
how to avoid them, but they ended up getting rather longer than I'd
initially expected :)

Hopefully I should be able to post some (rough) analysis of this in
the next week or two.

 > > I think there should be a warning in IDNA.
 > >
 > > But is there any scope for adding such a warning to IDNA in the near
 > > future, now that the IDN WG has been disbanded?
 > 
 > The IDNA RFCs will be reissued when they advance to Draft Standard,
 > sometime after multiple interoperable implementations are demonstrated.
 > We already have lists of editorial clarifications to make at that time.
 > I doubt there would be any difficulty in adding a helpful warning about
 > tricky cases.  Adding a new SHOULD recommendation would be a technical
 > change though; I don't know the policy on that.

On further consideration, I see that this isn't a protocol issue, so
I'm now less sure that the IDNA specs need to make such
recommendation.  This is really an administrative issue, and if I
understand correctly, would more appropriately be addressed in a BCP.
But I admit to being somewhat unclear on what belongs in a standards
track document, and what belongs in a BCP.

As far as the current IMAA issue goes, my current feeling is that
users of RTL languages would be better served by a BCP giving advice
on how to avoid the issue, than by restrictions which prevent the use
of many safe IMAs without fully solving the problem.

	-roy