Re: Keywords for "SMTP Service Extension for Content Negotiation"

> > The case I was thinking of was the one where caching of conneg information by
> > intermediaries eventually brings the information back to the server adjacent to
> > the originating client. So the transformation is still done on the originating
> > client or on a server very close to it.

> I think it's a stretch to believe that caches are going to solve this problem.
> It's true that if A keeps sending messages to B then eventually A's MTA will
> be able to cache B's recipient information.   But this assumes that the
> intervening MTAs support CONNEG (and cache CONNEG information) - which itself
> seems like a stretch because, as you say, there's no business case for them
> doing conversion.

What's a stretch is your assumption that caching implies conversion
capabilities. They are completely different activities. Conversion by an
intermediary is a nasty mess, whereas caching conneg information is trivial.

> It's also a stretch to believe that this is going to work well
> for arbitrary pairs of senders and recipients - it might work for those pairs who
> exchange lots of messages, not so well for those pairs that occasionally exchange
> messages.

That's certainly a possible outcome. But you can game this in all sorts of ways
and reach various different conclusions.

> And of course there's the problem that CONNEG information can be
> expected to change over time, but there's no mechanism in the current proposal
> to timeout caches.

I've already indicated that I believe conneg information caches are something
that needs to be discussed.

> Frankly the method of returning capabilities in a bounce
> message seems more effective and more reliable because it doesn't rely on
> intermedaries.

The problem I see with depending on notifications is another one of those
"looks good on paper" things: For whatever reason, support for sophisticated
handling of notifications has been slow to materialize in user agents.

> The only way I see to make the CONNEG SMTP proposal work end-to-end is for
> all of the intermediate MTAs (those that don't have direct knowledge of the
> recipient capabilities) to open up SMTP connections to the next hop *in real time* -
> so when the sender asserts CONNEG in a RCPT command then the MTA has to stop
> acting like a relayer and start acting like a proxy - finding a MTA for the
> next hop, opening up a connection, sending EHLO and seeing if it supports
> CONNEG, sending MAIL and all previous RCPTs, and finally sending the RCPT
> that has the CONNEG option, just so that it can propagate the CONNEG response
> back to the sender's UA.  Even then it will be very slow, it introduces
> race conditions due to timeouts, and it still requires all of the intermediate
> MTAs to support CONNEG in proxy mode.

This scheme was actually discussed and I believe rejected in the FAX WG
some time ago. Regardless, I disagree with your assessment that this is
a requirement for the present proposal to be effective.

> I haven't followed the fax discussions, but weren't the fax people looking for
> a mechanism that would work predictably and reliably - e.g. if sender and
> recipient both have (say) high-res capability then the document is always
> transferred in high-res - and a mechanism that would give the sender the option
> of requiring that the recipient have certain minimum capabilities before sending
> the message?  (e.g. don't bother sending if recipient doesn't have color?)
> I just don't see a way to make that work through the existing SMTP infrastructure.

I'm sure there are plenty of places in the present infrastructure where this
scheme won't work well. I'm also sure there are plenty of places where it will.
My assessment of the notification scheme is roughly the same. And experience
should inform us that our ability to predict what portions of the
infrastructure will be upgraded is pretty limited.

The bottom line is that we're dealing with partial solutions in every case
here. This makes it easy to criticize any given scheme. IMO this also makes it
very much the WG's call as to how to proceed.

				Ned