Editor's note: These minutes have not been edited. ACAP Bof Reported by Matt Wall and Dirk-Willem van Gulik Draft agenda - IETF Montreal 96. 1. Agenda. No amendments to the agenda. 2. ACAP, Brief introduction. As most people present apeared to have read the draft only a brief introduction into ACAP is given by ChrisM. Essentially at Carnegie Mellon university experince with a campus wide mail system is build upon. This system ensures that a clients mailbox, configuration and addressbook files follow the user from machine to machine. Unlike DHCP, It is geared towards individual users; which have a certain degree of control over their configuration files, and can actually change values and entries; rather than geared towards system administrators control. Furthermore it has more advanced access controls and, to keep the clients relatively lightweight features like server side sorting and virtual scrolling have been added. Various comments focus on the question why (yet) another protocol is needed; and any charter and/or draft should at least have a good justification and position statements towards DHCP, SNMP, ... and similar protocols which could do something quite familliar. Chair believes is a specific task/hole/need for this level of configuration; this is on the level of a User, which control their own sections/data; rather than IP addresses etc... Several people point out that quite a toolkit is needed to maintain all this information, keep things in sync. Especially when there is a certain overlap with DHCP and other (configuration) databases. But the ensuing conversaion on API is kept short; it is felt to be more desirable, in the IETF, to document a Wire protocol. It is suggested that, since this protocol is supposed to be lightweigt on the side of the client; an appendix of the draft might detail a minumum client. However it is stated that the server implementations are not going to be lightweight. Some discussion on the relatively simple flat storage model which has very little typing and no language support or UTF8/ charset negotiation. A further discussion on support for multi value attribute sets, and how the user can set/read single values, is kept short with reference to the mailing list. It is pointed out by KeithM that solutions which simply label, even if the label is UNKOWN, a charsets are perhaps preferable to negotiation and default assumtions. Some consensus is reached on the uniqueness of the IDs for, say, Users. The chair points out that the deployment is typically on entriprize level; and Dave Crocker ? suggest, from experience in the internet mail consortsium, to draw the line near; not to solve the global naming; but get some ops experience first. 3. Charter, MattW. It is felt that an explicit dataset description is lacking. This will be added to the draft. Furthermore it is better to describe a general protocol first, followed by extensions by dataset. It could be split into seperate papers, but there are currently few datasets. It is noted that a registration mechanism for new dataset extensions, or conformance rules, BNF notations or other guidelines are absent in the draft. With regards to te charer, the 3rd pagragraph 'The-Goal.. adressbook' should be moved to the top; it is a good introduction. Furthermore should a position statement towards LDAP, DHCP etc be in the charter as well ? 4. John M takes chair; issues with the draft itself; Matt tries to justify the provisions to handle big lists (such as a hotlist or addressbooks) which is at odds with simplicity. Furthermore the sorting of those lists sparks off a discussion on internationalization and labeling. It is noted that it is diffult to draw the line between some of the described services and, local scale, directory services such as LDAP or WHOIS++. Certain implementations are envisioned at which databases are shared, further fuzzyfing the distinction. It is noted that the change command and interaction with pending virtual scrollbars might need some further work. Also, although access control lists are in, authorization is missing; it is something to perseu but it should not have such priority as to hold up the work. Clarifications of setting/changing values and attributes, typing, choises for advisory locking mechanisms, all ops are atomic (disk- write) ops. Some discussion about failure modes, keeping of history, last mod info. Larry Osterman? brings up several impl. issues regarding datastructure with various types of relations/inheritance for things such as defaults and write access. Added since last drafts - overide rigts, permits shadoing datasets to change value; can the user(group) change/override that value personally, for himself. - try- server special info token for referrals. The question is raised wether should you not use something like the SRV record. Also it is advised to stick a port number into the referral. - an attribute in the dataset list conains name of the dataset this entry is shadowing. Pending work - Dataset namespace /option/user/fred, /addressbook/user/fred... - Attribute namespace subcription, phone.work. fax.home Open Issues - Multi Value attr. (but we are aiming for single value, no one has convinced us sofar) - Sorting problems.. - Charset negot / vs / UTF8 Dealing with multi-ling strings. Octed seq spec. a specific charset. UTF8 might be a nice escape hatch; charset negotiation is that it does not work (well), server/clients have to know all charsets and have all mappings. Ned Freed ? points out that together with labeling a workable solution arrizes, but also that especially representing personal names is always a sensitive issue. - Attribute metda data e.g. a langu tag skipped in the interest of time :-) - Interaction between glob/ordering skipped in the interest of time :-) - How to create/delete/rename datasets; by manipulations of the root/mother one. - i,c and d rights on datasets; rather than on atributes. - NOTIFYCONEXT on contexts created from contexts; asking for synced updates; put a restriction in there ? - wildcards on RETURN - what rights are necessary to LOCK an entire dataset - DELETEDFROM response untagged or intermediate 5. Closedown - Chris takes chair again. Mail[request] list: ietf-acap[-request]@andrew.cmu.edu char-set issue: HaraldA, UTF8 is a step forward; if you start also putting charset in; then you have the same can of problems. KeithM; UTF8 mandatory, but you may add charsets; extension possibility. Closedow Action Itmes Revise charter, Matt Wall ACAP vs Others Matt Wall Above Submit to list by 7/31 Revised draft; John Myers, 8/31 list discuss items open issues name registeration specif datasets bookmorks options adressbooks dictionary API doc, left open Security/ACL model, in Sec. Considarations section of the draft Addentum to draft with simple client implementation Intention for Proposed standard January 97 ----- Chris Newman <chrisn+@cmu.edu>, <http://www.contrib.andrew.cmu.edu/~nifty/> U.S. Citizens: Ask your representatives to support S.1587/S.1726/HR.3011 for a right to Internet privacy and encryption.