Piggybacked, adjunct services

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, [email protected] 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:[email protected]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850