Minutes, Content Negotiation BOF, 12-9-97.
Notes taken by Andy Mutz and edited by
Ted Hardie.  Any errors are the responsibility
of Ted Hardie <hardie@nic.nasa.gov>.

Larry Masinter chair
mailing list:  conneg@imc.org
web page:  http://www.img.org/conneg

Introduction - Larry Masinter 

Content negotiation discussions have been under discussion for at
least 2 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 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 UofTennessee 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?  Ans: 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
vs.  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 whethers 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
agreeed to publish his proposed Charter in the week following the IETF
meetings.