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.
