home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / imap / imap-minutes-93aug.txt < prev    next >
Text File  |  1994-02-08  |  36KB  |  996 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4. Reported by Terry Gray/University of Washington
  5.  
  6. Minutes of the Internet Message Access Protocol Working Group (IMAP)
  7.  
  8.  
  9. Summary
  10.  
  11. An interim IMAP Working Group meeting was held at the University of
  12. Washington on August 30 and 31, 1993.  Eight people attended.
  13. Twenty-three issues were discussed.  A consensus position was reached on
  14. twenty of those issues.  No consensus was reached, but some progress was
  15. made on the issues related to namespace semantics and hierarchy support.
  16. A separate message, attempting to summarize this particular issue, will
  17. be forthcoming.
  18.  
  19. A new Internet-Draft, incorporating the results of this meeting and
  20. several suggestions made via e-mail, will be forthcoming for general
  21. review and comment.
  22.  
  23.  
  24. Issue 1:  Extensibility of IMAP
  25.  
  26.   A. Envelope headers
  27.   B. Body structure changes (e.g. content-disposition, MD5)
  28.  
  29.  
  30.    o Discussion
  31.  
  32.       -  There are some IMAP primitives that do not return as much
  33.          information as would now be desirable.  For example, it would
  34.          be nice if the ENVELOPE structure included RESENT fields.
  35.          Moreover, the BODY structure does not return
  36.          content-disposition or MD5 information.
  37.  
  38.       -  Modifying the existing primitives will break existing IMAP
  39.          software; therefore, new functionality often implies a new
  40.          primitive.
  41.  
  42.       -  There is a difference between defining a protocol extension and
  43.          defining a protocol extensibility mechanism.  When considering
  44.          the need to accommodate protocol evolution, it would be ideal
  45.          to define a mechanism that would allow ``old'' clients to
  46.          discover new fields and do something useful with them.  But
  47.          this is not viewed as a realistic expectation because how the
  48.          new values would be presented to the client depends upon the
  49.          type of data, and fully describing the data type, whether or
  50.          not it is parsed or presented literally, etc., can lead to an
  51.          overly complex protocol.  (In short, a simple name=value
  52.          property list is not sufficient.)
  53.  
  54.       -  Even if we cannot build a client that will never have to be
  55.          updated, (to track protocol evolution), at least we should
  56.          strive to minimize the need to change clients and servers at
  57.          the same time.  We can define new primitives in such a way that
  58.          clients receiving *lists* of elements can interoperate with a
  59.          new server that will return more elements in the list than the
  60.          client understands.  That is, the primitive is specified so
  61.          that the client will discard list elements beyond those it is
  62.          expecting, rather than choke on them.
  63.  
  64.       -  In order to accommodate MIME evolution, it is proposed that a
  65.          new BODY type be defined along the above lines.  It will return
  66.          an S expression list including newly defined MIME elements, and
  67.          will have new list elements defined over time as needed.
  68.  
  69.       -  Doing the same thing for the ENVELOPE data structure was
  70.          thought to not be worth the effort because there is now a
  71.          primitive to fetch arbitrary groups of header lines---although
  72.          they are returned as unparsed strings.  ENVELOPE contains
  73.          information to aid the client (e.g.  by pre-parsing the basic
  74.          addresses), but a client can request all or any headers using
  75.          other primitives.  While this places an additional burden on
  76.          the client to be able to parse these other header lines, that
  77.          burden is not considered more egregious than the effort to
  78.          implement an ENVELOPE2 structure.
  79.  
  80.  
  81.    o Action
  82.  
  83.       -  Define ``BODY2'' which will allow for unanticipated fields.
  84.  
  85.       -  Part 0 (zero) in encapsulated messages is defined to mean
  86.          header.
  87.  
  88.       -  No change re ENVELOPE.
  89.  
  90.  
  91.  
  92. Issue 2:  Mstring Grammar
  93.  
  94.    o Discussion
  95.  
  96.       -  In RFC 1176, a FIND is defined to return ``* mailbox string''
  97.          but C-client actually returns ``* mailbox text-line''
  98.  
  99.       -  Change existing implementation to match specification?  Define
  100.          a new FIND?
  101.  
  102.  
  103.    o Action
  104.  
  105.       -  Table until other FIND issues (i.e.  namespace semantics) are
  106.          resolved.
  107.  
  108.  
  109. Issue 3:  BBOARDS are 2nd class citizens (cannot CREATE, APPEND, etc.)
  110.  
  111.    o Discussion
  112.  
  113.       -  What do the BBOARDs really do?
  114.           * Define a different namespace
  115.               +Global, rather than per-user
  116.           * Imply Read-Only (of course mailboxes *may* be Read-Only)
  117.  
  118.  
  119.    o Action
  120.  
  121.       -  Action deferred until the namespace semantics discussion.  If
  122.          that leads to a more general way to specify a namespace, then
  123.          the BBOARD construct becomes superfluous.
  124.  
  125.  
  126. Issue 4:  8Bit
  127.  
  128.    o Discussion
  129.  
  130.       -  Should IMAP have a way to transmit 8 bit characters?  Yes, if
  131.          the character set is discoverable, but No for the raw 822 text
  132.          case.
  133.  
  134.       -  Should IMAP allow unencoded binary transfer?  No, due to
  135.          robustness concerns about mixing binary transfer in an
  136.          ascii-oriented protocol.  Better to wait on this one,
  137.          especially in view of the null problem described below.  The
  138.          only real downside to encoding before transfer is the cost of
  139.          transmitting extra characters due to the encoding overhead.
  140.  
  141.       -  Should IMAP allow nulls in strings without Base64 encoding?
  142.          No, because so much software is based on the
  143.          ``null-terminated-string'' model, and tends to break when
  144.          presented with a null.  But clients should be encouraged to be
  145.          ``null tolerant'' in any case.
  146.  
  147.       -  Should IMAP allow 8bit characters in mailbox and flag names?
  148.          No, not yet.  Let the dust settle on other efforts to extend
  149.          Internet protocols to 8 bit rather than claiming to have the
  150.          answer.
  151.  
  152.  
  153.    o Action
  154.  
  155.       -  Revise page 34 to clarify intent per above discussion.
  156.  
  157.  
  158. Issue 5:  ``Optionals'' in the Specification
  159.  
  160.    o Discussion
  161.  
  162.       -  Having ``OPTIONALS'' tends to perpetuate disparity across the
  163.          set of IMAP servers.  We want to encourage all new servers (and
  164.          clients) to fully implement the new specification.  Hence make
  165.          all the primitives mandatory, but provide information on
  166.          backward-compatibility issues.  Also avoid using term
  167.          ``COMPATIBLE'' as this will be an invitation for sub-standard
  168.          implementations to claim IMAP2bis compatibility.
  169.  
  170.       -  Should primitives such as SUBSCRIBE really be mandatory?  Yes,
  171.          better to have a degenerate implementation that always returns
  172.          ``NO'' than to have a truly ``optional forever'' command.
  173.          (Note:  a full implementation of SUBSCRIBE may also have
  174.          occasion to return ``NO''.)
  175.  
  176.  
  177.    o Action
  178.  
  179.       -  Make all IMAP2bis primitives mandatory and create an appendix
  180.          documenting backward compatibility issues.
  181.  
  182.  
  183. Issue 6:  Versioning or Command Discovery
  184.  
  185.    o Discussion
  186.  
  187.       -  There are existing clients and servers with different
  188.          capabilities.  There will be new commands added over time.
  189.          Should IMAP have a way to discover what commands exist before
  190.          they are executed ``for real''?  Yes, but...
  191.  
  192.       -  Alternatives
  193.  
  194.           * Version string...  deprecated because advertised version may
  195.             not really match what is implemented in the software.  It is
  196.             an assertion of compliance to a certain level, but history
  197.             has shown many deviations.
  198.  
  199.           * Discovery command...  still some sentiment for this, but not
  200.             useful for clients/servers that predate the Discovery
  201.             command.  (Absence of Discovery command does not mean that
  202.             other commands, e.g.  CREATE, are missing.)
  203.  
  204.           * Define non-destructive, reversible behavior for all new
  205.             primitives, so that a client can test for their existence
  206.             before actually using them ``in action.''  Example:  CREATE
  207.             INBOX should return either BAD or NO, depending on whether
  208.             the server is old (does not know anything about CREATE) or
  209.             new (wherein that particular operation is an error.)
  210.  
  211.  
  212.    o Action
  213.  
  214.       -  Attempt to define safe ``probe'' operations for CREATE, DELETE,
  215.          RENAME, APPEND, etc.
  216.  
  217.  
  218. Issue 7:  IMAP Command Interruption
  219.  
  220.    o Discussion
  221.  
  222.       -  Would be nice, but assumes server will be listening while
  223.          sending.
  224.       -  Hard to do with TCP and Standard I/O-based software.
  225.       -  Therefore, widespread implementation is unlikely.
  226.  
  227.  
  228.    o Action
  229.  
  230.       -  None.
  231.  
  232.  
  233. Issue 8:  Returning Size Information So Client Can Present ``Progress
  234.           Bars''
  235.  
  236.    o Discussion
  237.  
  238.       -  Highly desirable.
  239.       -  Extremely hard to implement efficiently, to the point that it
  240.          is unlikely that a client could depend upon having the
  241.          information.
  242.  
  243.  
  244.    o Action
  245.  
  246.       -  Defer until someone proposes a sufficiently efficient solution
  247.          to expect widespread implementation.
  248.  
  249.  
  250. Issue 9:  Preserving flags/date on COPY, setting on APPEND
  251.  
  252.    o Discussion
  253.  
  254.       -  Should APPEND provide a way to set flags?  Yes.
  255.       -  Should COPY preserve flags?  Yes (if access controls allow).
  256.  
  257.  
  258.    o Action
  259.  
  260.       -  Change COPY definition to include SHOULD preserve flags.
  261.       -  Change APPEND definition to add *optional* argument for flags.
  262.  
  263.  
  264. Issue 10:  International error strings
  265.  
  266.    o Discussion
  267.  
  268.       -  Should the IMAP specification define a way for the client to
  269.          tell the server what language to use for messages?  No,
  270.          because...
  271.  
  272.       -  Internationalization is non-trivial.
  273.  
  274.       -  Server needs to be able to generate implementation-specific
  275.          messages, in whatever language it chooses.
  276.  
  277.       -  Maybe IMSP can tell the server what language the client likes?
  278.  
  279.       -  Best we can do is to make it easy for a client to
  280.          localize/modify messages from the server if it does not like
  281.          the default language...  see error codes!
  282.  
  283.  
  284.    o Action
  285.  
  286.       -  None.  (See error codes.)
  287.  
  288.  
  289. Issue 11:  Error codes
  290.  
  291.    o Discussion
  292.  
  293.       -  There will always be more error cases than can be specified in
  294.          the document.
  295.  
  296.       -  It would be nice if major categories were presented so that the
  297.          client could easily localize or make program flow decisions
  298.          (e.g.  TRYCREATE).
  299.  
  300.       -  You do not need a numeric code to achieve the above.
  301.  
  302.  
  303.    o Action
  304.  
  305.       -  An effort will be made to identify some common error cases and
  306.          define a short descriptor to go at the beginning of all
  307.          messages in the category, similar to [PARSE] and [TRYCREATE].
  308.          Unlike the rest of the error string, these would become
  309.          required constant parts of an error string.
  310.  
  311.  
  312. Issue 12:  TRYCREATE
  313.  
  314.    o Discussion
  315.  
  316.       -  Should TRYCREATE be part of solicited ``NO'' response on COPY
  317.          and APPEND? (Right now it is an *unsolicited* NO response) Yes,
  318.          because it is providing information tied specifically to the
  319.          COPY or APPEND operation.
  320.  
  321.  
  322.    o Action
  323.  
  324.       -  Change specification accordingly.
  325.  
  326.  
  327. Issue 13:  ISTRING/RFC 1342 SEARCH Argument
  328.  
  329.    o Discussion
  330.  
  331.       -  Multiple character set searches are a can of worms.
  332.  
  333.  
  334.    o Action
  335.  
  336.       -  John and Mark to take Peter's suggestions and come up with
  337.          revised text.
  338.  
  339.  
  340. Issue 14:  UID Operations for Disconnected Operation
  341.  
  342.    o Discussion
  343.  
  344.       -  Proposed UID operation definitions appear to be satisfactory,
  345.          for achieving the disconnected operation goal, but BEFORE does
  346.          not add much value...
  347.  
  348.  
  349.    o Action
  350.  
  351.       -  Drop BEFORE operation as superfluous.
  352.  
  353.  
  354. Issue 15:  UID Uniqueness
  355.  
  356.    o Discussion
  357.  
  358.       -  Regarding the desire to have UIDs be globally unique:  there is
  359.          a conflict between the global uniqueness goal and the goal of
  360.          having UIDs within a single mailbox always be ascending.
  361.          Global uniqueness is desirable if it allows detecting that a
  362.          message saved in different or multiple mailboxes is identical
  363.          to the one in the client cache.  However, it is not---in
  364.          general---possible to take an arbitrary message with a globally
  365.          unique ID, and *append* it to a different mailbox while
  366.          preserving the ``UIDs must be in ascending order with a
  367.          mailbox'' requirement.  (We ruled out the possibility of
  368.          inserting a message in the middle of a mailbox to preserve UID
  369.          ascendancy as this would violate user expectations, especially
  370.          for APPEND!)
  371.  
  372.       -  Conclude:  global uniqueness is desirable, but cannot be
  373.          required.  (Nor should it be forbidden in the specification.)
  374.  
  375.  
  376.    o Action
  377.  
  378.       -  Define UIDs as unique within a folder, but not necessarily
  379.          across folders.
  380.  
  381.       -  Note that globally unique UID will conflict with ``UIDs are
  382.          always ascending in a mailbox,'' assuming we always append/copy
  383.          rather than insert a message in the middle of a mailbox.
  384.  
  385.  
  386.  
  387. Issue 16:  RECENT Description
  388.  
  389.    o Discussion
  390.  
  391.       -  Current definition is incomplete/inconsistent
  392.  
  393.  
  394.    o Action
  395.  
  396.       -  Make wording changes on page 15 based on Peter's suggestions
  397.          (avoid word ``new'' in RECENT defn; specify read-only case).
  398.  
  399.  
  400.  
  401. Issue 17:  New SEARCH
  402.  
  403.    o Discussion
  404.  
  405.       -  Understood to be needed
  406.       -  A starting point for a definition:
  407.           * Be able to search on Composed DATE
  408.           * Be able to search on Received DATE
  409.           * Be able to search on MessageID
  410.           * Be able to search on general header text
  411.           * Not operator
  412.           * Deprecate ``UN...'' constructs
  413.           * OR operator
  414.           * Operator grouping
  415.           * If not regular expressions, at least wild cards in strings
  416.           * Better international searching
  417.  
  418.  
  419.    o Action
  420.  
  421.       -  Solicit IMAP developers to flesh out a detailed proposal for
  422.          new SEARCH.
  423.  
  424.  
  425.  
  426. Issue 18:  Mailbox Reorder
  427.  
  428.    o Discussion
  429.  
  430.       -  Legitimate reasons to want to (permanently) reorder a mailbox,
  431.          but hard to anticipate all possible sort requirements...
  432.  
  433.       -  COPY provides a moderately efficient way for client to create a
  434.          new mailbox in the order desired by the client.
  435.  
  436.       -  For now, best to leave as a client issue.
  437.  
  438.  
  439.    o Action
  440.  
  441.       -  None now; revisit if support for sorted/filtered views is ever
  442.          added.
  443.  
  444.  
  445.  
  446. Issue 19:  Sorted/Filtered Views
  447.  
  448.    o Discussion
  449.  
  450.       -  A goal of some clients is to present to the user (possibly
  451.          multiple) message selections (subsets) in an order other than
  452.          the natural order of the mailbox.
  453.  
  454.       -  A perennial question is how much support should the protocol
  455.          and server provide to the client for this type of situation.
  456.  
  457.       -  This is (as is often the case) a performance tradeoff.
  458.          Client-based sorts, even if based only on header information,
  459.          can be quite time-consuming on current desktop hardware.
  460.  
  461.       -  A downside of trying to do this on the server is that the
  462.          protocol must anticipate all the potentially interesting sort
  463.          and selection criteria.
  464.  
  465.       -  An open question is whether increasing desktop computer
  466.          performance, relative to per-user server performance, will
  467.          mitigate the need for server-based processing; however,
  468.          server-based search/selection is expected to remain important,
  469.          especially when connecting via low-speed lines.
  470.  
  471.  
  472.    o Action
  473.  
  474.       -  Defer for further study.
  475.  
  476.  
  477.  
  478. Issue 20:  Message Annotation
  479.  
  480.    o Discussion
  481.  
  482.       -  It would be desirable to allow messages to be annotated,
  483.          perhaps with keywords, perhaps with additions to the text.
  484.  
  485.       -  It has been proposed that it be possible to rewrite a message
  486.          in a mailbox (with additional flags or annotations) without
  487.          having to delete the original version and append the new
  488.          version to the end of the mailbox, as the change of mailbox
  489.          order is undesirable.  Unfortunately, this approach to
  490.          annotation is at odds with disconnected operation, wherein it
  491.          is expected that the client cache copy of a message matches the
  492.          original.  If the content of the original changes, so should
  493.          the UID, but then it cannot stay in the same place in the
  494.          mailbox without violating the ``UIDs must be in ascending
  495.          order'' rule.
  496.  
  497.       -  Additional work must be done to explore alternatives for
  498.          annotation, whether they be via a ``threads'' model, or
  499.          external annotation by reference, or invalidation and
  500.          regeneration of UIDs...
  501.  
  502.  
  503.    o Action
  504.  
  505.       -  Defer for further study.
  506.  
  507.  
  508.  
  509. Issue 21:  Accessing Definitive Address of Message Originator
  510.  
  511.    o Discussion
  512.  
  513.       -  It is desired that client can obtain the SMTP envelope address
  514.          most likely to definitively get a reply back to originator.
  515.  
  516.       -  Some delivery agents do terrible things to the SMTP envelope
  517.          addresses, e.g.  when the delivery agent creates a ``From''
  518.          address.
  519.  
  520.       -  RFC 1123 (Sec 5.2.8) requires the receiver SMTP to make the
  521.          ``MAIL FROM:'' address of the SMTP envelope available via the
  522.          Return-Path header line.
  523.  
  524.       -  IMAP specification allows fetching individual header line (e.g.
  525.          Return-Path) even though it is not part of the IMAP envelope
  526.          structure.
  527.  
  528.  
  529.    o Action
  530.  
  531.       -  None.  Current IMAP behavior is sufficient if host adheres to
  532.          RFC 1123.
  533.  
  534.  
  535. Issue 22:  Concern About Lack of Multi-Threading
  536.  
  537.    o Discussion
  538.  
  539.       -  A concern was reported having to do with accessing multiple
  540.          mailboxes/views at the same time.  The concern was that this
  541.          might not be possible in IMAP because IMAP does not have
  542.          multiple threads on a single connection.
  543.  
  544.       -  It is believed that this concern is a misunderstanding.  While
  545.          an IMAP stream does map to a single TCP connection, it is
  546.          acceptable and often desirable to have multiple streams open
  547.          concurrently.  Existing IMAP clients routinely allow access to
  548.          multiple mailboxes concurrently.
  549.  
  550.  
  551.    o Action
  552.  
  553.       -  None needed.
  554.  
  555.  
  556. Issue 23:  Namespace Semantics and Hierarchy Support
  557.  
  558.    o Discussion
  559.  
  560.       -  This one's long...  a separate document will be forthcoming.
  561.  
  562.  
  563.    o Action
  564.  
  565.       -  Develop a detailed plan for how a context-free name scheme
  566.          could adequately support hierarchy.
  567.  
  568.       -  Define hierarchy primitives desired in c-client API.
  569.  
  570.       -  Compare/assess tradeoffs between implementing hierarchy in the
  571.          client vs.  adding protocol support for it.
  572.  
  573.  
  574. Summary of Items From 3/93 BOF
  575.  
  576.    o Support for disconnected operation
  577.    o Off-line sorting of mailbox
  578.    o Background server searching and sorting
  579.    o Shared mailbox per-user state (like a .newsrc, but for mailboxes)
  580.    o Function to determine where to submit messages
  581.    o Storage/retrieval of MUA configuration data
  582.    o Minimal non-plaintext authentication
  583.    o Minimal confidentiality (XOR with shared secret)
  584.    o Test assertion that PEM does not affect IMAP
  585.    o Remote printing (from IMAP server's copy of message)
  586.    o Improved searching
  587.  
  588.  
  589. Summary of Items From 7/93 Working Group Meeting
  590.  
  591.    o Disconnected operation support, a la DMSP, continues to be widely
  592.      desired.
  593.    o There is considerable interest in using IMAP to access message
  594.      archives.
  595.    o Several people asked about extensions to support binary message
  596.      part access, without Base64 or QP encoding:
  597.       -  Possible?
  598.       -  Impact on s-expression model?
  599.       -  Can unencoded binary attachments be transferred without charset
  600.          concerns?
  601.    o The question of signalling when large blocks of data are being
  602.      transferred:
  603.       -  Congestion of pipe; need to have multiple channels or
  604.          out-of-band signals
  605.    o Can we have an IMAP server capabilities command, a la new SMTP?
  606.    o Be sure to look at URL/I work before settling on unique message ID
  607.      scheme.
  608.    o Is IMAP a distribution list alternative:  shared but limited access
  609.      mailbox?
  610.    o Can IMAP ``integrate'' two mailboxes (remote mail archive plus
  611.      local subset)?
  612.    o Should IMAP become ``Interactive Message Access Protocol''?
  613.  
  614.  
  615. Summary of Items From 6/92 CMU-UW Meeting
  616.  
  617.    o Clearly needed IMAP futures:
  618.       -  Fetch partial text
  619.       -  Add create, delete, rename folder
  620.       -  Clarify find folder semantics
  621.       -  Put/append
  622.       -  Subscribe/unsubscribe
  623.    o Functions needed with multiple IMAP servers:
  624.       -  Directory service
  625.    o Desired, but deferred:
  626.       -  Search multiple mailboxes on multiple servers
  627.       -  Put/replace
  628.       -  Extend IMAP to subsume DMSP (Disconnected operation)
  629.       -  Add IMAPd driver to access arbitrary files
  630.    o Possibilities outside the scope of remote mailbox access:
  631.       -  Change password
  632.       -  Get disk usage
  633.       -  Get disk quota
  634.       -  Set disk quota
  635.       -  Change protections on folder
  636.       -  Message posting facility (Send via other than SMTP?)
  637.    o Believed to be upward-compatible changes:
  638.       -  Disconnected operation
  639.       -  Internationalization of error strings (add numbers while we're
  640.          at it?)
  641.       -  Internationalization of search strings
  642.       -  Server generated browser lines?
  643.    o Extensions where old functions must be retained for compatibility:
  644.  
  645.       -  More powerful search command
  646.       -  New envelope fetch with additional headers
  647.    o Possibly incompatible changes:
  648.       -  8-bit operation
  649.       -  Using unique IDs as fundamental key instead of sequence number
  650.       -  Rename fetch operations for greater clarity
  651.       -  Return additional fields after a mail_find(), e.g.  count,
  652.          unseen count
  653.    o Low bandwidth issues (outside the scope of Remote Mailbox
  654.      Manipulation):
  655.       -  Printing messages from server
  656.       -  Forwarding messages from server
  657.  
  658.  
  659. Part 1:  Background/Overview
  660.  
  661.    o Goal
  662.  
  663.      Our System (servers, clients, protocol) must support hierarchy and
  664.      collections in a consistent way across different clients (and
  665.      ideally across different servers as well).
  666.  
  667.    o Approaches
  668.  
  669.       1. Client gets to pick its own hierarchy model, treating server
  670.          namespace as ``flat''---that is, it only sends and receives
  671.          context-free (?)  names, and any notion of hierarchy is ``in
  672.          the eye of the client.''  The server must figure out how to
  673.          accommodate the client's view if/when it conflicts with
  674.          server's natural hierarchy.
  675.  
  676.       2. Server has a natural hierarchy mechanism; client discovers and
  677.          exploits the server's natural hierarchy.
  678.  
  679.       3. Protocol defines a lowest-common-denominator hierarchy model
  680.          that is believed to be useful for most clients and
  681.          implementable on most servers.
  682.  
  683.  
  684. Options 1 and 2 are not mutually exclusive.  That is, from a protocol
  685. perspective, one can imagine a design that would allow either a client
  686. having its own view of hierarchy, interacting with the server only via
  687. flat (context-free) names, while also allowing other clients to discover
  688. and use the servers' natural hierarchy.  However, consistent behavior
  689. across clients remains an important goal.
  690.  
  691.    o Issues
  692.  
  693.       1. Defining scope of name set to be returned by FIND. It is
  694.          essential that the client be able to bound the scope of a FIND
  695.          search, both on the ``prefix'' and ``suffix'' sides of the
  696.          search string.  (Note:  c-client FIND does not implement the
  697.          IMAP specification because it does not follow directories at
  698.          the moment.  This needs to be fixed for clients implementing
  699.          Approach #1, but those implementing Approach #2 will then need
  700.          a new mechanism to bound the search to a single directory.)
  701.  
  702.       2. Defining what server will do with ``directory'' names found
  703.          within the specified scope.  A non-terminal name must be
  704.          distinguishable from a terminal name.  Alternatives for FIND
  705.          include:
  706.  
  707.         (a) Return an attribute for non-terminal names designating them
  708.             as such.
  709.  
  710.         (b) Ignore non-terminal names; define new primitive to find
  711.             them.
  712.  
  713.         (c) Return non-terminal names with the hierarchy delimiter
  714.             included.
  715.  
  716.         (d) Server flattens namespace and traverse directories,
  717.             returning only context-free names.  (This supports only
  718.             approach #1.)
  719.  
  720.       3. There is a distinction between hierarchy created by the user
  721.          and hierarchy that is pre-existing (designed by someone other
  722.          than the user, as in an anonymous archive or netnews
  723.          hierarchy).
  724.  
  725.       4. A mechanism is needed for common name semantics across clients.
  726.          We all agree that it's really important that different clients
  727.          can see a common view of the same namespace.  If namespace
  728.          semantics are not an inherent characteristic of the protocol,
  729.          nor is there a way to discover it via protocol primitives, then
  730.          there must be an external agreement on how to describe
  731.          hierarchy, and a mechanism for clients to share hierarchy
  732.          definitions.  IMSP has been suggested as one way various
  733.          clients could access a common hierarchy definition.
  734.  
  735.       5. Clients should not have any built-in knowledge of server file
  736.          system semantics.  They should be able to discover what they
  737.          need to know from the server or from client config information.
  738.  
  739.       6. If the conversation with the client is via context-free names,
  740.          a client needs to be able to easily recombine locally
  741.          maintained context information, e.g.  prefixes, with FIND
  742.          responses in order to generate arguments for SELECT and other
  743.          primitives.
  744.  
  745.  
  746. There was not much support for building a ``lowest common denominator''
  747. model of hierarchy into the protocol, so the discussion centered on
  748. approaches #1 and #2.  Number 1, where hierarchy is in the ``eye of the
  749. client'' came to known as the ``flatlander'' view, since names going to
  750. and from the server are always flat (context-free) names.  Approach #2,
  751. wherein the client discovers and uses the natural hierarchy of the
  752. server is referred to below as ``server exported hierarchy.''  As you
  753. will see, neither approach is without problems.
  754.  
  755.  
  756.  
  757. Part 2:  Summary of the Two Leading Alternatives
  758.  
  759.    o Two models:
  760.  
  761.       -  Flatlander
  762.       -  Server Exported Hierarchy
  763.  
  764.    o Flatlander
  765.  
  766.       -  Server flattens any internal hierarchy in FIND. Current
  767.          c-client bezerkely behavior is a bug--it needs to recurse down
  768.          directories.
  769.  
  770.       -  CREATE needs to automatically create any necessary internal
  771.          directories.  The client does not know the internal structure
  772.          of the server and cannot be expected to create internal
  773.          directories.
  774.  
  775.          The directory structure may limit the ability to create certain
  776.          named objects because of internal hierarchical limitations
  777.          (e.g., a unix based server which maps .  to / may not allow ..
  778.          because // can not be maped to the unix filesystem.)  or for
  779.          other administrative reasons.
  780.  
  781.       -  Need a facility for clients to limit results of FIND results to
  782.          substring matches based on hierarchical delimiters.
  783.  
  784.          Proposal:  extension to FIND to allow the client to specify a
  785.          set of 'stop' characters:
  786.  
  787.          a FIND ALL.MAILBOXES comp.* ./
  788.          MAILBOX comp.ai
  789.          MAILBOX comp.lang.
  790.          MAILBOX comp.baz/
  791.          a OK Done
  792.  
  793.          comp.ai is a folder.  There are folders which start with
  794.          ``comp.lang.''  and ``comp.baz/'' but a subsequent FIND is
  795.          necessary in order to find out what they are.  The
  796.          non-terminals can be identified as such by the fact that they
  797.          are both longer than the prefix and end with a stop character.
  798.          They could alterately be identified by using either a new
  799.          unsolicited reply for non-terminals or by IMSP-style
  800.          attributes.
  801.  
  802.       -  The set of stop characters is a client configuration problem.
  803.          A client can start with a ``default'' set (probably ./\) which
  804.          is modified by a configuration file or IMSP option.  (John
  805.          Myers view:  Netnews convention will eventually just win)
  806.  
  807.  
  808.   TEG Comment:  The default set of stop characters is a problem.
  809.   On a single IMAP server, it is possible to have multiple
  810.   hierarchies using different stop characters, e.g.  netnews with
  811.   a dot, and a Unix filesystem with a slash.  There may be cases
  812.   where having multiple stop characters makes sense, but I
  813.   certainly do not want all the dots in my Unix file names to be
  814.   interpreted as hierarchy delimiters.  (And the existence of
  815.   zillions of files with dots in their names makes me skeptical
  816.   of John M's prediction that dot will win out as the one true
  817.   hierarchy delimiter.)
  818.  
  819.  
  820.    o Drawbacks:
  821.  
  822.       -  There is no way to create empty non-terminals which persist.
  823.          If a folder browser was used to create a ``directory,'' the
  824.          client would have to handle that information virtually.  If the
  825.          user did not subsequently create a mailbox in that directory,
  826.          the virtual directory would not persist across sessions.
  827.          (Chris Newman proposal:  add concept of ``namespace extender,''
  828.          which can be manipulated through the protocol.  A client could
  829.          create the placeholder ``comp.lang.''  which is neither a
  830.          folder nor the initial substring of a folder, but shows up as a
  831.          non-folder when doing FIND with a (possibly empty) set of stop
  832.          characters.)
  833.          Counterpoint:  in some domains, such as netnews, the concept of
  834.          an empty nonterminal does not exist.  Either the concept would
  835.          have to be hacked on top of the domain or users would see
  836.          inconsistent behavior.  Is the feature worth the cost?
  837.    
  838.       -  An anonymous IMAP server may have a pre-defined hierarchy for
  839.          its data with stop characters which are unknown to the client.
  840.          One possible solution would be for anonymous IMAP servers to
  841.          use one of the ``default'' stop characters for any predefined
  842.          hierarchy.  Another solution would be for the anonymous IMAP
  843.          server to have an IMSP server which advertises the appropriate
  844.          stop characters.
  845.          (reluctant proposal:  Add a wart to the protocol to obtain the
  846.          set of separator characters.)
  847.    
  848.       -  The ``stop character'' mechanism will view a VMS-style
  849.          namespace in an unexpected way.
  850.          The namespace can still be used and viewed in a hierarchical
  851.          manner.
  852.    
  853.       -  Flattening out some namespaces may take an inordinate amount of
  854.          resources.
  855.          e.g.  FIND /* in c-client berkeley driver will thrash server.
  856.          This problem exists in other domains (e.g.  SEARCH BODY) and is
  857.          usually solved with administrative limits on such things as
  858.          depth of search, CPU use, or total number of matches.
  859.    
  860.  
  861.    o Server exported hierarchy:
  862.    
  863.       -  Need server determined directory concept MKDIR, RMDIR commands
  864.          Drawback:  in some domains, such as netnews, the concept of
  865.          creating and removing directories does not exist.
  866.    
  867.       -  NFIND returns both folders and directories.
  868.          Does not recurse down directories.
  869.    
  870.       -  Still need flatlander view
  871.          Flatlander clients
  872.          Folder discovery (FIND *mail* or similar)
  873.          Flatlander FIND needs to return directory structure information
  874.    
  875.       -  Client needs to know the characteristics of the namespace.
  876.          Protocol has to mandate restrictions on the namespace and/or
  877.          communicate to the client those characteristics which are not
  878.          mandated.
  879.    
  880.          In order to implement a Macintosh-style folder browser or a
  881.          hierarchical browser, client needs to obtain fully qualified
  882.          name from directory and relative name components.  In order to
  883.          enter such a browser from a flatlander search or Pine-style
  884.          rubber-room path, client also needs to know how to obtain the
  885.          sequence of relative names to get to a fully qualified name.
  886.          This suggests two commands, JOINPATH and EXPANDPATH.
  887.    
  888.          Drawbacks:  Mandated restrictions will prohibit servers from
  889.          exporting otherwise useful views.  Attempting to describe
  890.          characteristics which have insufficient restrictions is overly
  891.          complex.  This leaves the possibility of a ``convert between
  892.          relative and absolute paths'' command.
  893.    
  894.          Examples:  In the VMS namespace, the absolute path name:
  895.    
  896.                              sys$user:[bovik.foo]bar
  897.    
  898.          converts to the relative name sequence:
  899.    
  900.                                 sys$user:[000000]
  901.                                 [bovik]
  902.                                 [.foo]
  903.                                 bar
  904.  
  905.  
  906.    o Drawbacks:
  907.  
  908.       -  IMSP server has to know about the characteristics of the
  909.          namespaces for its IMAP servers.
  910.  
  911.  
  912.    o Comments:
  913.  
  914.       -  CD/PWD is orthogonal to hierarchy, except in that they provide,
  915.          as a side effect, a JOINPATH mechanism.  They are not
  916.          sufficient to provide a EXPANDPATH mechanism.
  917.  
  918.  
  919. Part 3:  Elaboration of Hierarchy Support Issues for VMS Namespaces
  920.  
  921. This comes from a view that the server needs to export its hierarchy to
  922. the client.  If restrictions were put on the hierarchy such that
  923. assumptions could be made about the namespace and a namespace like the
  924. VMS filesystem were disallowed this would not be as bad.
  925.  
  926. The basic problem in the hierarchy view of the world is how to represent
  927. a hierarchical namespace such as VMS. In VMS you have a hierarchy that
  928. looks like:
  929.  
  930.  
  931.                     for the file:
  932.                     sys$user:[wally.foo.bar]baz.txt;1
  933.  
  934.  
  935. the relative hierarchy used by something like a cd command:
  936. (all the devices and logicals which you cannot find with a dir command)
  937.  
  938.  
  939.                             sys$user:[000000]
  940.                             [wally]
  941.                             [.foo]
  942.                             [.bar]
  943.                             baz.txt;1
  944.  
  945.  
  946. And their fully qualified names for discovery:
  947.  
  948.  
  949.                     sys$user:[000000]
  950.                     sys$user:[wally]
  951.                     sys$user:[wally]foo.dir;1
  952.                     sys$user:[wally.foo]bar.dir;1
  953.                     sys$user:[wally.foo.bar]baz.txt;1
  954.  
  955.  
  956. To use this namespace from an FTP client you need to know something
  957. about the namespace.  For example, to properly represent a VMS namespace
  958. fetch knows that mail.dir;1 should be shown to the user as [.mail].
  959.  
  960. In your pine client you want to be able to jump to a ``rubber room'' in
  961. the namespace given a name in a config file.  Now if you specified that
  962. you wanted to jump to:
  963.  
  964.  
  965.                         sys$user:[wally.foo.bar]
  966.  
  967.  
  968. A macintosh folder browser would want to fill in the bottom parts in the
  969. pop of menu denoting where in the namespace you are in.  Fetch cannot do
  970. this, so shows you the places you cd'ed from and then a special ``parent
  971. directory'' marker.  It also gets confused frequently, especially if I
  972. cd to the parent directory which is sys$user:[0000000].
  973.  
  974. Also to continue to support a flat namespace (which we would need very
  975. much), for something like *imap* to work you would need to be able to
  976. return hierarchy information.  This would be needed to fill a hierarchy
  977. map of the entire namespace or portion of the namespace.
  978.  
  979. So, given a name or pattern you need to return typed information of the
  980. name and its hierarchy, and the relative name from the previous level:
  981.  
  982.  
  983.           find *imap*
  984.  
  985.           sys$user:[000000] sys$user:[000000] (/directory)
  986.           sys$user:[wally] [wally] (/directory)
  987.           sys$user:[wally.foo] [.foo] (/directory)
  988.           sys$user:[wally.foo.bar] [.bar] (/directory)
  989.           sys$user:[wally.foo.bar]imap.txt;1 imap.txt (/folder)
  990.  
  991.  
  992. This is the hierarchical tree for imap.txt;1.  Now this does not explain
  993. it if there are multiple ways of getting there in the tree and probably
  994. is more complicated than it is being explained.
  995.  
  996.