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

Ned, Keith, and others,

I'm going to try to respond to several messages in one, please
bear with me.  Also, please note that I've had more than my share
of terrible ideas and it is quite possible that the notion of a
MUA getting information out of a directory about recipient
capabilities is another one.


--On Saturday, 13 July, 2002 08:55 -0700
[email protected] wrote:

>> A footnote on the "find out from a database" issue.  The more I
>> think about it, the more I conclude that the database lookup
>> (LDAP or otherwise) is the only rational way of implementing
>> the desired functionality here in a case that might involve
>> relaying. To the extent that speedy and confirmed delivery are
>>...
>> But, if database lookup is the only plausible implementation
>> that is consistent with the underlying design requirements,
>> then we should not be looking at capabilities negotiation in
>> the SMTP stream.  Instead, we should be looking at a piece of
>> protocol by which the sending system (probably the MUA, rather
>>...
> I think this is a fine piece of theoretical analysis which
> unfortunately has no applicability to the real world. In the
> real world directory/database systems that let sites provide
> Internet-wide access to information about their users do not
> deploy.

Well, it depends on how important they are.  And, while it may be
tautological, the observation that these things have not deployed
is an indication that they haven't been important enough, given
deployment and maintenance costs and security risks.  Of course,
we do have one wildly-successful counterexample and, while I hate
to even mention it as a possibility, if this capability is
important enough, and it were the right answer (I have serious
doubts about both), nothing prevents us from thinking about a
mail-capabilities RR.  It would be a bad idea if only because the
capabilities are really an MUA issue and the DNS identifies MTAs
(today), but...

>...

> The IETF has tried to tackle this problem several times, and
> indeed continues to do so now in the RESCAP WG. But I don't
> think anyone seriously believes that even if RESCAP produces
> some specifications it is going to succeed at its intended
> scale. Frankly, the silence is pretty deafening over there.

I certainly agree.

> Lacking direct capabilities to find capabilties information
> necessarily leads to various piggybacking options, that is,
> deploy this facility on top of or inside other protocols. This
> has some of the same characteristics as the
> everything-over-HTTP approach, but with several important
> differences: There is a close relationship between the
> piggybacked data and the intended purpose of the underlying
> protocols (a relationship that is often lacking with stuff
> travelling over HTTP) and the operational case for doing this
> is far more compelling (getting the OK to drill a hole in a
> firewall for a new protocol is triviality itself compared to
> the difficulty in setting up even restricted access to
> directory information).

Yes, but as Keith points out (more politely), using the general
organizational directory for this purpose would be madness.  I
hope you didn't assume I was proposing it.   But the "piggyback
everything, rather than think about new protocols" approach
(which I don't think you believe in either, at least in the
limiting case) leads to a different sort of madness, one which
often manifests itself as "give up on all other application
protocols and just use HTTP" (or, more recently, SIP).

> I think the availabilty of capabilities information has the
> potential to be as important a step as MIME was. As such, I
> don't begrudge healthy debate about how and where it is done.
> But let's not forget that the development of MIME was informed
> by the catastrophic failure of various other schemes for doing
> multimedia messaging -- some of them more elegant than MIME --
> leading to compromises in the design intended to insure
> deployability. I think the discussion of where and how to do
> content negotiation needs to be similarly informed by the
> catastrophic failure of Internet-wide directory services to
> deploy.

That should clearly inform many of the things that we do, but we
should learn the right lessons.   Just as "firewalls get in the
way of anything new, therefore we should run all new protocols
and services over HTTP" is typically a wrong answer, developing a
paranoid fear of directory-like services. Prior attempts have
been over-ambitious for what they promised to deliver relative to
what people needed.  Or they have failed for other reasons.   But
it may be that the lesson is "more focused and less ambitious and
general purpose approaches", rather than discarding the
bathwater, the baby, and anything that vaguely resembles either
because, e.g., it is wet.

So, given that I'm already generating plausibly-bad ideas, think
about a strawman.  Suppose we said "if you want to use email
capabilities, you need to be able to establish a connection to
the final recipient" (whatever that means).  This is, of course,
a variation on the "no relay" scheme.   But then suppose that,
instead of piggybacking on top of SMTP, we required that the
destination host have an A RR, or a very specific and slightly
peculiar SRV RR, or something similar, such that the client MUA
could open a connection to it, ask "what sort of fax capabilities
are you willing to provide to a message coming from foo.bar.baz
to [email protected]", and get back a quick answer.  At the
price of a new RR type, it could even be done over UDP, on a "get
an answer or give it up and send the minimum" basis.  Or, at the
price of committing an obscenity, it could be done pretty easily
over HTTP or SIP.  The UDP approach, and probably the other two,
would almost certainly be faster than getting anywhere near an
LDAP server.   Those approaches are consistent with what I
intended to imply by "...LDAP (or something else)".  

It would require some configuration, but so does piggypbacking on
SMTP.  Is it important enough to deploy?  I don't know.  But, if
it isn't, is this capability really worth cluttering up SMTP?
Remember that quote from RFC 1425 and its successors... your name
is on that document too.

You also wrote:

> Second, I believe the notion of using a directory for this sort
> of thing has been discussed in the FAX WG on several occasions.
> And while it is axiomatic that nothing precludes the WG's
> having chosen to use a directory, nothing requires that a WG
> pursue it either. I take the rather stunning lack of interest
> in this overall approach as yet another sign that it is seen as
> nonviable.

Since I have been paying only intermittent attention to the Fax
WG, I missed those discussions.  But most of the discussions
(about other topics) I remember from that WG were focused,
appropriately, on fax.   One of the reasons we do IETF last
calls, IMO, is to be sure that applicable considerations outside
the scope of the WG are exposed and aired.  So, unless you are
convinced that the WG carefully and accurately balanced the
general (1425/1869, etc) argument against SMTP extensions on
behalf of the overall community, I'd be interested in their
reasons for rejecting alternate approaches but might not find
them compelling.
 
To conclude, Keith wrote:

> The two approaches are not mutually exclusive, but if we wanted
> to support both query methods then it would be good idea to 
> understand how they interact sooner rather than later.

And it is a good idea to weigh the strengths and weakness of
each, in an overall Internet and email context, not just a fax
one (unless this capability is to be narrowed to fax
applications).  That is why, regardless of the outcome of this
discussion, I think it is a good use of time and appreciate your
willingness to engage in it without dismissing the issues as
spurious.

     john