2.1.3 Content Negotiation (conneg)

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

Chair(s):

E. Hardie <hardie@nasa.gov>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.no>

Applications Area Advisor:

Harald Alvestrand <Harald.Alvestrand@maxware.no>

Editor(s):

A. Mutz <mutz@hplabs.hp.com>
G. Klyne <gk@acm.org>

Mailing Lists:

General Discussion:ietf-medfree@imc.org
To Subscribe: ietf-medfree-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-medfree/

Description of Working Group:

A number of Internet application protocols need to indicate recipient capabilities, characteristics, and preferences when the resources they handle can vary in form. This working group will finalize registration procedures for distinguishing attributes which cause the media delivered to vary in form. The registration of these "media features" will provide a supplement to the MIME registration of media types and enable the development of a cross-protocol vocabulary for exchanging information on recipient capabilities, characteristics, and preferences. Since these distinguishing attributes commonly occur in related sets, this working group will also describe at least one method for referring to composite media feature sets. Experimental methods for using these features and feature sets within specific protocol contexts may be developed within this group or within the groups standardizing the relevant protocols.

The working group is aware of applications which desire to negotiate what content is delivered as well as the form in which it is delivered. As much as possible, the group will endeavor to create a framework for exchange sturdy enough to handle the later addition of this type of negotiation. It will not, however, address this need directly nor will it limit its design choices based on the possible later addition of this negotiation.

Goals and Milestones:

Feb 98

  

Submission of registration procedure draft as BCP

Feb 98

  

First draft of Requirements and frameworks document.

Feb 98

  

Submission of feature scenarios draft as Informational RFC

Mar 98

  

Revised draft of Requirements and frameworks document.

Mar 98

  

First draft of composite feature set draft.

May 98

  

Requirements and frameworks document to Information RFC

May 98

  

Revised feature set draft

Jul 98

  

Feature set draft to Informational RFC

Aug 98

  

Working Group Closes

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the Content Negotiation (conneg) Working Group

Chair: Ted Hardie
Reported by: April Marine

Agenda for meeting consisted of discussing the pending drafts, then editing the milestones (plus any other biz). The pending drafts are:

Feature Registration Draft draft-ietf-conneg-feature-reg-00.txt
Media Features Draft draft-ietf-conneg-media-features-00.txt
MDN Features Draft draft-ietf-fax-mdn-features-00.txt
Requirements Draft draft-ietf-conneg-requirements-00.txt
Algebra Draft draft-ietf-conneg-feature-algebra-00.txt

1. Feature Registration Draft discussion, led by Andy Mutz.

Andy summarized the points in his draft. The draft deals with the points of who should register content feature tags, what should be registered, and why. Also, the procedures for registration. There are many situations where one would like to have a common set of features to negotiate over, so sharing a set of tags would be beneficial, even across protocols. This draft deals with registration of tags, not exchanging them or negotiating them.

Andy discussed the feature tag syntax, and the point was made that the less syntax used the better, as the method would then be more applicable across protocols (requiring less escaping of reserved characters).

The point was made that the security considerations section of the registration form is not optional. A question arose that there may be problems trying to describe security problems at the registration level, since there was no way of knowing how a protocol would handle the information. The response was an example of type of security consideration that might apply at this level. If, for example, you wanted to register something like "display=braille", it would be clear that you are potentially sharing info for a preference for a braille terminal, which may raise a privacy concern or issue. Therefore, it is useful for the purpose of a registration that you express that type of concern in the security considerations section, even if you don't know how a protocol might use the feature.

The point was made that while the IANA registers things, it does not necessarily catch conflicts. So, if someone registers "paper type" and then someone else wants "paper size" with same features, how can we make sure both are not registered? The suggestion was that we could send proposed features to a mailing list; i.e., that people would be encouraged to send proposals there, but not required to do so.

Finally, the point was made by the chair that it is necessary to bring this draft in line with the recent IANA Considerations document, which provides guidelines on working with the IANA. For example, things can be vetted via an RFC or via review by a designated expert, but not really via a mailing list. The group was encouraged to read that paper and that discussion was taken to the list.

