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

From: Bruce Lilly <[email-masked]>
Date: Fri, 11 Feb 2005 20:18:49 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Sat, 12 Feb 2005 12:32:12 +0000

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/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Feb 2005 10:52:17 -0800

At 12:32 PM +0000 2/12/05, [email-masked] wrote:
>draft-harrison-email-tracking-00.txt stricken from the record...

That's not possible in the IETF. In fact, many people often argue 
that Internet Drafts should live much longer than six months. Welcome 
to the club of people who wished that certain drafts could have a 
much, much shorter lifetime.

>  I don't think

Generally not a problem; like most people, IETFers have a short 
attention span for things that are not constantly brought before them.

--Paul Hoffman, Director
--VPN Consortium

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 14 Feb 2005 20:21:59 +0100

--On mandag, februar 14, 2005 10:52:17 -0800 Paul Hoffman 
<[email-masked]> wrote:

> That's not possible in the IETF. In fact, many people often argue that
> Internet Drafts should live much longer than six months. Welcome to the
> club of people who wished that certain drafts could have a much, much
> shorter lifetime.

correction.... it IS possible to ask the secretariat to withdraw an 
internet-draft, and if the author asks, it will be honored.

(don't start the rush today, though.... this is deadline week!)

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 17 Feb 2005 11:59:21 -0500

> I could take six months of flaming.

If the MSGTRK work is indeed what you had in mind, thats' fine.
[It's possible to submit a revision pointing to that work, as an
alternative to withdrawal.]  On the other hand, if you had something
different in mind, by all means proceed if you wish.

Best regards,
  Bruce Lilly