Editor's note:  These minutes have not been edited.

                     ACAP Working Group Meeting Minutes
                     San Jose IETF Meetings, Dec 11, 1996


Working Group Chair:     Chris Newman <chris.newman@innosoft.com>

Document Editors:        John Myers <jgm+@cmu.edu>
                         Matt Wall <wall+@cmu.edu>

Meeting Minutes:         Steve Hole <steve.hole@esys.ca>

---
 Q: = question
 A: = answer - resolved issue
 D: = discussion - unresolved issue


---
0.  Chris Newman reviews agenda.

    1.  Administrivia - Chris Newman
    2.  Update of the reference implementation - Rob Earhart
    3.  Update on protocol specification - John Myers
    4.  Address book schema design team results - Terry Gray


---
1.  Chris reviews history of ACAP working group

   - discussion of basic IMSP requirements
   - discussion of IMSP shortcomings addressed by ACAP
   - discussion of new requirements discovered from IMSP experimental work.
   - the overview notes are available at:
     http://andrew2.andrew.cmu.edu/cyrus/acap 

Q:  Some questions about the interaction/overlap between ACAP 
    and LDAP.  Mostly questions asking about the work that the 
    ASID was doing in the same area as ACAP.   

A:  Chris notes that he and Tim Howes (ASID chair) agreed to come
    up with a document that defines the domain of each service.  The
    idea is to keep the services separate and distinct.


---
2.  Rob Earhart gives a summary of progress on ACAP reference server
    implementation being done at Carnegie Mellon University (CMU).

   - basic protocol infrastructure is done
   - ACAP search infrastructure is nearly done -- some small redesign is
     currently under way.
   - ACL and quota support is not there yet
   - locking and notification not there yet
   - projection is for an alpha release that incorporates the changes
     discussed by the design team by the end of January.

Q:  What is the goal for the reference implementation.

A:  Rob discusses the phase I and phase II implementations of the
server.  The phase I release is to investigate the implementation issues
with ACAP, the second implementation is a "production" version.


---
3.  John Myers reviews recent changes introduced by the design team. 

Much work was done by the design team at the IETF meeting prior to the
working group session, reviewing issues that reached consensus on the
list since the Seattle meeting, and developing proposals for the known
open issues.

The results of the design team work include:

   -  decided to have a separate command for managing quotas.

   -  dataset metadata goes into attributes of the "" (empty string
      name) entry in the dataset.   This fixes the issues with migrating
      metadata to the parent dataset entry.

   -  ACL's for a dataset are stored the dataset.acl attribute in the ""
      entry for the dataset.

   -  if there is no sort order in the search command, then the server
      orders the result in an implementation specific manner.

   -  remove "ASTRING" syntax from the protocol.   All strings are either
      quoted or literal strings.  John will review the ACAP protocol ABNF
      to make sure that we don't introduce incompatibilities with IMAP4 by
      attempting to simplify the protocol this way.

   -  the term "shadowing" is replaced by "inheritance" as it is more
      descriptive of the mechanism.

   -  add a SASL capability list to the initial server response.

   -  add an extension syntax for new server responses.

   -  change the entry key attribute from "name" to "entry".

   -  the "NOTIFYCONTEXT" command is deprecated from a command to a modifier
      on the search command.

   -  the GETACL and LISTRIGHTS commands are deprecated.   ACL data is
      now stored as metadata on the attributes and is accessible via the
      "SEARCH" command.

   -  metadata has been separated into two classes - those that will
      cause the entry modtime to be changed when they are changed, and
      those that will not result in a change to the modtime.

Q:  There is some confusion of exactly what metadata is supported for
    attributes.  

A:  John reviewed the attribute metadata including which are
    currently proposed, what they mean, how to fetch them and
    store them.   The set of metadata items is not completely defined
    yet. 

   -  the insert "i" rights allow you to add new attributes to an entry or
      entries to a dataset.

   -  there are no delete "d" rights - subsumed by the write "w" right.

   -  there are no list "l" rights - subsumed by the read "r" right

   -  you delete an attribute  by storing the empty "" string value for
      the attribute -- requires the "w" right.

Q:  A question was raised on whether you should be allowed to differentiate 
    between the existence of an attribute with an empty value and no 
    attribute at all.   The design team proposal was to make an
    attribute with an empty value equivalent to no attribute.   

