NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
E. Hardie <hardie@nasa.gov>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Editor(s):
A. Mutz <andy_mutz@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:
· Media Feature Tag Registration Procedure
· Media Features for Display, Print, and Fax
No Request For Comments
Conneg Working Group Minutes, 42nd IETF
Thursday, August 27th 3:30 pm
Chair: Ted Hardie
Reported by: April Marine
The Chair reviewed the purpose of the group, noting that it is chartered to establish a
registry for media feature tags and a method for protocols who wish to use these tags
to do so interoperably. The group is focusing efforts on trying to create a framework
for the exchange of media and presentation-related features, though it is hoped that
the framework will be generally useful for feature exchange.
First, Larry Masinter discussed draft-ietf-conneg-media-features-01.txt; he will be
removing the TIFF profile tags from the draft, as they will be handled in documents
generated by the FAX group. He will also be changing data types from integer to
rational for the included features tags which are not in SI units, in order to meet the
conversion requirements of draft-ietf-conneg-feature-reg-03.txt.
Dan Wing reviewed conneg-related work in the FAX working group. He will be
mapping fax-related features to the conneg registry and algebra, starting with the
t30 capabilities related to media.draft-ietf-fax-130-capabilities-00.txt is a first cut at
this task. Dan also discussed draft-ietf-fax-reporting-extensions-01.txt, which
describes the use of DSN extensions to allow an MTA to indicate the feature
capabilities of the receiving device. For example, a printer could explain the formats
it understands via a mail agent. This work is in the FAX WG, which is trying to
unify FAX and email. It may also be applicable to other efforts to unify email and
voicemail, so in the future you could receive FAXmail, email, and voicemail all on
one device.
There were comments that the second draft looks like a reinvention of SLP and
possibly LDAP. Dan disagrees, but is looking at allowing printer capabilities to be
expressed in LDAP.
The Chair pointed out this work is important for conneg to consider now because it
provides a possible method for the actual exchange of conneg features; the working
group must consider how its common vocabulary will be exchanged to understand
how to optimize the expression of that vocabulary.
Concern was expressed by Lloyd McIntyre that normalizing some features will
mean losing information that is relevant to a particular device, such as the
particulars of how faxes handle colors. Appropriate registration can ameliorate the
problem, and situations in which a device might want to derive or infer a feature
must be very carefully examined.
The Chair reviewed draft-newman-mime-cdisp-metadata-01.txt, which proposes a
new MIME content disposition value, metadata, to be used with MIME multipart
messages. The use of this header would allow the development of a fully featured
MIME multipart/alternative, indicating which features are used by which parts.
This use, like the use of conneg features in Dan Wing's work, may help us better
delineate the problem space for the set theory work.
The group then briefly discussed the MAILCAP BOF held earlier in the week, which
will attempt to introduce a lightweight mechanism to distribute attributes associated
with an email address. The main candidates for inclusion in such data are public key
certs and capabilities information, which means that it may also want or need to use
conneg feature tags.
Graham Klyne then reviewed draft-ietf-conneg-feature-algebra-03.txt Some key
concepts from the doc are the terminology of feature collection, feature set, and
feature predicate. A feature collection can describe a specific document, for
example. A feature set describes the capabilities of a recipient, such as a printer.
A feature set describes all the possible feature collections that can be expressed. A
collection is often derived from a possible rendering. But a feature set implies one
can render something anumber of different ways. One may use a set of collections
to represent a resource or the capabilities of a recipient.
A feature predicate is a boolean function that takes a feature collection and returns
a true or false value. The presence of a true value for at least one feature collection
shared by the set describing the resource and the set describing the recipient
capabilities indicates that the resources is renderable by the recipient.
The current syntax for feature matching is based on an LDAP search filter, but it is
not a search.
Graham also discussed some issues he feels are outstanding. No easy way to say
"these features and no others" with the current system. The example given related
to font selection for a document that uses 3fonts. Currently would have to introduce
a separate value tag (true/false) for each feature needed to say "all these fonts are
needed" rather than "this font or that font" or "this one font, not others." The last
two situations can currently be expressed.
This point hasn't been discussed on the list yet; not sure whether it is important.
Introduce set value features, which adds some complexity but allows you to express
a closed set of features. Or need to introduce a way of expressing a combination
of features as a single feature value, plus the operations needed to compare these
values.
Another issue raised was that there is currently no way to combine MIME types
with other features, which is important for situations where the MIME type
influences other features (imagine a display in which application/postscript may be
rendered in color but application/pdf may not, for example). The document may
need to introduce a special feature tag that is a reference to the MIME type.
The last topic raised was how to register profiles, so as to allow for quick references
to standard feature collections.
The three isues of feature profiles, MIME type features, and multiple-value
mandatory features will be raised on the list.
In reviewing the Working Group milestones, the Chair noted that the working
group is behind and should be closing now. Discussing ways to move forward,
the room agreed that it was a good idea to subsume the profile registration doc
within the algebra doc, as it would allow registration to use the algebra syntax to
the profiles being registered. The room also suggested drastically reducing the
algebra draft to focus on the syntax and examples, and Graham asked the group
for assistance with the examples.
Given the highly-compressed time schedules of some of the working groups
depending on our work, the room agreed to aim for a working group last call on
the algebra draft by October of 1998.
None received.