(4) A general concern about the many possible
uses for this mechanism that has all of us engaging in futile
speculation and which cannot possibly be dealt sensibly with
in a specification without actual implementation and use
experience.
That is a reasonable position. But I suggest that it implies
either that this material should go to Experimental, rather than
Proposed, or that the mechanism should be defined as applicable
to the cases that are understood and expanded only when the
implications of that expansion are better understood. Or...
Experimental status also occurred to me as a possible approach.
The only clearly valid argument I've seen so far for removing
REQUIRED is that it may not really be needed and things that
aren't needed should not be there. But whether or not it is
needed is really a question for the WG. Perhaps those who
actually plan to implement CONNEG clients could comment on
whether or not they view REQUIRED as something they need.
I, at least, would find such comments helpful. But I'd also
like to hear comments from at least one person responsible for a
general-purpose MTA (as distinct from a fax-over-email engine)
who expects to implement this feature and how they propose to do
so and how this feature fits in.
There are two cases here: Client and server implementations.
I definitely plan to implement the server side of this proposal. From that
perspective all of the proposed variants are easy to implement as long as you
have a source of conneg information to tap. I plan to use an LDAP attribute for
this purpose.
The client side for a general-purpose MTA is much harder, but not because of
any aspect of the protocol. The issue I have there is how to match up an
arbitrary set of site-provided conversion operations with the current group of
recipient feature sets. I don't see a good solution to this other than making
the whole thing something the site specifies, and if I do that I see little
chance of the capability actually being used by enough sites to justify the
cost of implementation.
One final comment. A general-purpose MTA using arbitrary site-provided
conversion routines doesn't have the luxury of being able to bound the
performance or other characteristics of those conversion routines. This makes
the entire convert-on-the-fly scenario problematic in ways that don't arise for
a device built around a specific, limited and well understood set of on-the-fly
converters, regardless of whether that device is a fax machine or something
else entirely. Indeed, if I were to implement based on past bad experiences
with various general-purpose conversion routines I'd be likely to break the
problem down into three steps: (1) Collection of conneg information online, (2)
Message splitting and conversion offline, (3) Sending the resulting emssages to
their destination. I doubt I'd support using REQUIRED in (1).
Ned