Re: Revised Draft Charter

Ken,

I'll state my individual opinion. See below.

Ken_Lin/SSW/[email protected] wrote:

> Here are my comments.  Please pardon my unfamiliarity with WG charters.
>
> > Message Tracking Working Group (msgtrk)
> > ---------------------------------------
> >
> >    Charter
> >
> >    Chair(s):
> >
> >        Gordon B. Jones  <[email protected]>
> >
> >    Applications Area Director(s)
> >
> >         Keith Moore  [email protected]
> >         Patrik Falstrom [email protected]
> >
> >    Mailing lists:
> >
> >        General Discussion: [email protected]
>
> 1) An IMC member offered up hosting it in his domain.
>
> >        To Subscribe: [email protected]
> >        In Body: subscribe msgmib-list <email address> <your name>
>

Ok. He meant hosting it at the IMC itself. I say we do this but we should
also submit the charter in the  meantime if it happens too slowly.

> 2) Since "MIB" is misleading, it has been suggested to rename the list
> to msgtrk.
>

ok

> >        Archive: sloop-1.esinet.org/pub/msgmib-archive
>
> 3) Clarify that the archive is accessed via FTP (someone asked about
> that in the BOF)
>

ok

> >
> >     Description of Working Group:
> >
> >
> >      The Message Tracking Working Group will design a diagnostic
> >      protocol for a message originator to request information about the
>
> 4) At the BOF we agreed that tracking by recipient and administrator
> are out of scope.  Do we need to be explicit about that here or is the
> "message originator" passage good enough?
>

We discussed the possibility of delegation, so administrator is not entirely
out of scope. I would just leave this.

> >      submission, transport, and delivery of a message independently of
>
> 5) In the next paragraph we say "The types of messages to be tracked
> include RFC 822bis messages, and optionally others."  Did we have
> something in mind by "optionally others"?  If not, the following
> sentence fragment here would be better:
>       "submission, transport, and delivery of RFC 822 messages..."
>

ok

> >      its delivery status.
> >
> >      The group will produce two standards track documents: a message
> >      tracking model document and a protocol document. The model will
> >      state how message tracking is enabled, identify the entities
> >      involved (e.g., MTAs, ttrace serversv), define how and when
>
> 6) It might be better to remove the parenthetical comment since "MTAs,
> trace servers" are the entities the model document will describe.
>

ok

> >      message tracking requests are issued and answered, define
> >      approaches for inter-domain message tracking, and address security
> >      issues. The types of messages to be tracked include RFC 822bis
> >      messages, and optionally others. Messages will be tracked from the
>
> 7) Remove "The types of messages ... and optionally others" if we agree
> with bullet 5).
>

ok

> >      time they enter the messaging network up until the time they are
> >      delivered (e.g. to an end-userFs mailbox or a proprietary mail
>
> 8) In the BOF, there was discussion about the end point.  Both "final
> delivery" and "drop" were used instead of "delivered".  The sample
> usage for "drop" was "dropped to an IMAP server" rather than "delivered
> to an IMAP server".  Any ideas on the wording for the end point?
>

I was playing with the idea of "discharged onward to an entity that is not
itself an MTA".

> >      system).
> >
> >      The group will design one or more protocols to implement message
> >      tracking as described above.
> >
> >      Goals and Milestones:
> >
> >      Oct  15 Post an Internet Draft of the message tracking model
> >
> >      Nov 15 Post revised draft of message tracking model
> >
> >      43rd IETF discuss protocol, finish model
> >
> >      Jan 1 post final draft of model, post Internet Draft of protocol
> >
> >      Feb 15 Post revised draft of protocol
> >
> >      44 th IETF discuss protocol
> >
> >      May 1 Post final draft of protocol
> >