Re: "Reciprocation of SMTP Trace Record", draft-harrison-email-tracking-00.txt

[[e-mail]]

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 <[e-mail]> 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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf