On Tue April 5 2005 15:30, Internet-Drafts(_at_)ietf(_dot_)org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Ncc in Mail Header
Author(s) : A. Sankar
Filename : draft-arun-ncc-smtp-02.txt
Pages : 4
Date : 2005-4-5
This draft presents a mechanism to simplify one of the cumbersome
aspects of mailing, when one needs to send mails only to a subset of
mail-ids from an alias [ALIAS] . The basic intention is only to minimize
the complication and difficulty of a mail user when a mail needs to be
sent to n - m mail IDs i.e. send it to a group Id of n and exclude m
from the alias [ALIAS] list.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-02.txt
As the draft lacks any indication of where discussion should take
place, I'm sending these comments to the author and the IETF discussion
list, with informational copies to the ietf-822 and ietf-smtp lists.
General comments:
The "draft" fails to conform to requirements as specified in
http://www.ietf.org/ID-Checklist.html and
http://www.ietf.org/ietf/1id-guidelines.html. Among the problems
detected by "idnits" are:
* The document seems to lack an IANA Considerations section.
* The document seems to lack separate sections for Informative/Normative
References.
Checking conformance with RFC 3978/3979 boilerplate...
the boilerplate looks good.
(But only for now: the document uses RFC 3667 boilerplate instead of RFC
3978 boilerplate, and after 6 May 2005, submission of drafts with RFC 3667
boilerplate will not be accepted.)
[...]
* There are 3 instances of too long lines in the document, the longest one
being 4 characters in excess of 72.
* There is 1 instance of lines with control characters in the document.
[...]
- The page length should not exceed 58 lines per page, but there was 3 longer
pages, the longest (page 1) being 59 lines
- It seems as if not all pages are separated by form feeds - found 0 form
feeds but 4 pages
A spelling check would have proved beneficial; among spelling errors
detected are:
Implimentations
Updations
extention
implimented
recpect
The draft uses unconventional terminology, e.g. "a mail" rather than
"a message".
The draft conflates mailing lists and aliases, which are distinct [RFC
2821 sect. 3.10].
As far as I can tell, the draft topic seems related to a proposal
discussed some time ago on the ietf-822 mailing list:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12244
http://www.imc.org/ietf-822/mail-archive/msg04346.html
The author should probably review the content of that discussion.
The draft lacks ABNF, header field registration template (RFC 3864,
a.k.a. BCP 90), detailed discussion of what appears to be a proposal
for an ESMTP extension keyword, and (as noted by idnits) a mandatory
IANA Considerations section. The author is referred to the following
for a treatise on the sort of items that should be addressed for the
message header field portion of his draft; the SMTP extension needs to
be given some thought also:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12673
Section 6 of the draft makes improper use of RFC 2119 terms:
The Ncc option MAY not be implemented in all Mail Servers.
This SHOULD not affect the servers that have implemented Ncc.
It is curious that the draft references RFC 2821 (the Standards Track
successor to RFC 821), but RFC 822 rather than 2822.
The most serious problems with the draft proposal result from confusing
message delivery with message content. Message content -- including the
message header and particularly the Originator fields {RFC 2822 sect.
3.6.2] -- is not supposed to be modified except by gateways [RFC 2821
sect. 2.3.8]; even examination of message content is discouraged [RFC
2821 section 3.3] and modification is not permitted by relays. The
draft seeks to require relays to modify message content in violation of
long-standing architectural principles. The draft also implies
comparison of arbitrary mailboxes by hosts other then those which are
administrative for the mailbox domain; e.g. a mail relay at example.edu
is unable to determine whether or not FOO(_at_)example(_dot_)com is equivalent
to
foo(_at_)example(_dot_)com -- local parts may only be interpreted at hosts which
are authoritative for the domain. The draft would also require relays
to alter the SMTP envelope (RCPT TO) based on message header field
content. The draft suggests that message Originator fields [RFC 2822
sect. 3.6.2] should be modified by relays -- this is known as
"forgery" and is generally considered bad practice.
There is another work in progress that the draft author should be
acquainted with:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=11811
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf