Re: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt

--On Monday, March 26, 2001 18:37 -0500 [email protected] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Message Tracking Protocol
> Working Group of the IETF.
>
>	 Title		: The Message/Tracking-Status MIME Extension
>	 Author(s)	: E. Allman
>	 Filename	: draft-ietf-msgtrk-trkstat-01.txt
>	 Pages		: 8
>	 Date		: 23-Mar-01

        Message tracking is intended for use as a "last resort" mecha-
   nism.   Normally,  Delivery  Status  Notifications (DSNs) [RFC-DSN-
   SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]  would
   provide  the  primary  delivery  status.   Only if no response from
   either of these mechanisms would Message Tracking be used.

The last sentence needs a verb.

        A  Message  Tracking Status Notification (MTSN) is intended to
   be returned as the body of a Message Tracking request  [DRAFT-MTRK-
   MTQP].   The  actual body MUST be a multipart/related [RFC-RELATED]
   with type of "tracking-status"; each subpart  MUST  be  type  "mes-
   sage/tracking-status" as described herein.

The multipart/related type parameter takes a media type, so:

   ... The  actual body MUST be a multipart/related [RFC-RELATED]
   with type parameter of message/tracking-status.

----
      ...  That body consists of one or more "fields" for-
      matted to according to the ABNF of RFC 822 headers "fields" (see
      [RFC-MSGFMT]).

headers -> header
----

           The body of  a  message/tracking-status  is  modeled  after
      [RFC-DSN-STAT].  That body consists of one or more "fields" for-
      matted to according to the ABNF of RFC 822 headers "fields" (see
      [RFC-MSGFMT]).  The per-message fields appear first, followed by
      a blank line.  Following the per-message fields are one or  more
      groups  of  per-recipient  fields.   Each group of per-recipient
      fields is preceded by a blank line.  Formally, the syntax of the
      message/tracking-status content is as follows:

I'd be inclined to add something like:

Note that there will be a blank line between the final per-recipient field 
and the MIME boundary, since one CRLF is necessary to terminate the field, 
and a second is necessary to introduce the MIME boundary.
----
         delivered    The  message  has been successfully delivered to
                      the final recipient.  This  includes  "delivery"
                      to  a  mailing list exploder.  It does not indi-
                      cate that the message has been read.  No further
                      information  is  available;  in  particular, the
                      tracking agent SHOULD NOT attempt further "down-
                      stream" tracking requests.

         expanded     The  message  has been successfully delivered to
                      the  recipient  address  as  specified  by   the
                      sender,   and  forwarded  by  the  Reporting-MTA
                      beyond that destination to  multiple  additional
                      recipient  addresses.  However, these additional
                      addresses are not trackable,  and  the  tracking
                      agent  SHOULD  NOT  attempt further "downstream"
                      tracking requests.
...
           The  tracking  algorithms  MUST  NOT allow tracking through
      list expansions.  When a message  is  delivered  to  a  list,  a
      tracking request MUST respond with an "expanded" tracking status
      and MUST NOT display the contents of the list.

I'm unclear under what conditions to use "delivered" or "expanded" for 
mailing lists or aliases.  Please fix.

----
 3.5.  Interaction Between MTAs and LDAs

           A message that has been delivered to  an  LDA  that  under-
      stands  message  tracking  (in  particular, an LDA ...

You need to associate "LDA" with the expansion of the acronym in section 
3.3.5.  Either expand it once here as well, or use the acronym in 3.3.5.
----

A note on my security consideration suggestion for the SMTPEXT document, a 
reference to the security considerations section in this document would 
suffice.

		- Chris