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