Minutes of the Content Negotiation BOF
Chair: Larry Masinter
Reported by Andy Mutz and edited by Ted Hardie
Mailing list: email@example.com
Web page: http://www.img.org/conneg
I. Introduction - Larry Masinter
Content negotiation discussions have been under discussion for at least two years. Note content negotiation is NOT negotiation over content but over FORM of content. (It is likely the group will be renamed.) Content work grew out of the realization that current form in HTTP based on Content-Type was insufficient; negotiation on features was desired. Lots of applications outside of HTTP shared this requirement for features.
A proposal for certain features (paper size, etc.) was made, and then re-submitted as draft-masinter-media-features-01.txt. In addition Dan Wing, Joffe, and Masinter worked on applying this to Fax over SMTP.
HTTP requirements include: accept, accept-charset, user-agent support for handhelds, screen size. Fax requirements: Compression methods and TIFF profiles. There was a report on LDAP requirements, too. The question of scope was raised; in particular, are IPP's requirements in scope? Generally agreed that they were in scope.
Al Gilman spoke about the Accessibility Web initiative. For example, a blind person would like appropriate content. The ability to convey information to server regarding functional capability of user interface was desired. For example - no display, no mouse, sound primary, or no sound, text only. so the server can send appropriate information.
Keith Moore spoke on requirements for URI Resolution, arguing for doing negotiation outside a particular protocol. Think of it as a URI resolution set. Metadata exists somewhere in the world about the data, and the resolution step is used to do media selection. This can be done outside of HTTP, and reduces needs for redirects. It is useful for protocol selection as well as media selection. For example, one could pick audio over real-audio or text over http. Experiments at University of Tennessee doing this are ongoing. Media selection over HTTP is slow/expensive. SMTP is store-and-forward; it is inappropriate for negotiation in the general case. Protocol and media negotiation allows smooth transition betweeen fax-over smtp and fax-over-http and fax-over-pstn for example. Protocol for doing this can be simple, and the hard work is selecting robust schema.
Graham Klyne presented the Framework and Requirements Draft (draft-klyne-conneg-requirements-00.txt) He started from the FAX field and examined work in HTTP. This draft has been mailed today and will be submitted as ID in a couple of weeks. It's preliminary, and covers a little more than requirments. Some terminology is defined, including capability, choice message, connected mode, content negotiation, data resource, feature, list message, message, negotiatioed content. Ted Hardie's draft explains "why negotiate?" This draft discussed "how might it be done?" Sender-initiated as well as recipient-initiated negotiation discussed. Question: is quality of service treated? Answer: not considered specifically. Proposed Framework presented: Abstract negotiation process --> protocol binding --> negotiation spec for particular protocol. <--concrete representation of metadata <-- abstract representation of metadata. Issues include name space and notation. (text, ASN1 + encoding) Technical issues: Non-message resource transfers, End-to-end versus hop-hop negotiations, Billing issues, Use of directory services, Performance considerations ....
The group discussed security considerations for some forms of negotiation: privacy, denial of service attacks, mailing list interactions (revealing capabilities via disposition notification).
The group discussed the 'alternates' draft: it does not require feature tags since it can be used to specify media. Multipart-alternative with content by reference vs. http headers (or both): is the syntax in alternates reasonable for the SMTP-fax draft? Ted Hardie noted that while features useful, he has concerns (regarding gateways) of losing capabilities if method is not cross-protocol compatible.
Dave Crocker suggested changing the term negotiation to 'feature profile'.
Larry Masinter asserted that resource providers want to know recipient capabilities, preferences, characteristics. These need to be combined into a single name space. Note that many characteristics/ capabilities are very 'fuzzy'. Carl-Uno Manros noted that IPP assigns a 'default' for capabilities.
Protocol lifetime: This would be included in a specific application but outside the scope of the generic feature registration/negotiation work.
Al Gilman asked the group to consider whether a global registry is needed and noted 3rd party can be used. Designated feature spaces can be used for this. Consensus seemed to be that it might not be required but it's useful because global registries are very efficient.
The base problem can be stated as: a community of users can't view common content. This group wants to commonly register features. This is not enough, but it is a useful first step; the application of this to HTTP, FAX, and Internet Printing has to happen as well for this to be useful.
Larry Masinter suggested that one method of moving forward quickly would be to take the current registration draft forward to last-call.
Dave Crocker suggested a cover task of describing features and characteristics first. When the list exists, now the issue of getting the feature list exists. Transport of this list (or association) must happen. These can be treated separately.
Keith Moore spoke in favor of a feature registry, but expressed concern that the schema may be inadequate; trees keep getting reorganized as interdepencies are recognized. This registry may have limited utility in long-term due to this interdepence.
Larry Masinter agreed that the registration draft for attributes of recipients should be noted as being limited.
Keith Moore noted that describing capabilities of user is easy but describing features of content is hard.
Open-ended set of objects is described, but a registry is a useful step.
Carl-Uno Manros suggested work in IPP is applicable to this work. IPP registry for paper-sizes etc. should be same in this registry. General agreement that this registry should adopt by reference pre-existing registries where those registries are already in use.
Consensus was expressed that we should move forward on a registry and on some experimental drafts. Agreement was reached that a working group should be created. Ted Hardie volunteered to be Chair and agreed to publish his proposed Charter in the week following the IETF meetings.
go to list