Re: Another issue: quoting

Roy Badami <[email protected]> wrote:

> Quoting in local parts is a messy construct.

Yes.  Quoting in general is inherently messy, and the quoting in message
headers is no exception.

> One of the problems with the 822 specification is that localparts
> aren't just a sequence of characters, with quoting being just a
> transport encoding.  Localparts are a sequence of tokens, namely atoms
> and dots.
>
> By way of example, it seems to me that the RFC822 parse of the
> following two localparts is distinct, and as a result they could
> validly refer to distinct mailboxes:
> 
>     roy.badami
>     "roy.badami"

I had these exact same concerns two months ago, and careful reading of
RFC 822 clarified some things.

D. J. Bernstein has already pointed to section 3.4.4 of RFC 822, which
explains that the backslashes used to quote the next character, and the
quotation marks around quoted-strings, are not part of the data, and
should not be retained outside a message-header context.

As for the atom/dot structure, section 6.2.4 explains that it is not
significant.  So in your example above, roy.badami and "roy.badami" do
in fact refer to the same mailbox, even though they parse differently.

> In fact, the definition of "dequoted local part" in the base document
> is problematic as it stands, because in 822 there isn't any such
> thing.

I don't see what's wrong with defining a new term.

Actually, the definition of "dequoted local part" is merely giving a
name to a concept described (but not named) in the last paragraph of
section 3.4.4 of RFC 822.

AMC