CURRENT_MEETING_REPORT_ Reported by Keith Moore/University of Tennessee Minutes of the Detailed Revision/Update of Message Standards Working Group (DRUMS) These minutes are based on notes taken by Rodney Tillotson. Since this was the first meeting of the working group and there were no drafts of the revised mail standards available by the Internet-Drafts deadline, the chair proposed that the meeting time be used to discuss a small number of contentious issues, in the hope that the face-to-face contact would facilitate reaching closure on one or more of them. The chair therefore produced a list of issues gleaned from discussions on the mailing list, and took suggestions from the floor for additional issues worthy of discussion. Issues Proposed for Discussion The issues proposed for discussion were: Syntax changes: 1. Mark Crispin's proposal (from the mailing list) that we remove ``['', ``]'' and ``.'' from ``specials'' and redefine ``local-part'' and ``domain'' to be just ``word''. (Discussed below.) 2. How should IPv6 domain literals be represented? 3. Should we unify 821 and 822 address syntax, and if so, what should the grammar be? (Subsumed by 21.) Others: 4. Discuss use of SMTP as a message submission protocol (what to do about missing headers, etc.). 5. Discuss use of RFC 822 as a message submission protocol (how to handle Bcc: etc.). 6. What do/should the Resent-* headers really mean? 7. Should we restrict the names or kinds of user-defined message headers? For example: a. Forbid field-names Content-* unless they are part of MIME. b. Forbid fields that are supposed to be interpreted by MTAs (during transport or delivery). 8. Interaction of headers with mailing lists? (Subsumed by 10.) Harald Alvestrand's (paraphrased) additions, also circulated beforehand: 9. Headers: should we require registration of non-``X-'' headers? (reactivating a sleeping clause in RFC 822). 10. Should we define the behavior of mailing lists? 11. What tack should we take on syntax changes? - No changes whatsoever? - Should we only make the syntax stricter than 822? - Should we loosen the 822 syntax, perhaps with warnings? - Be liberal (822-compliant) in what you receive, be conservative (DRUMS-compliant) in what you send? 12. Can we invent a name for the message format (other than ``RFC822''), or should we call it ``Internet Mail''? Added in the meeting: 13. What is the meaning of Usenet headers in e-mail. 14. Ambiguity about Reply-To: (both the UA action and the field specification). 15. Places where RFC 822 specifies syntax but no semantics. 16. HTTP headers which clash with mail ones (this was declared out of scope for the DRUMS Working Group). 17. What does ``authoritative'' mean in RFC 822? 18. Received-*: headers: what is the syntax and what can you do with them? 19. What are the guiding principles for the bouncing of mail? (NOTARY fixes a few things.) 20. The UA-MTA model: what is a reflector? an exploder? Should we devise a taxonomy of several meanings? 21. RFC 821 and RFC 822 together: remove obsolete parts and harmonize syntax specifications. 22. Should we revisit the RFC 822 rule requiring at least one To, Cc, or Bcc: address? 23. RFC 822 does not clearly specify the use of msg-id in replies (it provides two syntaxes, but ``unique'' is not specified). 24. What categories of alteration to a message justify changing or preserving the msg-id? Einar Stefferud also expressed interest in producing a document describing an MTA-UA model for Internet mail. The chair suggested that this not be discussed at the meeting itself, but instead that he and other interested working group members collaborate on a draft or outline of such a document, and submit it to the group for consideration as to whether the group should produce such a document as an RFC. The chair attempted to reduce the above list to a shorter list which could be discussed at the meeting. The most attractive possibility was to dispose promptly of items which allowed it, but after several cautious attempts it appeared that at the time there were no issues which this meeting could deal with in this way. Several of them raised more general questions about the approach to take and the amount of damage which could be inflicted on the existing standards or the existing user and product base, and it was hoped that detailed discussion of one or more specific issues. The short list was reduced to about three items, although the first item in that short list (Mark Crispin's proposal) consumed almost all the remaining time. Discussion Mark Crispin's proposal (1 above) was that we remove ``['', ``]'' and ``.'' from specials and redefine local-part and domain to be just ``word''. This would (among other things) allow ``.''s in phrases. On the one hand, this would make life simpler for parsers; on the other, it might encourage generation of even more messages that aren't compatible with existing mailers. The intended effect of such a change is to remove the requirement to quote name phrases containing the above characters, which are currently ``specials'' as defined by RFC 822. From an end user point of view, it would be worth some additional parsing effort to remove what may seem an arbitrary restriction. In most cases where the quoting requirement is not honored, a human reader can immediately tell what is intended as in, for example: To: A.Random User However, RFC 822 assumes that lexical analysis of addresses is not context dependent so that the name phrase receives the same treatment as an address. Simply removing ``.'' from specials would allow some addresses which are currently invalid, such as: <...hi.there...@cs.utk.edu> An alternative suggestion was that the RFC 822 grammar should not be changed, but that advice could be generated on parsing incoming addresses which are out of specification. Discussion spread to compare the cost of making changes in general with the cost of not making them. It was pointed out that the earlier transition from RFC 733 to RFC 822 working was justified because it had by then become essential (even though it was expected to cause at least some failures); but also that the community affected by intrusive changes now is orders of magnitude greater than it was then. Where practice has diverged from standards, normally the standards should be updated or the practices banned. Rules should only be relaxed where there are compelling reasons. It should be remembered that RFC 822 (for instance) is referred to by many other RFCs and other documents, and that changes to it even when considered necessary might have effects which cannot easily be foreseen. The chair pointed out that it was necessary to consider the resulting effect on user agents that would have to maintain backward compatibility with existing user agents. A change intended as a simplification might in reality make implementation more complicated, reduce interoperability with the installed base, or make it more difficult to understand what is required to produce a user agent that is interoperable in practice. Even after the change took effect, an effective user agent would still have to support both the old and the new versions of the message format. Dave Crocker proposed several categories of change: o Specifications which are broken. o Specifications which are unclear. o Limitations now considered inappropriate. o Enhancements. It is also desirable to simplify the specifications where possible. Criteria against which to assess the value of a proposed change are: o Simplicity of the resulting specification. o Benefits to users of changes proposed. o Impact on the installed base. Dave Crocker agreed to write a draft describing this taxonomy for circulation to working group members. The allotted time having elapsed for the meeting, the chair suggested that the above discussion be continued on the mailing list, and the meeting was adjourned.