home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / drums / drums-minutes-96dec.txt < prev    next >
Text File  |  1997-01-30  |  8KB  |  169 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. Minutes recorded by Ned Freed <ned@innosoft.com>
  4. December 9th, 1996
  5.  
  6. Minutes for the DRUMs meeting at the San Jose IETF
  7.  
  8. 821bis document (John Klensin editor):
  9.  
  10. John stated that conversion to ABNF is incomplete; it will be completed once
  11. the ABNF specification is done. In addition, examples won't be revised until
  12. everything else is complete.
  13.  
  14. Discussion of outstanding 821bis issues:
  15.  
  16.   (a) It has been tentatively decided that the definition of the
  17.       Received: field will be moved from 822bis to 821bis. The logic
  18.       here is that MTAs are the things that need to deal with this
  19.       field so it should be defined in the MTA document. There was no
  20.       objection to this change.
  21.       
  22.   (b) The domain name in HELO/EHLO commands is problematic for some
  23.       clients. The proposal is that clients should insert their domain
  24.       name if they know it. The document editor will generate a
  25.       proposal for what to do if the domain name is not known.  (This
  26.       is likely to be some combination of domain literals for IPv4
  27.       addresses and strings that are identifiable as not being domain
  28.       names.) The language in RFC1123 regarding the need for servers
  29.       to accept arbitrary HELO parameter values will be retained; the
  30.       RFC1123 requirement that HELO parameters conform to domain
  31.       syntax may or may not be retained.
  32.       
  33.   (c) Jim Conklin raised the issue of back references the 821bis
  34.       document to RFC821. If the intent here is to produce an entirely
  35.       new specification such references are inherently
  36.       problematic. John responded that such references only appear to
  37.       cite obsolete or deprecated features we really want to go
  38.       away. Dave Crocker then suggested that such references be moved
  39.       to an appendix. John will see what he can do to resolve this.
  40.       
  41.   (d) Eric Allman pointed out that the current text says that out of
  42.       multiple MX records you need to pick one and it should say that
  43.       they need to be randomized.  John will fix this.
  44.               
  45.   (e) Loop detection. The group feels that:
  46.    
  47.        (1) Counting received lines is an easy and effective way to
  48.            detect some loops. A limit of 100 seems like an acceptable default.
  49.        (2) Other mechanisms may prove to be problematic.
  50.        (3) This entire issue needs to be addressed in detail in
  51.            another document. 
  52.  
  53. ABNF document (Dave Crocker editor):
  54.  
  55. Discussion of outstanding issues:
  56.  
  57.    (a) The precedence of alternation and concatenation need to be
  58.       changed. It was pointed out that the present precedence causes
  59.       problems when /= is used. The section also needs to make it
  60.       clear what "high precedence" means. A suggestion was made to use
  61.       "binds more tightly" or "binds more loosely", as these have
  62.       fairly obvious meaning. Examples are probably appropriate here.
  63.        
  64.    (b) The group feels that ABNF string literals should always be
  65.       considered to be case sensitive. When case sensitivity in the
  66.       grammar is needed it should be done as a concatentation of
  67.       literals.
  68.    
  69.    (c) The precedence of ".." needs to be specified and isn't. Dave
  70.       will fix this.  (".." binds more tightly than any other
  71.       operator.)
  72.        
  73.    (d) The group believes that digit values need to be specifiable in
  74.       bases other than 10. Dave will take suggestions and work up a
  75.       proposal to address this.
  76.        
  77.    (e) The group cannot reach consensus on whether to use ":=" or "="
  78.       as the rule definition operatior. As such, the chair proposed
  79.       that in the absence of consensus to change an existing
  80.       conventions we must retain the existing convention, which is
  81.       "=". This appears to be acceptable to the group.
  82.  
  83.    (f) There was some discussion of using a single unified syntax for
  84.       all sorts of literals, e.g. %t"string", %d"decimal-number",
  85.       %h"hex-number". This seems to be finding favor in the group and
  86.       will be taken to the list for further discussion.
  87.        
  88.    (g) It was suggested that we allow set subtraction. Pete Resnick
  89.       pointed out that range constructs seem to cover most of the
  90.       cases where subtraction might otherwise be needed without undue
  91.       complexity (822bis is an example of this), the 822bis document
  92.       might use this construct to advantage in defining things like
  93.       other-fields so that it does not include existing
  94.       fields. However, Pete also feels that this is messy and better
  95.       handled by prose comments.
  96.        
  97.    (h) Dave had to leave at this point, terminating the discussion.
  98.    
  99. 822bis document (Pete Resnick editor):
  100.  
  101. Discussion of outstanding issues:
  102.    
  103.    (a) Pete brought up the issue of what sort of white space is
  104.       allowed after the initial colon in a field -- whitespace,
  105.       whitespace plus comments, etc. John proposed that whitespace
  106.       plus comments be allowed after a colon in structured
  107.       fields. This appears to be acceptable; details will be thrashed
  108.       out on the list.
  109.        
  110.    (b) More explanation is needed in regards to handling of Bcc: lines
  111.       in replies.
  112.    
  113.    (c) The issue of how reply-to/from should be used in generating
  114.       replies. The current document says to use reply-to by default if
  115.       it is present and if it is not use from instead. It was then
  116.       pointed out that this is an on-wire protocol document, not an
  117.       MUA behavior document, and as such needs to deal with the
  118.       meaning of the fields, not their use. The suggestion was made to
  119.       define reply-to as the field where "the originator suggests
  120.       replies will be sent". The text that says that reply-to should
  121.       not be used when it is the same as the from field needs to be
  122.       removed, as this is actually used in some situations with
  123.       different semantics than those of a bare from.
  124.        
  125.    (d) Pete has picked up from the list that resent- is effectively
  126.       trace information.  John pointed out that if this is done both
  127.       resent-reply-to and resent-subject need to be deprecated, as
  128.       they do not make sense as trace. The group seems happy with
  129.       this.
  130.        
  131.    (e) Ned Freed objected to the requirement that resent-from and
  132.       resent-date be present.  John brought up the SMTP "251 user has
  133.       moved". Keith and Pete pointed out that resent- is supposed to
  134.       be reserved for manual resending operations only. Ned pointed
  135.       out that manual versus automatic is hard to distinguish. The
  136.       group seems to feel, however, that the present text is correct
  137.       as written.
  138.        
  139.    (f) The issue of header order and how to insert new headers was
  140.       raised. The consensus is that resent- headers should be
  141.       prepended to a message (note the lower case "should"), and thus
  142.       Received: headers may appear after resent- headers. An attempt
  143.       will also be made to describe the difference between resending
  144.       and forwarding.
  145.  
  146.    (g) The current grammar allows continuation lines containing only
  147.       whitespace. This will be changed to require some characters
  148.       (possibly only a comment), so as to allow interpreters to treat
  149.       lines containing only whitespace to be resolved as either a
  150.       header continuation line or as a break to the text. What is
  151.       appropriate for interpreters to do has yet to be resolved.
  152.        
  153.    (h) Chris raised the issue of whether the sender is a deliverable
  154.       mailbox or simply a trace field. (Chris had a slide that should
  155.       be attached here.) Keith proposed that as RFC1123 requires all
  156.       of these fields to be deliverable mailboxes this should be
  157.       addressed by the more general rule. Keith proposed language
  158.       saying that sender is distinguished from from either by (1)
  159.       Message sent on behalf of someone else or (2) Message sent on
  160.       behalf of several people, of which the sender may or may not be
  161.       one. In this case the sender should be the person who sent the
  162.       message, the from is the person or persons on behalf of whom the
  163.       message was sent. This will be discussed further on the list
  164.       although there seems to be consensus at the meeting.
  165.        
  166.    (i) Really out of time; group adjourned.
  167.    
  168.  
  169.