[RFCI-Discuss] FYI: 2821bis and 2822upd

[Derek J. Balling]

Is there somewhere that diffs 2821/2822 against 2821bis/2822upd in a 
nice easy to follow fashion (something like the way 2821bis-03 can be 
diffed against -02 online would be sweet).

Cheers,
D




Frank Ellermann wrote:
> Hi, there's a fresh attempt in the IETF to promote RFC 2821 (SMTP)
> and 2822 (mail) to "draft standards", the second step in the IETF
> standards process.  Full standard (STD) is the third step, at the
> moment RFC 821 belongs to STD 10, and RFC 822 is STD 11.
> 
> The actual drafts 2821bis-03 and 2822upd-01 are available at
> <http://tools.ietf.org/html/draft-klensin-rfc2821bis> and
> <http://tools.ietf.org/html/draft-resnick-2822upd>
> 
> The drafts are discussed on the traditional ietf-smtp and ietf-822
> lists shown on <https://datatracker.ietf.org/public/nwg_list.cgi>:
> 
> <http://www.imc.org/ietf-smtp/> and <http://www.imc.org/ietf-822/>
> The lists are also available on GMaNe, see <http://news.gmane.org>
> 
> If you for some reason or another feel that something with mail is
> not as it should be, and if you're willing to review these drafts,
> then now would be a good time to chime in.
> 
> Example for folks interested in Sender-ID, the 2822upd draft still
> says that Resent-* header fields MUST NOT be used in "other such
> automatic actions on messages".
> 
> Example for folks interested in misdirected bounces, the 2821bis
> draft still favours accept instead of reject, and mandates to send
> non-delivery reports to the originator as indicated in the reverse
> path.
> 
> Example for folks interested in NetNews, the 2822upd draft still
> allows control characters (NO-WS-CTL) and unnecessary "quoted-
> pairs" (backslash escapes) in Message-IDs.
> 
> Example for folks interested in SPF, the 2821bis draft still does
> not clearly admit that the RFC 821 alias-forwarding to 3rd parties
> was designed for an SMTP with "return routes", and whatever that
> was, it was killed by RFC 1123 together with the "source routes".
> 
> So there are some "minor" points in these drafts which could be
> relevant for some readers of this list.  Please help to get it
> right this time.  Don't let them get away with "it's as it is, and
> we can't change it because a promotion to 'draft standard' doesn't
> allow serious fixes."  RFC 3986 and RFC 3629 are examples where
> serious fixes worked, and if all else fails a fixed new "proposed
> standard" is better than any broken by design "draft standard".
> 
> Frank
> 
> _______________________________________________
> RFCI-Discuss mailing list
> RFCI-Discuss at lists.megacity.org
> http://lists.megacity.org/mailman/listinfo/rfci-discuss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.megacity.org/pipermail/rfci-discuss/attachments/20070429/27bf6716/attachment.bin