home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / acap / acap-minutes-96dec.txt < prev    next >
Text File  |  1997-01-30  |  10KB  |  270 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.                      ACAP Working Group Meeting Minutes
  4.                      San Jose IETF Meetings, Dec 11, 1996
  5.  
  6.  
  7. Working Group Chair:     Chris Newman <chris.newman@innosoft.com>
  8.  
  9. Document Editors:        John Myers <jgm+@cmu.edu>
  10.                          Matt Wall <wall+@cmu.edu>
  11.  
  12. Meeting Minutes:         Steve Hole <steve.hole@esys.ca>
  13.  
  14. ---
  15.  Q: = question
  16.  A: = answer - resolved issue
  17.  D: = discussion - unresolved issue
  18.  
  19.  
  20. ---
  21. 0.  Chris Newman reviews agenda.
  22.  
  23.     1.  Administrivia - Chris Newman
  24.     2.  Update of the reference implementation - Rob Earhart
  25.     3.  Update on protocol specification - John Myers
  26.     4.  Address book schema design team results - Terry Gray
  27.  
  28.  
  29. ---
  30. 1.  Chris reviews history of ACAP working group
  31.  
  32.    - discussion of basic IMSP requirements
  33.    - discussion of IMSP shortcomings addressed by ACAP
  34.    - discussion of new requirements discovered from IMSP experimental work.
  35.    - the overview notes are available at:
  36.      http://andrew2.andrew.cmu.edu/cyrus/acap 
  37.  
  38. Q:  Some questions about the interaction/overlap between ACAP 
  39.     and LDAP.  Mostly questions asking about the work that the 
  40.     ASID was doing in the same area as ACAP.   
  41.  
  42. A:  Chris notes that he and Tim Howes (ASID chair) agreed to come
  43.     up with a document that defines the domain of each service.  The
  44.     idea is to keep the services separate and distinct.
  45.  
  46.  
  47. ---
  48. 2.  Rob Earhart gives a summary of progress on ACAP reference server
  49.     implementation being done at Carnegie Mellon University (CMU).
  50.  
  51.    - basic protocol infrastructure is done
  52.    - ACAP search infrastructure is nearly done -- some small redesign is
  53.      currently under way.
  54.    - ACL and quota support is not there yet
  55.    - locking and notification not there yet
  56.    - projection is for an alpha release that incorporates the changes
  57.      discussed by the design team by the end of January.
  58.  
  59. Q:  What is the goal for the reference implementation.
  60.  
  61. A:  Rob discusses the phase I and phase II implementations of the
  62. server.  The phase I release is to investigate the implementation issues
  63. with ACAP, the second implementation is a "production" version.
  64.  
  65.  
  66. ---
  67. 3.  John Myers reviews recent changes introduced by the design team. 
  68.  
  69. Much work was done by the design team at the IETF meeting prior to the
  70. working group session, reviewing issues that reached consensus on the
  71. list since the Seattle meeting, and developing proposals for the known
  72. open issues.
  73.  
  74. The results of the design team work include:
  75.  
  76.    -  decided to have a separate command for managing quotas.
  77.  
  78.    -  dataset metadata goes into attributes of the "" (empty string
  79.       name) entry in the dataset.   This fixes the issues with migrating
  80.       metadata to the parent dataset entry.
  81.  
  82.    -  ACL's for a dataset are stored the dataset.acl attribute in the ""
  83.       entry for the dataset.
  84.  
  85.    -  if there is no sort order in the search command, then the server
  86.       orders the result in an implementation specific manner.
  87.  
  88.    -  remove "ASTRING" syntax from the protocol.   All strings are either
  89.       quoted or literal strings.  John will review the ACAP protocol ABNF
  90.       to make sure that we don't introduce incompatibilities with IMAP4 by
  91.       attempting to simplify the protocol this way.
  92.  
  93.    -  the term "shadowing" is replaced by "inheritance" as it is more
  94.       descriptive of the mechanism.
  95.  
  96.    -  add a SASL capability list to the initial server response.
  97.  
  98.    -  add an extension syntax for new server responses.
  99.  
  100.    -  change the entry key attribute from "name" to "entry".
  101.  
  102.    -  the "NOTIFYCONTEXT" command is deprecated from a command to a modifier
  103.       on the search command.
  104.  
  105.    -  the GETACL and LISTRIGHTS commands are deprecated.   ACL data is
  106.       now stored as metadata on the attributes and is accessible via the
  107.       "SEARCH" command.
  108.  
  109.    -  metadata has been separated into two classes - those that will
  110.       cause the entry modtime to be changed when they are changed, and
  111.       those that will not result in a change to the modtime.
  112.  
  113. Q:  There is some confusion of exactly what metadata is supported for
  114.     attributes.  
  115.  
  116. A:  John reviewed the attribute metadata including which are
  117.     currently proposed, what they mean, how to fetch them and
  118.     store them.   The set of metadata items is not completely defined
  119.     yet. 
  120.  
  121.    -  the insert "i" rights allow you to add new attributes to an entry or
  122.       entries to a dataset.
  123.  
  124.    -  there are no delete "d" rights - subsumed by the write "w" right.
  125.  
  126.    -  there are no list "l" rights - subsumed by the read "r" right
  127.  
  128.    -  you delete an attribute  by storing the empty "" string value for
  129.       the attribute -- requires the "w" right.
  130.  
  131. Q:  A question was raised on whether you should be allowed to differentiate 
  132.     between the existence of an attribute with an empty value and no 
  133.     attribute at all.   The design team proposal was to make an
  134.     attribute with an empty value equivalent to no attribute.   
  135.  
  136. D:  Examples were given that indicated that having attributes with empty
  137.     values is important for the inheritance scheme.  The consensus was to
  138.     move this as an open issue to the list.
  139.  
  140.    -  return an error on fetch of an undefined attribute metadata item.
  141.  
  142.    -  entry ACLs are stored as metadata on the "entry" attribute of the
  143.       entry.
  144.  
  145.    -  dataset reference list is stored in the dataset entry in the parent
  146.       dataset.   It is a list of relative URL's that are relative to the
  147.       child dataset.
  148.  
  149.    -  Extend search to include subtree search rules:
  150.  
  151.       o  DEPTH modifier specifying a maximum depth in the hierarchy. 
  152.          DEPTH of 0 = infinite depth (no limit).
  153.  
  154.       o  LIMIT defines the number of results that are returned in
  155.          a search result.  Now contains two numbers - first is the maximum
  156.          number return on a successful search, the second is the number
  157.          to return if the search fails because the first number is exceeded.  
  158.  
  159. <<Editor's Note>>- for example if the LIMIT (20, 5) is specified, 
  160.          then up to 20 entries will be returned on a successful match.  
  161.          If the match would return more than 20 items, then an error is
  162.          returned along with the first 5 items of the search.   This is 
  163.          useful for doing type down addressing and other "completion"
  164.          lists operations.
  165.  
  166.       o  It is not possible to get a search context on a subtree search.
  167.  
  168.    -  LOCK takes a blocking timeout value.
  169.  
  170.    -  have a wildcard suffix for attribute names on RETURN().
  171.  
  172.    -  LOCK on a dataset requires "w" rights on at least one attribute of
  173.       of all entries.
  174.  
  175. Q:  There was discussion on the viability of the locking an
  176.     entire dataset.
  177.  
  178. D:  Consensus was to discuss further on the list because it was not clear
  179.     that there is a use at all for locking an entire dataset.
  180.  
  181.    -  Search orders are based on octet and are UNICODE case insensitive.  
  182.       Entries can include attributes for explicit client use in
  183.       ordering the data using client specified collation functions using
  184.       the attribute data.   This is sufficient to handle Yomi and other
  185.       user specified arbitrary sort orders specified by the client, and
  186.       still have sort order handled for more simple cases.
  187.  
  188. Question:  Some discussion on precendence and calculation of the MYRIGHTS
  189.            based on ACLs.   The conversation related to the use of
  190.            positive and negative ACL's and the rules for calculating the
  191.            resulting rights in the presence of both user and group rights.
  192.  
  193. John discussed the resolution of open issues with the current protocol
  194. specification that were not resolved by the design team.
  195.  
  196.    -  basically will bring the recent changes made to SASL into the base
  197.       specification. 
  198.  
  199. ---
  200. 4.  Terry Gray presented overview of the addressbook schema design group.
  201.  
  202.    -  presented the schema that Steve Hubert proposed and refined on the
  203.       on the design team mailing list. 
  204.  
  205. Q:  John Myers suggests that the virtual data of the address-expand (virtual)
  206.     data might be better done as metadata.
  207.  
  208. Q:  Ned suggested that we may want to include a "List Name" in the
  209.     schema to provide a public naming to a list.
  210.  
  211. Q:  An issue was raised that the LDAP Pilot Schema and the VCard Schema
  212.     would work nicely for the schema for ACAP abook entries.   A work
  213.     item was identified to make sure the schema would merge nicely with
  214.     the ACAP schema.
  215.  
  216. Q:  Discussion on having multiple email addresses for a person in an
  217.     entry for those users that have different addresses that are used
  218.     in different contexts.   Consensus was to defer this issue to the
  219.     list.
  220.  
  221. Q:  Discussion on other datasets being considered.  What dataset
  222.     definitions go into the base specification?   
  223.  
  224. A:  There is consensus to push dataset/entry/attribute definitions into
  225.     a separate document with a registration mechanism.
  226.  
  227.  
  228. ---
  229. SUMMARY
  230.  
  231. 1.  Open issues.
  232.  
  233.    - Should attributes with empty values be allowed and distinct from no
  234.      attribute at all.   The current proposal is to make them
  235.      equivalent, and not have an explicit delete command.
  236.  
  237.    - Is it useful to be able to lock an entire dataset?   Should ACAP
  238.      support this capability?
  239.  
  240.    - Should address book list expansions be stored as metadata on list
  241.      entry attributes?
  242.  
  243.    - Should a "list name" attribute be added to "distribution list"
  244.      entries for use as a public handle for MTA expansion?
  245.  
  246.    - Should an addressbook "person" entry support having more than one
  247.      email address for a person?
  248.  
  249.    - What datasets should be defined as the base set in the dataset
  250.      definition document?
  251.  
  252.  
  253. 2.  Action items.
  254.  
  255.    - Chris Newman, Tim Howes - work on a document defining the
  256.      relative scope of ACAP and LDAP.
  257.  
  258.    - John Myers - update the ACAP specification with the changes
  259.      discussed in the working group.
  260.  
  261.    - Chris Newman - post a message asking for pointers other "person"
  262.      being developed by other groups schemas.
  263.  
  264.    - Addressbook Schema Design Team - review other group schemas to
  265.      try to incorporate their specifications (if possible).
  266.  
  267.    - ?? - fill out design teams for the dataset definitions.
  268.  
  269.    - Chris Newman - find an editor for the dataset definition document.
  270.