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