home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / IMAP / 94JUL.MIN < prev    next >
Encoding:
Text File  |  1994-08-08  |  3.8 KB  |  94 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. Date: Wed, 27 Jul 1994 07:38:29 -0700 (PDT)
  4. From: Terry Gray <gray@cac.washington.edu>
  5. Subject: IMAP WG Minutes
  6.  
  7. Minutes of the IMAP (Internet Message Access protocol) Working Group 
  8. Meeting at the 30th IETF (Toronto)
  9.  
  10. 26 Jul 1994
  11. 1600-1800
  12.  
  13. Twenty-five people attended.
  14.  
  15. The document author described a few terminology clarifications he made 
  16. since the last version of the draft.  References to "message numbers" 
  17. and "sequence numbers" are now uniformly changed to "message sequence 
  18. numbers", and the term "sets" is now used for lists or ranges of message 
  19. sequence numbers.
  20.  
  21. The principal agenda item was to discuss issues raised by John Klensin 
  22. (our Area Advisor) during his review of the IMAP4 spec. in perparation 
  23. for submission as a Proposed Standard.  John raised the following issues:
  24.  
  25.  o The document is hard to follow, because you must continually refer
  26.    back and forth between the commands, responses, and syntax sections of 
  27.    the document.
  28.  
  29.  --> Result: rationale for current organization discussed (it's oriented 
  30.      toward the way an implementation would be written).  Need for IMAP 
  31.      tutorial acknowledged.  No change to doc. organization will be made
  32.      at this time. 
  33.  
  34.  o The document needs a few more words at the beginning under a heading 
  35.    titled "How to read this document."  Especially the fact that you *must* 
  36.    consult the grammar to do an implementation.
  37.  
  38.  --> Result: text to be added.
  39.  
  40.  o Another sentence or two is needed to clarify cases where the optional 
  41.    keyword MAILBOX is included in a command (for backward compatibility);
  42.    e.g. is there a difference between "subscribe mailbox" and subscribe 
  43.    mailbox mailbox"?
  44.  
  45.  --> Result: text to be added.
  46.  
  47.  o The 30 min minimum value for an autologout timer on a server was 
  48.    thought to be too long in certain dialup contexts.
  49.  
  50.  --> Result: After extensive discussion, four options were identified:
  51.     -Remove ref to any timeout value in the spec.  (Bad because value 
  52.      needed    to set upper bound for client keep-alive processing.)  
  53.     -Change value to something other than 30 min. (No consensus on
  54.      what a better minimum would be.)
  55.     -Have the server probe the client.  (Dangerous because of potential 
  56.      for flow control deadlock!)
  57.     -Create command to allow client to tell server what timeout
  58.      value should be.  (Agreed, but not in base document.  Rob 
  59.      Austein to propose --the first!-- new CAPABILITY extension.)
  60.  
  61.  o There needs to be a small amount of meta-wording added to explain
  62.    that a subsequent document describing a protocol modification or 
  63.    extension (new CAPABILITY) can over-ride or modify the behavior 
  64.    described in the base spec, but that new extensions (CAPABILITIES) only
  65.    modify the base spec behavior by mutual consent of the client and
  66.    server.  This is similar to the SMTP extensions model. 
  67.  
  68.  --> Result: text to be added.
  69.  
  70. Also, an agreement was reached on modified wording concerning handling 
  71. of zero-length literals.
  72.  
  73. NEXT STEPS...
  74.  
  75. Draft version -05, incorporating the above changes, will appear within a
  76. few days. Thence John Klensin will request a "Last Call for Proposed
  77. Standard" notification for the following three documents: 
  78.  
  79.  o The base IMAP4 spec (standards track)
  80.  o John Myers' doc on a way to use the Authenticate cmd (standards track)
  81.  o The compatibility document (to be issued as an "Informational" RFC)
  82.  
  83. Everyone is requested to look at the last two ASAP for any final suggestions.
  84.  
  85. After the Last Call interval, assuming no major problems surface, John K. 
  86. will initiate balloting of the IESG on the above three docs.
  87.  
  88. Also, Rob Austein requested more feedback on the informational "How to use
  89. IMAP4 for Disconnected Operation" document, which is not yet ready for
  90. publishing. 
  91.  
  92. That's it.  In all, a very successful meeting.
  93.  
  94.