2.1.1 Application Configuration Access Protocol (acap)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98


Chris Newman <chris.newman@innosoft.com>
Matt Wall <wall@cyrusoft.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.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 addressbooks.

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 addressbooks, 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:



Submission of 'ACAP vs. Other Protocols' as Internet Draft



Second internet-draft of ACAP protocol specification



Submission of revised proposed WG charter to area directors



Submission of 'ACAP vs. Other Protocols' Informational Document for discussion



working group meeting at San Jose IETF



Working implementations of client and server library



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.


Request For Comments:







ACAP -- Application Configuration Access Protocol



Anonymous SASL Mechanism

Current Meeting Report

Minutes of the Application Configuration Access Protocol (acap) Working Group

Reported by Walter Wong <wcw@andrew.cmu.edu>

The chair believes that we have completed most items of the charter and can retire the working group meetings and will gage consensus at the end of the meeting.

There were no objections to the addressbooks or options dataset going to last call.

Steve Hole started by talking about the registration process for "standard" items in the options dataset. In the most common case, vendors will create their own space in the options dataset; however, there will be the case where there are options that should be shared between multiple vendors. However, this information may not warrant defining a new dataset. So the plan is to do a registration scheme where recommendations for standard options is to post to the mailing list for peer review. Once it passes peer review, it can get registered with IANA to finalize the procedure. While the process may be a lot of work, the frequency of needing to go through it is thought to be small enough so that it isn't that bad. Details are in section 5.2 and 6 of draft-ietf-acap-options-02.

Chris Newman then talked about the draft to incorporate TLS with IMAP/ACAP/POP. He mentioned that there was also the plain SASL mechanism which is described in the draft that can only be used if TLS is involved. Chris plans to ask for a 4-week last call on the draft (draft-newman-tls-imappop-03). The important point to note is that this method doesn't require a different port to enable TLS. The draft is similar to the SMTP-TLS draft.

This led to a discussion on what to do if TLS were not available and one had to fall back to SSL. The problem exists in that there is no SSL draft to reference so how does one properly word this. It was decided to let it go to last call and if anyone could come up with better wording, it would be addressed then.

There was also a question about what the proper behavior when starting TLS fails and there is no fallback. The claim is that the TCP connection should remain in the same state. The question then arose where was this referenced. The final decision was to take this discussion off-line to the apps-tls mailing list.

Chris Newman presented the mediatypes dataset (draft-ietf-acap-mediatype). This dataset provides a distributed, interoperable "mailcap." The document should be basically complete with the exception that there are some issues to be dealt with regarding Microsoft operating systems and some path issues. It is believed that only one more revision should be necessary. People with experience dealing with mapping MIME types to the appropriate viewer on Microsoft operating systems are highly encouraged to review the upcoming draft of the document.

Steve Hole presented the Authorization Identifier dataset (draft-ietf-acap-authid-01). The idea is to provide not only "user friendly" mappings to the underlying authentication layer but also provide a mechanism to bind identities to group lists which can then be used in ACLs to evaluate authorization properties.

There did not appear to be any namespace issues but there was a question with inheritance and whether or not users should be able to create their own groups or does the site admin have to do all the group creation.

The consensus reached was that inheritance would not occur and there would NOT be user creatable groups. There were no arguments about inheritance but there were concerns about the group issue. Specifically, you really didn't want an administrator involved in every group creation.

The document editor believes that there should not be any inheritance as it gets ugly and there shouldn't be user defined groups. There was a concern about enterprise scalability. The problem is that there may not be a really good group model so the plan is to try to keep it simple (i.e., leave it out) and get some operational experience.

There is one revision that userids need to be moved forward. Matt wants a note that elaborates more on the issue of groups/inheritance. There was a comment that AuthID was confusion so the full name is being used in the draft. One minor revision is needed for the document.

Mailboxes dataset. Issue is to store IMAP mailbox information. There was a list of things that needed to be in the dataset that needs to be written up in a dataset. There will be a posting to both imap and acap list to gather requirements by posting a preliminary draft to the list.

Content-type extension - values in acap don't have any type information. It may be useful to associate a MIME content-type with acap data. There is a problem with inheritance so that when you set a content-type you must set a value. The general concept seems ok with an exception of a some nits. Should be one more minor revision.

Bookmarks dataset - allow browser "bookmark" information to be stored in ACAP. The 'type' field provides some information as to the entry (e.g., separator, link, folder, alias). We are interested in someone who has implemented a browser to comment on this.

Question: what about multiple URLs in a single entry?

There was a question about relevant experience and there was some suggestion that we go with experimental status for RFC. Many of the drafts haven't had a lot of review -- is there appropriate peer review for the datasets? Two in particular are AuthID and bookmarks. AD says could last call and see if people notice. Other option is to publish as experimental. Chair will open up a thread to the list. If experimental make sure the mailing list is in the document.

Accounts/personalities - email related attributes that are necessary for an email client (receive); personalities is for sending mail. Personalities can also be used to process the incoming mail. Sieve filter would live in the accounts.

Dictionary - way for you to store your personal dictionary information (words that you add to your dictionary) for your spellchecker. Main issue is with internationalization aspects: how to deal with different languages, dialects, etc. There was a point that this would be good for more than 'personal' dictionaries but rather should be shared among groups. The idea is that you could have a comment field for the dictionary so that you can find the dictionary that you want to use (e.g., if there is a technical dictionary that you want to share across the net).

There may be cases when you want to remove words from the dictionary. Chair asked people who work with spellcheckers to take a look at the draft.

There was a question about using this as a translation device.

There was a question on whether your complete dictionary should be on ACAP. Further discussion goes to the list.

The chair reviewed the requirements to finish up the WG:

· authid revision
· authid group last call

· option group last call

A hum agreed that we were on track to get all these goals accomplished by June.


None Received

Attendees List

go to list