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 Document Editors: John Myers Matt Wall Meeting Minutes: Steve Hole --- 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. <>- 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.