2. Media Features Draft discussion was led by Larry Masinter.

This draft deals with media features for display, print, or fax. It started with the question of how a browser might tell a server what display size was optimal, but also discussed more generally what a recipient might want to tell a server about itself.

There were only two pending issues identified re this draft. The second open issue was non-contentious. It dealt with the question of why one should have pixel size and resolution and paper size all as features because can't one derive, say, paper size if one knows the other two? The response was, possibly, but it is not necessary true, that one always knows the "other" two, so all are needed.

The greatest part of the discussion on this draft dealt with the question of the unit of measurement for resolution. Should it be in pixels per inch (as the draft currently says) or pixels in a metric measurement. That is, should the "English" (inches) unit be used or should pixels be expressed in a per millimeter value? Long discussion of the pluses and minuses of each and several ways the options could be expressed (e.g., with a separate value for unit). Discussion of how it is done in VCARD and how it is done in the FAX community, etc. Different communities have different conventions. Impossible to come to resolution during meeting and time was passing; taken to list.

3. The next topic was the inclusion of media features in email directories.

Currently the email address information is part of the person schema and cannot itself accept additional attributes. However, it would be useful to know if someone's email address could accept particular media features, such as, can a particular email address accept a high-resolution color tiff value?

The point was made that this work sounds like an application of the registration values the group is creating, i.e., another context that can handle a media feature list. So, the request was made for help in developing a way to describe features of email addresses. Larry rounded up a volunteer to help.

4. Next draft discussed was MDN features, led by Dan Wing.

This is a draft from the FAX group, which is a discussion of how one might pass features using MDN. It was discussed in this group because it might have uses beyond the fax community regarding how to get features flowing between interested participants. Use of this method would eliminate the need to have something like a "user can receive HTML" or "text enriched" check box because the MDN would contain all the features a recipient has. Once that information is passed, it would eliminate the need to send the recipient anything it can't accept or ask further what the recipient can handle. The group was encouraged to read the draft.

5. Graham Klyne was next up to talk about two drafts he has written.

First he discussed the Requirements Draft. Graham summarized the points made in the document; there were few comments. The basic approach was to include every related requirement that could be found and make them available for discussion and winnowing. The desire was to have a common vocabulary for features and feature sets, and to have an extensible framework that could adopt new features easily. A requirement was that one must be able to describe features both individually and in sets. The doc has a framework proposal for how content negotiated elements can be developed across protocols and applied to different protocols appropriately.

6. Graham continued with his Feature Algebra document.

This draft came about from a study of HTTP transport content negotiation because that mechanism seemed very ad hoc, with no underlying framework.

The structure suggested in this document allows for feature comparisons and the use of logical operators. It is proposing a syntax based on the LDAP filter string model in RFC 2254, with a few shortcut conveniences in notation.

A key to the work is the knowledge that real negotiation will take place on collections of features, so there is a need to bundle features into collections that can be compared.

Work remaining includes a need for a description of preferences and a syntax for text representation. Also the comment was made that this approach is different from that taken in the IPP group and a possible future topic would be to work to more closely align the two approaches.

7. The final topic was a re-evaluation of the milestones as noted in the charter.

February 1998

Submission of registration procedure draft as BCP
Moved to June 1.
Pending: resolve ASN.1 questions; revise to meet IANA Considerations requirements

First draft of Requirements and frameworks document.
Done.

Submission of feature scenarios draft as Informational RFC
Deleted. Falls under charter of FAX WG, so it will be reviewed when it comes out of that group.

March 1998

Revised draft of Requirements and frameworks document.
Moved to May 1.
Pending: Graham is waiting for feedback.

First draft of composite feature set draft.
Done.

May 1998

Requirements and frameworks document to Information RFC
Moved to August.

Revised feature set draft
Stays at May.

July 1998

Feature set draft to Informational RFC
Stays at July.

August 1998

Working Group Closes
Add: Media Features Registration Doc; June 1 (depends on registration procedure doc).

Group is still looking to close after Chicago.

Slides

None Received

Attendees List

go to list