On Tue April 5 2005 15:30, Internet-Drafts@xxxxxxxx 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@xxxxxxxxxxx is equivalent to foo@xxxxxxxxxxx -- 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf