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.