Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard

> > (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