Re: Question: Fullwidth double-quote and fullwidth backslash

   But local parts that require quotation are fundamentally more difficult,
   even with today's ASCII local parts.  Although there is a standard
   quotation mechanism for local parts in message headers and SMTP
   commands, there is no standard quotation mechanism for user interfaces.
   Some user agents might copy the user input directly into the header
   (relying on the user to supply any needed quotation), others might
   assume the user input is literal and add more quotation if needed,
   and others might allow users to use some other quotation mechanism
   altogether, which the agent undoes before applying the 822-style
   quotation.  There's no standard, so we can't expect local parts
   requiring quotation to be mailable and paste-able, even in today's ASCII
   world.  It would be a wasted effort to try to standardize the Unicode
   variants of non-standard ASCII metacharacters.

I'm not sure I follow where the user interface issues come in.

As I see it, an RFC-822 address (in the form in which it appears in
headers) is regarded by most users as an opaque string of characters
which they must copy verbatim in order to reach the recipient.  Any
quoting that is needed in an address will already be present when the
address is given to the end user (eg out of band) and will by typed in
literally by the user into the MUA.  Most users probably won't even
explicitly know that quoting is going on, they'll just notice that
it's a slightly ususual address that they've been given.

The only thing a user (who is not familliar with the RFCs) will do
with this opaque string is copy it or transcribe it.  The string they
are given to transcribe may contain a number of classes of characters:
ascii characters, international characters, dots, at-sign,
double-quote and backslash.

IDNA already ensures that if the user accidentally mis-transcribes
normal alphanumeric characters on the RHS as full-width characters
this won't break the address, and I imagine that IMAA will involve a
similar normalization on the LHS.

IDNA already ensures that if the user accidentally mis-transcribes dot
on the RHS as full width dot, this will work.

IMAA proposes ensureing that if the user accidentally mis-transcribes
the at-sign as a full-width at-sign, the address will still work.

So if IMAA chooses not to allow for users mis-transcribing backslash
and double-quote as full-width characters, these will end up being the
*only* ASCII characters in an address (as presented to the users) that
are sensitive to full-width/half-width transcription issues.

I feel that the group should consider attempting to either solve or
avoid the transcription problem by doing one of the following:

either (1) modify the dequoting mechanism to recognize full-width-backslash,
	   full-width double-quote, and any other similar characters that
	   are considered appropriate,

    or (2) declare that an IMA that contains non-ASCII characters SHOULD NOT
	   use quoting.

I don't have a strong preference one way or the other between the
above options.

	   -roy