Capabilities and content-type

[Graham Klyne <GK@xxxxxxxxxxxxxx>]

Larry,

At the WG meeting yesterday, you raised the idea that Content-alternative 
headers should always indicate the content-type of an alternative being 
offered.

I've been thinking about your suggestion, and think that there's something 
here but that you've picked the wrong target.

The place where I think a (type="image/tiff") _should_ always be included 
is in the Media-accept-features field of the (EIFAX) status response.  This 
field is used without being associated with any particular message content, 
and is intended to be a free-standing description of the receiver's 
capabilities.

By comparison, the Content-alternatives header is always used in 
conjunction with some specific content, and declaring a 'type' feature 
value is most important when some _different_ content-type can be offered, 
such as (type="application/pdf") or (type="image/png").  Of course, this 
doesn't mean that the 'type' tag cannot be used redundantly in 
Content-alternatives, but I don't think there's any benefit to mandate such 
use.

I think, then, that the question for this group is:  should EIFAX be 
revised (specifically the content feature schema) to always specify 
(type="image/tiff") as part of the fax capabilities.  This would have the 
advantage of reducing the element of "guesswork" involved when sending a 
message:  (i.e. is the target ifax or non-ifax?).

I think that although this change to EIFAX is retrospective, it could be 
introduced in a way that is quite deployable.    Initially, the 
implementers' guide could recommend inclusion of (type="image/tiff") in 
receiver capability expressions, which is fully compatible with current 
EIFAX.  A future revision of the fax feature schema could include this in 
all profiles, with the proviso that a fax capability expression not 
including a 'type' can be assumed to include (type="image/tiff").  This is 
no less well determined than the current situation, and over time may help 
us to migrate to a specification that fully supports integrated multimedia 
messaging  (e.g. integrated IFAX/IVM terminals could be better supported).

#g


------------
Graham Klyne
(GK@xxxxxxx)