Message-Id: <199603030434.XAA27336@wilma.cs.utk.edu>
To: drums@cs.utk.edu
Subject: proposed agenda for 8 March WG meeting
cc: moore@cs.utk.edu
From: Keith Moore <moore@cs.utk.edu>
Date: Sat, 02 Mar 1996 23:34:32 -0500
Sender: moore@cs.utk.edu


For Friday's meeting, I propose that we take up the following issues,
in this order:

1. What are we going to name this thing?  (15min)

   I'm going to recommend that we take Harald's suggestion and
   call the protocol suite "Internet Mail", with document titles 
   something like:

   An Overview of Internet Mail
   Internet Mail Headers
   Internet Mail Transport - the Simple Mail Transfer Protocol

2. Which documents to be produced  (15min)

   At the last meeting there were several suggestions to add additional
   documents to our task list.  While there were a lot of good ideas,
   as Chair I'm concerned that we might take on more work than we can
   handle.  It's a lot of work to edit one of these documents and the
   authors tend to be people who are already busy anyway.  Also, I'm
   concerned about the potential difficulties of coordinating between
   the different authors, and the discrepancies that might result in
   the resulting documents.

   I plan to get the current document authors together sometime earlier
   in the week and come up with a proposal for a document set to be
   discussed at the WG meeting.  Offhand, I'm thinking in terms of:

   1. abstract model/terminology document
   2. slightly improved ABNF definition (so other RFCs can reference it)
   3. Internet Mail Headers (822bis)
   4. Internet Mail Transport (SMTPbis)
      (along with mail routing via DNS, and MTA requirements)
   5. (informational) overview of Internet Mail

   ...and I'd like the hold the total number of documents to 4 or 5.
   (roughly twice as many as I thought we'd have to produce)

3. Discussion of draft-ietf-drums-smtpupd-01.txt  (tbd)

   I'd like us to move this draft along quickly.  If there are
   issues that need to be resolved before the next draft is 
   produced, which could benefit from a face-to-face meeting, I
   want to make time for them.   If anyone (including the document
   author) can identify such issues, please post them to the list
   before next Thursday.

4. Discussion of how to resolve certain issues that need to be worked
   out in detail.  (we may wish to appoint individuals or committees
   to analyze the problems and/or work out detailed proposals to submit
   to the authors or to the WG in Montreal)  (30min)

   These are all issues left over from earlier discussions; I'd like
   to get these shaken down before inviting introduction of new ones.

   [ ] handling of source-routed addresses
   [ ] language for EXPN and VRFY
   [ ] advice to 822bis implementors about how to deal with illegal
       characters in phrases (such as ".") when parsing messages.
       (we had near-concensus in Dallas to leave the set of "specials"
       as in 822, but to give advice to implementors about how to
       deal with the broken stuff)
   [ ] use of 822 as a message submission protocol 
       (derivation of an envelope from the header, bcc handling, etc.)
   [ ] use of SMTP as a message submission protocol
       (which headers are required, which may be defauted by SMTP
       server, etc.)
       [ this is currently in appendix B of the smtpupd draft ]
   [ ] detection of mail loops  (using either received headers
       or envelope information)
   

5. Miscellaneouus issues (with a limited time rule like that used in Dallas)

   [ ] which syntax to use for ipv6 domain literals:

       user@[ip6.abcd.ef01.2345.6789]

       or

       user@abcd.ef01.2345.6789.ip6.int

       ...just to get a show of hands and/or brainstorming about
       improvements on one or the other of the above.

   [ ] Whether to require 8BITMIME extension for compliance with the
       new SMTP spec.   (people would of course still be free to 
       implement the old SMTP spec and be 7-bit only, and new SMTPs
       would still have to interoperate with old ones.)

   [ ] Whether to recommend that servers put "ESMTP " in greeting if they 
       support the EHLO command and at least one extension.  This would
       not rid them of the necessity to support the HELO command, and
       clients would still be required to try HELO if EHLO failed with
       5xx (even if the server somehow had ESMTP in its greeting)

   [ ] others?

--------
Take the pledge! "I do not limit my speech to satisfy the whims of Congress."