D:  Examples were given that indicated that having attributes with empty
    values is important for the inheritance scheme.  The consensus was to
    move this as an open issue to the list.

   -  return an error on fetch of an undefined attribute metadata item.

   -  entry ACLs are stored as metadata on the "entry" attribute of the
      entry.

   -  dataset reference list is stored in the dataset entry in the parent
      dataset.   It is a list of relative URL's that are relative to the
      child dataset.

   -  Extend search to include subtree search rules:

      o  DEPTH modifier specifying a maximum depth in the hierarchy. 
         DEPTH of 0 = infinite depth (no limit).

      o  LIMIT defines the number of results that are returned in
         a search result.  Now contains two numbers - first is the maximum
         number return on a successful search, the second is the number
         to return if the search fails because the first number is exceeded.  

<<Editor's Note>>- for example if the LIMIT (20, 5) is specified, 
         then up to 20 entries will be returned on a successful match.  
         If the match would return more than 20 items, then an error is
         returned along with the first 5 items of the search.   This is 
         useful for doing type down addressing and other "completion"
         lists operations.

      o  It is not possible to get a search context on a subtree search.

   -  LOCK takes a blocking timeout value.

   -  have a wildcard suffix for attribute names on RETURN().

   -  LOCK on a dataset requires "w" rights on at least one attribute of
      of all entries.

Q:  There was discussion on the viability of the locking an
    entire dataset.
 
D:  Consensus was to discuss further on the list because it was not clear
    that there is a use at all for locking an entire dataset.

   -  Search orders are based on octet and are UNICODE case insensitive.  
      Entries can include attributes for explicit client use in
      ordering the data using client specified collation functions using
      the attribute data.   This is sufficient to handle Yomi and other
      user specified arbitrary sort orders specified by the client, and
      still have sort order handled for more simple cases.

Question:  Some discussion on precendence and calculation of the MYRIGHTS
           based on ACLs.   The conversation related to the use of
           positive and negative ACL's and the rules for calculating the
           resulting rights in the presence of both user and group rights.

John discussed the resolution of open issues with the current protocol
specification that were not resolved by the design team.

   -  basically will bring the recent changes made to SASL into the base
      specification. 

---
4.  Terry Gray presented overview of the addressbook schema design group.

   -  presented the schema that Steve Hubert proposed and refined on the
      on the design team mailing list. 

Q:  John Myers suggests that the virtual data of the address-expand (virtual)
    data might be better done as metadata.

Q:  Ned suggested that we may want to include a "List Name" in the
    schema to provide a public naming to a list.

Q:  An issue was raised that the LDAP Pilot Schema and the VCard Schema
    would work nicely for the schema for ACAP abook entries.   A work
    item was identified to make sure the schema would merge nicely with
    the ACAP schema.

Q:  Discussion on having multiple email addresses for a person in an
    entry for those users that have different addresses that are used
    in different contexts.   Consensus was to defer this issue to the
    list.

Q:  Discussion on other datasets being considered.  What dataset
    definitions go into the base specification?   

A:  There is consensus to push dataset/entry/attribute definitions into
    a separate document with a registration mechanism.


---
SUMMARY

1.  Open issues.

   - Should attributes with empty values be allowed and distinct from no
     attribute at all.   The current proposal is to make them
     equivalent, and not have an explicit delete command.

   - Is it useful to be able to lock an entire dataset?   Should ACAP
     support this capability?

   - Should address book list expansions be stored as metadata on list
     entry attributes?

   - Should a "list name" attribute be added to "distribution list"
     entries for use as a public handle for MTA expansion?

   - Should an addressbook "person" entry support having more than one
     email address for a person?

   - What datasets should be defined as the base set in the dataset
     definition document?


2.  Action items.

   - Chris Newman, Tim Howes - work on a document defining the
     relative scope of ACAP and LDAP.

   - John Myers - update the ACAP specification with the changes
     discussed in the working group.

   - Chris Newman - post a message asking for pointers other "person"
     being developed by other groups schemas.

   - Addressbook Schema Design Team - review other group schemas to
     try to incorporate their specifications (if possible).

   - ?? - fill out design teams for the dataset definitions.

   - Chris Newman - find an editor for the dataset definition document.