I'll have to check this, but it certainly was not intentional in
the DRUMS work. I can see lots of reasons for getting rid of
the other control characters, but none at all for retaining them
and prohibiting space.
--On Sunday, 30 December, 2007 00:01 +0300 Alexey Melnikov
The IESG wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'Simple Mail Transfer Protocol '
<draft-klensin-rfc2821bis-06.txt> as a Draft Standard
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send
substantive comments to the ietf(_at_)ietf(_dot_)org mailing lists by
2007-12-24. Exceptionally, comments may be sent to
iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
I know that the IETF LC has ended, but I believe the issue is
important enough and hopefully will be addressed.
My co-worker has pointed out that RFC 821 allowed for space
characters (0x20) in local part of email addresses, but RFC
2821 and 2821bis don't allow for that:
Local-part = Dot-string / Quoted-string
; MAY be case-sensitive
Dot-string = Atom *("." Atom)
Atom = 1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
where qcontent is defined in RFC 2822 as:
qtext = NO-WS-CTL / ; Non white space
%d33 / ; The rest of the
%d35-91 / ; characters not
%d93-126 ; or the quote
qcontent = qtext / quoted-pair
NO-WS-CTL = %d1-8 / ; US-ASCII control
%d11 / ; that do not include
%d12 / ; carriage return,
%d14-31 / ; and white space
Was this change between RFC 821 and RFC 2821 intentional?
Prohibition of spaces in quoted parts breaks gatewaying
to/from X.400 (MIXER, RFC 2156).