It would seem my Internet-Draft is somewhat poorly researched and immature; moreover, my proposal has already been established, comprehensively, by others (msgtrk charter: RFCs 3885-3888). It is therefore my decision, if this is at all possible, to have draft-harrison-email-tracking-00.txt stricken from the record... I don't think I could take six months of flaming. With thanks Christopher Harrison http://www.ChrisHarrison.co.uk/ Bruce Lilly <blilly@xxxxxxxxx> wrote: > On February 10, draft-harrison-email-tracking-00.txt was > announced on the ID-announce mailing list. > > Assuming that the draft is not intended to be a precursor of > an April 1 RFC, I have several comments. Since the draft > mentions no place for public discussion, I am copying the > IETF discussion list, with a suggestion that any public > discussion take place there, unless and until a more > suitable venue is proposed. > > First, the draft seems to be in far too premature a state to > warrant detailed commentary, so I'll touch on several issues > in general terms. > > o The subject matter of the draft appears to be covered > more appropriately and far more comprehensively by RFCs > 3885 through 3888. I believe that publication as an > RFC would be harmful to the IETF work done in the > MSGTRK WG. > > o It proposes a header field, which it confusingly calls > a "header", but provides no ABNF and no textual > indication of syntax or semantics. > > o It refers to an "originator", but does not specify the > source of that information, nor what should happen if > the SMTP envelope return path or other source of > "originator" is a null path. > > o It mentions "return receipt", but provides neither a > normative nor informative reference. > > o It purports to turn the "only human-readable" Subject > field comprised of unstructured text into a repository > for keywords in a specific language, with no provision > for localization or registration of keywords. > > o The proposed field uses a portion of the header field > namespace reserved for MIME extension fields, but the > field is not claimed as a MIME extension field, nor is > there is either a normative or informative reference to > the MIME specifications. > > o No header field registration information is provided. > > o Overall, the proposal is so nebulous as to defy any > attempt at implementation. > > o There is no discussion of interaction with deployed > mechanisms, including gateways (e.g. to/from X.400), > message/partial fragmentation, or resent messages. > > o The draft lacks the mandatory Security Considerations > section. > > o Although the draft uses the English-language word > "TRACK" in a message header field, there is no > provision for internationalization or localization and > no Internationalization Considerations section. > > o Although a keyword is proposed, there is no IANA > Considerations section. > > o There is a single "References" section, improperly > formatted, and with no indication of whether the single > reference (N.B. not plural) listed is normative or > informative. > > References: > > STD11 Crocker, D., "Standard for the format of ARPA Internet > text messages", STD 11, RFC 822, August 1982. > > RFC1958 Carpenter, B., "Architectural Principles of the > Internet", RFC 1958, June 1996. > > RFC2026 Bradner, S., "The Internet Standards Process -- > Revision 3", BCP 9, RFC 2026, October 1996. > > RFC2045 Freed, N. and N. Borenstein, "Multipurpose Internet > Mail Extensions (MIME) Part One: Format of Internet > Message Bodies", RFC 2045, November 1996. > > RFC2046 Freed, N. and N. Borenstein, "Multipurpose Internet > Mail Extensions (MIME) Part Two: Media Types", RFC > 2046, November 1996. > > RFC2277 Alvestrand, H., "IETF Policy on Character Sets and > Languages", BCP 18, RFC 2277, January 1998. > > RFC2418 Bradner, S., "IETF Working Group Guidelines and > Procedures", BCP 25, RFC 2418, September 1998. > > RFC2822 Resnick, P., "Internet Message Format", RFC 2822, > April 2001. > > RFC3864 Klyne, G., Nottingham, M., and J. Mogul, > "Registration Procedures for Message Header Fields", > BCP 90, RFC 3864, September 2004. > > RFC3885 Allman, E. and T. Hansen, "SMTP Service Extension > for Message Tracking", RFC 3885, September 2004. > > RFC3886 Allman, E., "An Extensible Message Format for > Message Tracking Responses", RFC 3886, September > 2004. > > RFC3887 Hansen, T., "Message Tracking Query Protocol", RFC > 3887, September 2004. > > RFC3888 Hansen, T., "Message Tracking Model and > Requirements", RFC 3888, September 2004. > > Malamud05 Malamud, c., "Labels in Subject Headers Considered > Ineffective At Best", draft-malamud-subject-line, > Work in progress, January 2005. > > Lilly05 Lilly, B., "Implementer-friendly Specification of > Message and MIME-Part Header Fields and Field > Components", draft-lilly-field-specification, Work > in progress, February 2005. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf