Re: Question: Fullwidth double-quote and fullwidth backslash

A couple months ago I wrote:

> Hmmm, the motivation for requiring recognition of fullwidth
> metacharacters was consistency with the requirement to recognize
> fullwidth at-sign, but now that I think about it, IDNA doesn't have
> that sort of consistency.  For example, an extended DNS master-file
> format might allow non-ASCII domain names, and IDNA would require that
> fullwidth dots be recognized as dots in such names, but it does not
> require that fullwidth backslash be recognized as beginning an escape
> sequence.  That's a private interface issue for the designer of the
> extended master-file format.

Roy Badami <[email protected]> replied:

> Ordinary users never encounter zone files, so it is reasonable to
> leave that as a private issue for the name server implementor.
>
> Ordinary users deal with RFC 822/2822 addresses (or at least
> addr-specs) every day, and such constructs contain a variety of
> metacharacters including (sometimes) quoting.

Do ordinary users deal with quoting in local parts?  The RFC
2821/2822 local part syntaxes allow metacharacters (double-quotes and
backslashes), but do local parts seen by regular users ever contain
those characters?  I can't remember ever encountering a real local part
that needed a double-quote or backslash.

Including support for fullwidth metacharacters in IMAA adds complexity
to the spec (and therefore to implementations), but how much benefit
would there be to end users?  In practice, I think there would be zero
benefit.

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

The current draft tries to do (1), but I am now leaning toward (2), in
order to simplify the spec.  I could live with SHOULD NOT, but a less
strict warning might suffice:

    Local parts that need quoting can be difficult for humans to use.
    This is already true for ASCII local parts, and is even more true
    for IMA local parts.  It is inadvisable to create such local parts
    if they are to be used by humans.

The quoting facilities would still exist for IMAs, but the correct ASCII
metacharacters would have to be used, not the fullwidth forms.  This
would not be a problem for software such as mail gateways and robots,
which are the only likely "users" of the quoting facilities.

(I think the quoting facilities were originally included in the syntax
to allow for the needs of gateways between internet mail and other mail
systems.  I doubt the quoting facilities would have been included if
internet mail had been designed to be the only mail system, which is
what it is becoming.)

AMC