home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / drums / drums-minutes-96mar.txt < prev    next >
Text File  |  1996-05-23  |  4KB  |  75 lines

  1. Editor's note:  These minutes have not been edited.
  2.  
  3. Minutes of the DRUMS WG meeting at Los Angeles IETF, March 9, 1996. 
  4.  
  5. Reported by: Keith Moore (based on notes by John Norenberg) 
  6.  
  7. Keith Moore chaired the meeting, which involved discussion of the following topics:
  8.  
  9. 1. Name of the protocol suite (to replace "RFC 822"). 
  10.  
  11. The most popular names seem to be simply "Internet Mail" or "Internet Messaging". Discussion compared the two. The general feeling seemed to be that "Mail" was more widely understood and more apropos than "Messaging". 
  12.  
  13. 2. Document set. The chair proposed focusing on four documents: 
  14.  
  15. 1. an overview/abstract model document, which defines terms, 
  16. and describes the major components of the mail system and how they fit togther.
  17.  
  18. 2. a definition of ABNF syntax, which can be used by other 
  19. documents besides just those on electronic mail. 
  20.  
  21. 3. a document defining the syntax of message headers (a 
  22. replacement for RFC 822), and describing minimal user agent behavior
  23.  
  24. 4. a document describing SMTP (replacement for RFC 821) 
  25. and also MTA behavior
  26.  
  27. After some discussion, where other topics such as mail gateways and a general overview were considered, the group agreed to limit its focus to these four documents. Eric Allman will see if he can devote time to editing first one. Dave Crocker has submitted an internet-draft of the second. John Myers had submitted a detailed outline of the third document to the group immediately prior to the Los Angeles meeting. John Klensin submitted a draft of the fourth document prior to the Dallas meeting; the group is awaiting a revised version of this draft. 
  28.  
  29. 3. Handling of source-routed addresses
  30.  
  31. A detailed proposal on this is needed before discussion. Discussion on deferred to the mailing list until such a proposal is available.
  32.  
  33. 4. Language to define functionality for EXPN and VRFY and 
  34. clearly distinguish between the two.
  35.  
  36. John Myers (?) and Eric Allman volunteered to draft some language.
  37.  
  38. 5. "."s in phrases
  39.  
  40. The group expessed a consensus to require UAs to accept "."s in phrases which appear in address lists. (though not necessarily in other contexts where phrases may appear). The editor of the message format document will consider how best to express this.
  41.  
  42. 6. use of RFC 822 (or its successor) as a message submission 
  43. protocol.
  44.  
  45. No advice currently exists as to how to derive an envelope from the message header, particularly for bcc handling. The group felt that this belongs in the abstract model/ overview document.
  46.  
  47. 7. Use of SMTP as a message submission protocol 
  48.  
  49. Text discribing this is already in the SMTP draft. 
  50.  
  51. 8. Detection of mail loops
  52.  
  53. Various working group members have submitted proposals, but other than to mention them, these were not discussed at the meeting.
  54.  
  55. 9. Which syntax to use for IPv6 domain literals 
  56.  
  57. The group felt that domain literals should be retained for IPv6. Of syntaxes similar to:
  58.  
  59. user@[ip6.abcd.0123.4567.89ab]
  60. user@abcd.0123.4567.89ab.ip6.int
  61.  
  62. The group (after discussion) preferred the former, favoring a syntax that requires special handling for such addresses. 
  63.  
  64. 10. Whether to require 8BITMIME extension for compliance 
  65.  
  66. A polling of the group demonstrated strong support that the SMTP implementations SHOULD implement 8BITMIME. Most were against saying that implementations MUST implement it. 
  67.  
  68. 11. Whether to recommend that servers put "ESMTP " in greeting. 
  69.  
  70. The group felt that the wording in RFC 1869 (which says to always send EHLO first) is already adequate and should not be changed.
  71.  
  72. 12. Regarding use of multiple RCPTs per envelope. 
  73.  
  74. Regarding the RFC 1123 recommendation to use multiple RCPT commands in a single session, when sending a message to several recipients at the same MTA: the SMTP document editor is directed to consider whether the current text is ambiguous or misleading and change it if necessary.
  75.