home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / drums / drums-minutes-95jul.txt < prev    next >
Encoding:
Text File  |  1995-10-18  |  8.1 KB  |  225 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Keith Moore/University of Tennessee
  5.  
  6. Minutes of the Detailed Revision/Update of Message Standards Working
  7. Group (DRUMS)
  8.  
  9. These minutes are based on notes taken by Rodney Tillotson.
  10.  
  11. Since this was the first meeting of the working group and there were no
  12. drafts of the revised mail standards available by the Internet-Drafts
  13. deadline, the chair proposed that the meeting time be used to discuss a
  14. small number of contentious issues, in the hope that the face-to-face
  15. contact would facilitate reaching closure on one or more of them.
  16.  
  17. The chair therefore produced a list of issues gleaned from discussions
  18. on the mailing list, and took suggestions from the floor for additional
  19. issues worthy of discussion.
  20.  
  21.  
  22. Issues Proposed for Discussion
  23.  
  24. The issues proposed for discussion were:
  25.  
  26. Syntax changes:
  27.  
  28.  
  29.   1. Mark Crispin's proposal (from the mailing list) that we remove
  30.      ``['', ``]'' and ``.''  from ``specials'' and redefine
  31.      ``local-part'' and ``domain'' to be just ``word''.  (Discussed
  32.      below.)
  33.  
  34.   2. How should IPv6 domain literals be represented?
  35.  
  36.   3. Should we unify 821 and 822 address syntax, and if so, what should
  37.      the grammar be?  (Subsumed by 21.)
  38.  
  39.  
  40. Others:
  41.  
  42.  
  43.   4. Discuss use of SMTP as a message submission protocol (what to do
  44.      about missing headers, etc.).
  45.  
  46.   5. Discuss use of RFC 822 as a message submission protocol (how to
  47.      handle Bcc:  etc.).
  48.  
  49.   6. What do/should the Resent-* headers really mean?
  50.  
  51.   7. Should we restrict the names or kinds of user-defined message
  52.      headers?  For example:
  53.  
  54.       a. Forbid field-names Content-* unless they are part of MIME.
  55.  
  56.       b. Forbid fields that are supposed to be interpreted by MTAs
  57.          (during transport or delivery).
  58.  
  59.   8. Interaction of headers with mailing lists?  (Subsumed by 10.)
  60.  
  61.  
  62. Harald Alvestrand's (paraphrased) additions, also circulated beforehand:
  63.  
  64.  
  65.   9. Headers:  should we require registration of non-``X-'' headers?
  66.      (reactivating a sleeping clause in RFC 822).
  67.  
  68.  10. Should we define the behavior of mailing lists?
  69.  
  70.  11. What tack should we take on syntax changes?
  71.  
  72.       -  No changes whatsoever?
  73.       -  Should we only make the syntax stricter than 822?
  74.       -  Should we loosen the 822 syntax, perhaps with warnings?
  75.       -  Be liberal (822-compliant) in what you receive, be conservative
  76.          (DRUMS-compliant) in what you send?
  77.  
  78.  12. Can we invent a name for the message format (other than
  79.      ``RFC822''), or should we call it ``Internet Mail''?
  80.  
  81.  
  82. Added in the meeting:
  83.  
  84.  
  85.  13. What is the meaning of Usenet headers in e-mail.
  86.  
  87.  14. Ambiguity about Reply-To:  (both the UA action and the field
  88.      specification).
  89.  
  90.  15. Places where RFC 822 specifies syntax but no semantics.
  91.  
  92.  16. HTTP headers which clash with mail ones (this was declared out of
  93.      scope for the DRUMS Working Group).
  94.  
  95.  17. What does ``authoritative'' mean in RFC 822?
  96.  
  97.  18. Received-*:  headers:  what is the syntax and what can you do with
  98.      them?
  99.  
  100.  19. What are the guiding principles for the bouncing of mail?  (NOTARY
  101.      fixes a few things.)
  102.  
  103.  20. The UA-MTA model:  what is a reflector?  an exploder?  Should we
  104.      devise a taxonomy of several meanings?
  105.  
  106.  21. RFC 821 and RFC 822 together:  remove obsolete parts and harmonize
  107.      syntax specifications.
  108.  
  109.  22. Should we revisit the RFC 822 rule requiring at least one To, Cc,
  110.      or Bcc:  address?
  111.  
  112.  23. RFC 822 does not clearly specify the use of msg-id in replies (it
  113.      provides two syntaxes, but ``unique'' is not specified).
  114.  
  115.  24. What categories of alteration to a message justify changing or
  116.      preserving the msg-id?
  117.  
  118.  
  119. Einar Stefferud also expressed interest in producing a document
  120. describing an MTA-UA model for Internet mail.  The chair suggested that
  121. this not be discussed at the meeting itself, but instead that he and
  122. other interested working group members collaborate on a draft or outline
  123. of such a document, and submit it to the group for consideration as to
  124. whether the group should produce such a document as an RFC.
  125.  
  126. The chair attempted to reduce the above list to a shorter list which
  127. could be discussed at the meeting.  The most attractive possibility was
  128. to dispose promptly of items which allowed it, but after several
  129. cautious attempts it appeared that at the time there were no issues
  130. which this meeting could deal with in this way.  Several of them raised
  131. more general questions about the approach to take and the amount of
  132. damage which could be inflicted on the existing standards or the
  133. existing user and product base, and it was hoped that detailed
  134. discussion of one or more specific issues.
  135.  
  136. The short list was reduced to about three items, although the first item
  137. in that short list (Mark Crispin's proposal) consumed almost all the
  138. remaining time.
  139.  
  140.  
  141. Discussion
  142.  
  143. Mark Crispin's proposal (1 above) was that we remove ``['', ``]'' and
  144. ``.''  from specials and redefine local-part and domain to be just
  145. ``word''.  This would (among other things) allow ``.''s in phrases.  On
  146. the one hand, this would make life simpler for parsers; on the other, it
  147. might encourage generation of even more messages that aren't compatible
  148. with existing mailers.
  149.  
  150. The intended effect of such a change is to remove the requirement to
  151. quote name phrases containing the above characters, which are currently
  152. ``specials'' as defined by RFC 822.  From an end user point of view, it
  153. would be worth some additional parsing effort to remove what may seem an
  154. arbitrary restriction.  In most cases where the quoting requirement is
  155. not honored, a human reader can immediately tell what is intended as in,
  156. for example:
  157.  
  158.  
  159.      To:  A.Random User <aru@somewhere>
  160.  
  161.  
  162. However, RFC 822 assumes that lexical analysis of addresses is not
  163. context dependent so that the name phrase receives the same treatment as
  164. an address.  Simply removing ``.''  from specials would allow some
  165. addresses which are currently invalid, such as:
  166.  
  167.  
  168.      <...hi.there...@cs.utk.edu>
  169.  
  170.  
  171. An alternative suggestion was that the RFC 822 grammar should not be
  172. changed, but that advice could be generated on parsing incoming
  173. addresses which are out of specification.
  174.  
  175. Discussion spread to compare the cost of making changes in general with
  176. the cost of not making them.  It was pointed out that the earlier
  177. transition from RFC 733 to RFC 822 working was justified because it had
  178. by then become essential (even though it was expected to cause at least
  179. some failures); but also that the community affected by intrusive
  180. changes now is orders of magnitude greater than it was then.
  181.  
  182. Where practice has diverged from standards, normally the standards
  183. should be updated or the practices banned.  Rules should only be relaxed
  184. where there are compelling reasons.
  185.  
  186. It should be remembered that RFC 822 (for instance) is referred to by
  187. many other RFCs and other documents, and that changes to it even when
  188. considered necessary might have effects which cannot easily be foreseen.
  189.  
  190. The chair pointed out that it was necessary to consider the resulting
  191. effect on user agents that would have to maintain backward compatibility
  192. with existing user agents.  A change intended as a simplification might
  193. in reality make implementation more complicated, reduce interoperability
  194. with the installed base, or make it more difficult to understand what is
  195. required to produce a user agent that is interoperable in practice.
  196. Even after the change took effect, an effective user agent would still
  197. have to support both the old and the new versions of the message format.
  198.  
  199. Dave Crocker proposed several categories of change:
  200.  
  201.  
  202.    o Specifications which are broken.
  203.    o Specifications which are unclear.
  204.    o Limitations now considered inappropriate.
  205.    o Enhancements.
  206.  
  207.  
  208. It is also desirable to simplify the specifications where possible.
  209.  
  210. Criteria against which to assess the value of a proposed change are:
  211.  
  212.  
  213.    o Simplicity of the resulting specification.
  214.    o Benefits to users of changes proposed.
  215.    o Impact on the installed base.
  216.  
  217.  
  218. Dave Crocker agreed to write a draft describing this taxonomy for
  219. circulation to working group members.
  220.  
  221. The allotted time having elapsed for the meeting, the chair suggested
  222. that the above discussion be continued on the mailing list, and the
  223. meeting was adjourned.
  224.  
  225.