ietf-smtp
[Top] [All Lists]

Piggybacked, adjunct services

2002-07-13 18:05:50

Folks,

Ned's note explains some operational realities and some architectural implications. His note is the clearest, the most pragmatic, and the most compelling statement on this issue that I have seen.

It is easy to miss just how important his explanation is. So I am taking the slightly theatrical step of re-posting it, in order to stress the importance of its insight:


At 08:55 AM 7/13/2002 -0700, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:

In the real world directory/database systems
that let sites provide Internet-wide access to information about their users do
not deploy.

I'm not sure why this is the case, and indeed I'm fairly sure that there is no
good reason for it, but a vast tract of experience tells me it for-sure is the
case. (Now is not the time to get into whys in more detail.)

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.

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).

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.

                                Ned

----------
Dave Crocker  <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850


<Prev in Thread] Current Thread [Next in Thread>