From: Keith Moore <moore@cs.utk.edu>
Date: Fri, 1 Dec 1995 06:00:36 -0500
Message-Id: <199512011100.GAA21890@wilma.cs.utk.edu>
To: drums@cs.utk.edu
Subject: rough agenda for next week's meetings


Okay, here's my draft agenda for Monday.  On Friday we will take
up any leftover business from items II and III (probably in that order).

I. discussion of charter, scope, and decision criteria (20 minutes)
   + what are we {supposed,allowed,forbidden} to do
   + what is within our scope
   + why might we want to change existing specs
   + criteria for evaluating possible decisions

II.  quick review of SMTP draft document. (1 hour max)
     The point of this is to identify issues, not to work out things
     in detail.

III.  issues list (max 20 minutes each)
     (The Chair reserves the right to change the order from that
      presented below or to add other issues.  If we can resolve
      the issue in 20 minutes, fine, if not it is tabled either
      to the list or (if people want to work it out during
      the week) until the Friday meeting.)

     Most of you will recognize this list: it's the one we worked
     on in Stockholm, rearranged slightly, with a few new things
     added and a few resolved issues removed.  I've included some
     suggestions for how I think things might go...which should not
     be taken as edicts from the chair or even necessarily how I want 
     things to end up...

   A. changes to syntax of addresses
	1. unify 821/822 syntax
	2. IPv6 domain literals
		(we need a proposal here)
	3. remove "[", "]", "." from "specials" ?
   B. use of 822 as a message submission protocol (e.g. "sendmail -t")
	(need a proposal here -- is this in the smtp draft?)
   C. use of SMTP as a message submission protocol
	(we need prose here)
	(which headers are required? which ones are forbidden?
	what add'l processing (if any) should the MTA do beyond
	that of normal messages received with smtp?)
   D. resent-* headers
	1. resolve ambiguity between different interpretations
	   (manual redistribution by recipient vs. automatic
	   redistribution by lists; what resent-* means to UAs
	   when composing replies; must they occur in {from,to} pairs?)
 	   (pick one interpretation OR deprecate the header OR
	    remove the header from 822bis OR ...)
	2. make arrangements to provide the functionality that
	   resent-* was supposed to provide but didn't work
	   (i.e. audit trail for human intervention)
   E. Restrictions on headers in general
	1. Content-* fields are reserved for MIME?
	2. non X-* fields must be registered with IANA?
	3. limitations on use of header fields by MTAs?
	   (e.g. an MTA does NOT route on to/cc/bcc fields, and it
	    does NOT honor Errors-to, return-reciept-to)
   F. What is recommended behavior for mailing lists?
      (I expect that many of these will be expressed as tradeoffs)
   G. Shall we call this "Internet Mail"?  "822bis"?
   H. Usenet headers in mail
        1. field names defined for usenet are reserved in internet mail
	   and may not be used for different purposes.
	2. incorporation of usenet header fields into internet mail
	   is probably out-of-scope (it is dangerously close to 
	   the mail<->news interoperability rathole)
  I. Received headers
	1. what kinds of things can they express?
	2. any syntax changes?
  J. Rules for mail bouncing
	1. minimum required behavior (bounce to envelope return-path
 	   or return-path header, bounces have null return-path)
	2. bounced message MUST contain failed address and
	   SHOULD contain some indication of the error which caused failure
	   (if any such indication is available)
	3. recommend use of NOTARY for message format
	4. recommendation for gateways into wierd environments /
	   consequences of failure to conform
	5. recommendations to provide more accurate error reporting?
  K. Sender field
	1. resolve ambiguity between different interpretations
 	   (pick one interpretation OR deprecate the header OR
	    remove the header from 822bis OR ...)
	2. make arrangements to provide the functionality that
	   is missing once #1 is accomplished
	   (i.e. person who sent the message, name of list,
	   manager of list,)
  L. UA/MTA abstract model / definitions
	(someone needs to write prose)
  M. Shall we continue to require at least one of To/Cc/Bcc?
     (what are the consequences if we don't do this anymore?)
  N. message-id:
     	1. should it be required (or recommended) during composition?
	2. what changes to a message require a new message-id?
	3. what can a mail reader reasonably expect if two messages 
	   have the same message-id?
	(maybe we should express things in terms of #3 rather than #2)
	4. MUST be unique
  O. in-reply-to:
	recommend/require using message-id if it is available?
  P. references: header
	clarify meaning -- does it form threads?
	(what's the impact if we align it with netnews?)
	recommend/require updating when replying?
  Q. required MTA support for Postmaster address
  R. what is Comments: for?
     (suggest: markings by mail handling software not intended
     for general recipient consumption, but possibly of interest
     to a human who needs to look at headers in detail.)