Alexey Melnikov wrote:
Ken Murchison wrote:
I was just asked what would happen if this extension is used on an
address such as:
user+detail1+detail2(_at_)canonicaldomain(_dot_)dom
I'm proposing adding the following text to the draft:
"NOTE: If the separator character occurs more than once in the
local-part,
then the address SHOULD be split at the left-most separator."
Does this seem sufficient? Should this be a MUST instead of a SHOULD?
Any other thoughts?
IMHO, this should be MUST and it is sufficient.
I concur, and since brought this all up, that means there's no
disagreement. :)
However, regarding Michael's NUL comment:
Michael, I believe that we are not talking about the same thing, and
there's nothing to worry about, and no change to the RFC needed. The
null key ("") that I was referring to, and that the subadress extension
refers to is the empty string. Sematically, it's a string of 0
characters, not a string with one character with the value 0. (Except
that it might be stored such that it looks that way - in languages such
as C, it might be stored as a pointer to a an array of 0 characters
followed by the value 0.)
The NUL (ASCII 0) referred to in 2.4.2 of the RFC is a character with
the value 0, often used in languages such as C to indicate the end of a
string, and therefore cannot be part of a string (which is probably why
it is forbidden by the RFC.) You'l note that the RFC separately refers
to the null key (""); certainly these are different things. Cool?
Finally, I noticed that 2.7.1 of the RFC states in part:
The null key ("") is contained in all values.
That answers question 4. There's just a bug in the implementation I use;
smooth sailing for the subaddress draft.
Therefore there IS a way to match the null key:
header :contains "Subject" ""
should return true for all mail with a Subject header, including an
extant but empty one.