NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97
Chair(s):
Chris Newman <chris.newman@innosoft.com>
Matt Wall <wall@cyrusoft.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Mailing Lists:
General Discussion:ietf-acap+@andrew.cmu.edu
To Subscribe: ietf-acap-request+@andrew.cmu.edu
Archive: anonymous IMAP: cyrus.andrew.cmu.edu:archive.ietf-acap
Description of Working Group:
The goal of this working group is to define, specify, and develop the Application Configuration Access Protocol as a general access mechanism for per-user and per-server structured lists of information. In addition, the Working Group will specify how to use the protocol to store specific structured lists, initially application configuration options and address books.
The Application Configuration Access Protocol is a proposed solution to the problems of client configuration for users of the internet.
Given the increasing prevalence of network access points and rapidly increasing numbers of users with diverse needs and settings, there is a phenomenon of internet application users who typically connect from more than one physical location and/or operating system to use the same set of internet services and applications. These users must recreate sets of personal configuration information for each system, session, and location that they use. This may include information such as application options and preferences; personal or shared user data such as address books, bookmarks, or subscription lists; or shared data for internal client use, such as authorization group lists.
The products of this working group will be:
* a formal specification for the protocol * formal specifications of datasets used by the protocol and related extensions to the protocol * an RFC intended to move to a Standard in a timely manner * a specification for extensibility of the protocol in the form of a framework document * additional informational and/or experimental RFCs as necessary to amplify and/or extend ACAP.
Note on goals and milestones: because the work of the ACAP WG is based on the previous work done on IMSP, there is justification for a somewhat more aggressive schedule than is customary.
Goals and Milestones:
Done |
|
Submission of 'ACAP vs. Other Protocols' as Internet Draft |
Done |
|
Second internet-draft of ACAP protocol specification |
Done |
|
Submission of revised proposed WG charter to area directors |
Done |
|
Submission of 'ACAP vs. Other Protocols' Informational Document for discussion |
Done |
|
working group meeting at San Jose IETF |
Done |
|
Working implementations of client and server library |
Done |
|
Additional dataset specifications defined as directed by WG. |
Apr 97 |
|
Final internet-draft of ACAP protocol submitted to IESG for consideration as Proposed Standard |
Apr 97 |
|
Final Internet-Draft of ACAP Protocol. |
May 97 |
|
Address book dataset class submitted to IESG for consideration as a Proposed Standard. |
Aug 97 |
|
Meet at Munich IETF. Discussion to include language-based orderings. |
Sep 97 |
|
Submit remaining dataset class definitions I-D to IESG for consideration as a Proposed Standard. |
Sep 97 |
|
Conclude WG. |
Internet-Drafts:
· ACAP -- Application Configuration Access Protocol
· ACAP TYPE Extension
· ACAP Datatyping and Datatyping Discovery
· Multi-Lingual String Format (MLSF)
· Two Alternative Proposals for Language Taging in ACAP
· Anonymous SASL Mechanism
· ACAP Authorization Identifier Datasets
· ACAP Personal Address book Dataset Class
· ACAP personal options dataset class
No Request For Comments
Minutes of the Access, Searching and Indexing of Directories (ACAP) WG
Chairs: Matt Wall, Chris Newman
Reported by Tim Showalter
Document Editor: Chris Newman, John Myers
Introduction: Matt Wall (chair) says hello. ACAP base document went to RFC (RFC2244), so tonight we're talking about datasets. We need to work on three or four to fufill the base charter and make the protocol useful. We'll be talking about two tonight -- addressbooks and datasets but not mailboxes.
Steve Hole: "Authid?" (Added.)
Mailing list: ietf-acap-request@andrew.cmu.edu. Anonymous IMAP
Archive: imap://cyrus.andrew.cmu.edu/archive.ietf-acap, imap://imap.cyrusoft.com/lists.acap
I. Documents
RFC2244, ACAP base specification
Dataset drafts:
- Addressbooks -- version 02
- Options -- version 02
- Authid -- will be at version 01 (Steve Hole)
- Mediatypes -- version 01
- TYPE extension-- hasn't been touched since April. (crossed off the agenda when Rob Earhart
didn't want to talk about it.)
Also completed was an anonymous SASL extension, which went to RFC 2245.
Web site http://andrew2.andrew.cmu.edu/cyrus/acap/
"Are we doing anything with MLSF?"
Chris: No, Unicode doesn't like it. Unicode did one they like more and their working groups have started on it. I don't expect to move it unless the other solution dies.
Matt: Brainstorming meeting for Mailbox dataset on Tuesday at 5PM since that hasn't been covered in a while.
Where?
Matt: Dunno, will post on message board.
Chris: Meet by the bar @ 5.
Steve Hole: This is to suppliment some of the information that IMAP has -- extra subs information, folder annotation, etc.
Other data types: mediatypes, bookmarks, personalities.
Chris: Latter 2 are out of scope, but we can work on them anyway. (Crossed off agenda.)
Matt: Will have another ACAP meeting like the first one last year in Pittsburgh to work on out-of-scope-for-IETF-discussions type stuff. Snow is less likely. (From the back: El Nino!) Randy Gellens Will be posts on ACAP list in a couple days. Two days in February. Randy notes that there's a (lighted) golf course open until 2 am.
II. ACAP Personal Addressbooks (presented by Chris Newman)
Hard to nail down which set of addressbook information; tried to change things to make it more compatible with vcard.
Major change: phone numbers are stored like addressbook.TelephonePrimary addressbook.TelephoneOrder modifers in phone syntax: 555-1234$work$home$voice$fax
You say we're trying to make it closer to vcard ... how?
Presenter: We could write a spec to say "map this to this", but that's premature since VCard isn't done yet.
Remove all references to VCard since it's not done?
Presenter: No, it's ok.
Remove 6.1 since that's got a mapping.
When will it be done?
Presenter: It's based on MIME calendar stuff so it's hairy, trying to work on it.
That's a normative reference...
Presenter: I could remove all references to VCard. Is that what people want? - Pressure on VCard if you do this, can move forward together.
Presenter: We should move ahead with this since this part probably won't change and since it's much more descriptive.
Add mappings?
Presenter: Not necessary, since everything is 1:1. I don't want to block the spec since that would make it dependant on Vcard - don't wait, we can fix it.
Presenter: So there's only one postal address attribute. Want to make it look like phone numbers in the next spec?
$ could be legal in addresses.
Presenter: This is borrowed from LDAP mapping of VCard stuff.
Pick some character way out in Unicode land (this was taken to be bad.).
Presenter: Document editor takes direction that he needs to figure out a better seperator in addresses (and make the same change on the phone change).
Fixed set in addressbooks and use the same registry for extending these things that Vcard uses.
Presenter: Moving on, added a PGP reference to this. Need to check the version number to keep compatibility with PGP key.
Need to have same attribute qualifications on PGP keys as on phone and addresses. Probably a good idea, but need to generalize everything.
Maybe we should treat ourselves as if we're different people.
Steve: That's what I've done in IMSP as a user.
Hard to keep information correct when you update information.
Chris: Document editor takes direction to add properties to PGP keys.
(from several people:) Need to add to everything.
This is like changing the protocol...
Nothing more complicated than people. This is a special case. For configuration, it's dead simple.
Ever write an .Xdefaults file?
"Personalities" (identities you send mail as) vs. this stuff...
What about X.509 or RSA public keys?
Tied to X.500 directory (where this isn't necessary).
Sad reality probably says yes.
If someone sends me a stable spec of X.509, I'll put it in.
Chris: treatment of X.509 is probably fair, and I'll see what I can do about it.
Complex metadata causes protocol problems. This may come up again. (Mailboxes.)
Mailboxes aren't going to cause this problem.
One email address per entry. Do we want to move to effectively require user to pick email address at send time?
One of the things that makes X.509 tickets special is that those certificates contain those attributes as well; need to duplicate them?
I probably want to add second email address to primary email address.
But there's just a primary #...
Why not have a hierarchy of .../name/{home,work,prison}/...
John dislikes this?
Thinking of my phone # -- have 3 -- (description of truly bizarre phone mess)... need this in addressbooks...
You turn this into a case where the roles are distinct, you can have seperate entries(?), inherit...
Not a hierarchy that inherits, not ...
Presenter: The document editor has enough guidance for the next version of the draft.
Added name prefix and suffix and suggestion to add LanguagePrimary and LanguageOther (as multivalued attributes).
III. Options Dataset, presented by Steve Hole
I submitted what I hope is close to the last draft of the Options Dataset, the general form of options storage in ACAP (for unstructured, general information).
ABNF added for namespace, Chris needs to check it.
"Common" option anmespace left open for shared options. If we're going to have these single options, we're going to need a registry.
Unfortunately, design team suggests that IANA registries have been poor; MIME stuff didn't work until now. Need a recommendation; wanted to hear from Harald.
See the IANA ---- draft from Harald (and XXX)? Has information on how to get IANA to keep a registry of stuff. Has several methods of registration, different gradiations of review, some of ISP, some no review, some lots of review.
Steve asks about this asking about how to hook in; Harald asks for mail about this.
To register intended use.
Documentation issue.
Presenter: Encouraged to hear of good results from new MIME specs and registry, which means we may have better luck.
Also may want common options, so need another layer (common/option becomes standard/option and standard/option/group)
Database will be too big. Relationships need to be well defined.
Steve: Two classes of options, scalar and structured. Spec discusses difference and defines rules for collections of structured options... dataset class. Can have aux information and syntactic content and stuff to make it work. Client applications need to be smart when representing configuration information.
But if items are close but not exactly the same, users will be confused that two close options don't pick up the same value.
Presenter: namespace is set up so that this won't happen.
Presenter: peer review will hopefully solve this problem.
But common app space will be close to vendor space.
Presenter: That's just poor design.
This is like designing MIBs. Trying to match data against the places where data has to be filled in. MIBs have these problems, that's reality, and we're stuck with it. We can try and combat it with peer review. I asked for more examples in Memphis; is the draft to the point where it's worth considering them now?
Presenter: There's a 1p example in this draft.
How about an example as to how to store options?
Presenter: Ok.
IV. AuthID (Steve Hole)
Presenter: I didn't get draft out before deadline since there's a major problem with the model with group authoriziation identifiers. This is an attempt to abstract authorization information from authentication information for the purposes of providing generalized access control inside of services. ACAP, IMAP, others support ACLs based on authentication id; problem with that is users want control over access control mechanisms and #s for authorization identifiers don't make any sense. This provides a way of mapping human-readable names and numbers to ID #'s and have multiple authids bound to single identifiers. Say, both a Krb user and a Unix UID mapping to one user, or perhaps two Krb principals (steve.admin and steve) both grant access to one user.
User ID part is straightforward, but providing grouping mechanism is hard. In original draft, group membership was a multivalued list and that doesn't scale at all. Adding or deleting from a multivalued list means pulling the whole list down, and this is a real problem. Thousands of users in a group is a real problem.
One group at University of Maryland had 40,000 users in group (main student campus).
Have to use subdataset. Namespace problem: groups referencing groups and userids -- both could have the same name. Two schemes presented to design group: 1, entry name uniquifier, leading colon; ":devel" is a group, but "devel" is a user.
Other alternative was to create two subdatasets, one called "members.group" and another called "members.user". 2nd lvl data set has always exactly two entries.
Other alternative was suggested by Rob Earhart -- hierarchy of groups. Declare subgroups underneath and any group containing a subgroup contains all the members inside of it.
Another: reserve name "members", everything else was subgroup. Still a group tree.
/groupid/{groupid_entries}
- ^^ each of which is a dataset with an element named "members" and submembers that are members of the individual groups
Problem: Can't create group named "members."
OK to allow groups to hold groups? What is the current experience of this?
AFS groups have : in them.
Well, not always.
NT5 has a more complex group model than that. But they waved their hands; everything's a GUI, so this stuff is never user-visible. Everyhting is unique since it has a unique ID.
VMS does that too. (Have to guearanteee that users have unique IDs, so you have to look up that, too; name/class combo has to be complete.)
Goal is making up ACLs out of these. Need to know whether something is a user or a group.
(Resolved that what NT5 is a little different than what VMS does.)
Could put a different char in front of users and therefore keep groups and users seperate.
What's the ultimate use? Just in ACAP or elsewhere?
(Questions of resolving permissions...)
Need to make it flexible enough to map everyone else's group models.
I can add owner as an attribute of the group.
Another alternative is to look into the information; if it's group information, it's a group, otherwise it's user information.
V. Mailboxes Data Set
Meeting time as above. Think about it so we can get together and brainstorm tomorrow.
VI. Mediatypes
Idea is to store mediatype to application mapping for inheritance from site defaults. Wanted to pursue this for one of the default datasets since they're "dangerous."
Wanted to describe how "dangerous" a mediatype is (like Word files which can have microsoft files).
(Mention about how text/plain and GIFs can get you fired.)
Looking for "safe" datatypes.
Few people: this isn't useful, warnings aren't useful.
Grab security stuff from MIME documents.
Chair: Out of scope? (Not everyone else thinks so)
Isn't that in the mailcap file? No
[Degenerating]
Chair: Let me give three options and look for consensus.
1. Just give text and ask for warning (site-defined warnings)
2. Try to also flag whether or not it's ok to launch it (rathole?)
3. Punt for experimentation.
Just files off the net?
Chris: Yeah, but this is just the dataset, it's how the client uses it. ... I'm of the opinion *just* warning text could be helpful, and then we could stop there.
No one's gonna read it.
Why not just use this to replace internal current registries?
This probably isn't useful; people just turn it off.
Warning texts aren't ineffective, but how they're used are; people turn them off when they perceive they're not dangerous, then lose. Need to encourage people to use this sensibly.
What I'm hearing is mixed views towards text being not useful, but people do want flags saying warn/don't warn.
Warning text can't hurt.
Have to have something in the window to put with the OK button. [laugh]
Document Ed.: I think I have enough guidance now to update this.
Where are we now?
Complete these five drafts and shut down the working group. If they're not done by the next IETF, we're shutting down anyway. Would like to shut down before next IETF, at worst, will shut down after next IETF. (Acceptable to AD.)
If necessary, we can have working groups to discuss new datasets.
None Received