These are two well-known serious flaws in EAI and URLs; there is no useful
syntactic limit on what is in the query part of a URL or on the local part
of an email address that would allow their boundaries to be detected in
plaintext.
No use complaining about them, because people are concerned with backwards
compatibility, and wouldn't change the underlying specs.
That being true, I wish that industry could come to consensus about
requiring everything outside of a well-defined, backwards-compatible set of
characters to be expressed as UTF-8 percent-escaped characters in these
fields when they are expressed as plaintext. (Something like XID_Continue ±
exceptions.) That would allow for unambiguous parsing in plaintext.
Mark <https://google.com/+MarkDavis>
*
*
*— Il meglio è l’inimico del bene —*
**
On Thu, Oct 31, 2013 at 8:37 PM, Philippe Verdy <verdy_p_at_wanadoo.fr> wrote:
> How can it "suarprisingly work" if you need to safely embed an
> email address as an URI in a plain text document ? Yes there's way to worak
> with the IDNA part, but the local part is a challenge, that will require
> (to make it work) that the mail server will accept several aliased account
> names, depending on the document in which the address was embedded and
> encoded before being dereferenced and used to send mails.
>
> There's no easy way to embed the local part in plain-text when it can be
> arbitrary sequences of bytes in the non-ASCII range, whose encoding in the
> target domain name is unpredictable without first querying the MX server
> for that domain for this info, or without retrying sending mails with
> several guesses: these guesses with retries may cause privacy issues for
> the legitimate owner of non-ASCII email accounts (another reasons for using
> email of verification/confirmation of the owner, before sending him private
> messages).
>
> 2013/10/31 Shawn Steele <Shawn.Steele_at_microsoft.com>
>
>> I think that’s true for non-ASCII non-EAI locale parts as well. It’s
>> so inconsistent its surprising when it works?
>>
>
>
Received on Fri Nov 01 2013 - 03:41:47 CDT
This archive was generated by hypermail 2.2.0 : Fri Nov 01 2013 - 03:41:49 CDT