> > 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.
> Widespread deployment of LDAP as a public directory service was hampered
> by several factors - despite the designers' intention that it be used
> for publically accessible information it was widely hyped as a generic
> database access protocol, so an organizations' LDAP servers were
> typically filled with information that they wouldn't dream of making publically
> available. Also, there wasn't an obvious global namespace or infrastructure
> that was easy for LDAP users to tie into, nor any widespread understanding of
> why it would be a good idea to do so.
LDAP is but one example, and in some ways not a good one. There are plenty of
others.
> None of this experience seems particularly applicable to the question at hand,
> where we are comparing two different mechanisms for exporting only a small
> amount of information - SMTP, or some other protocol (of which LDAP is only a
> token example). If an enterprise is reluctant to export "information about
> their users" in general, then they will be about as reluctant to do so via SMTP
> as via some other protocol.
I'm afraid this is another piece of theoretical considerations that fly in the
face of actual experience. The obvious counterexample is HTTP.
> I do think it's reasonable to assume that any other protocol server is likely
> to be viewed as a separate maintenance burden that needs to be justified, whereas
> a wart on the side of SMTP will probably be viewed as just some incremental pain
> that must be endured. But if large sites end up needing a separate database server
> anyway to support CONNEG because the MX servers don't have direct knowledge of
> recipient capabilities, then that separate maintenance burden is there anyway,
> at least for those sites.
While I obviously cannot speak for all large sites, I can tell you that
database usage is sufficiently pervasive inside the sites I'm familiar with
that this is basically a nonissue.
> I also believe that trying to use LDAP for this purpose would be a marketing
> disaster - because there is already such a mindset about what LDAP is used for,
> and what kind of data goes into it, that any proposal to expose this specific
> piece of information using the LDAP protocol will immediately get attacked
> by people who are concerned that other informaion often stored in LDAP will be
> inappropriately leaked.
Nowhere did I mention using LDAP to expose this information. So this appears to
be a complete strawman argument to me.
> > 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 suspect the lack of significant interest in rescap is because it lacks a
> killer app - there are many uses for rescap but no one application for
> it sees a significant enough win to drive the people who work on that
> application to contribute to rescap. That and each of those uses involves
> some deployment pain - and the first one involves significant pain, so nobody
> wants to be first. Another way of saying this is that (at least in the apps
> area) we tend to divide our work around product lines - we tend to work on
> email, fax, voice mail, web replication, instant messaging and so on - and
> rescap cuts across all of these.
> (on the other hand, any technology that is initially driven by a narrow set
> of interests tends to get warped to serve that set of interests at the
> expense of others, even if the technology was generally useful.)
> I'm not sure whether this is good or bad, nor whether it is inherent or an
> artifact of our organizational structure. Mostly I view this as a given.
> There are exceptions, but they're rare, at least in the apps area.
> But there's nothing stopping fax people, or email people, or voice mail
> people from considering a standard protocol for the lookup of recipient
> capability information and (separately) from considering whether that
> protocol should be accessed directly or through SMTP. And while I suspect,
> intuitively, that accessing that information via SMTP is actually a
> better way to go overall, I'd like to see some more analysis on it rather
> than a quick dismissal based on experience with LDAP.
First, this is not a quick dismissal, it is a conclusion based on decades of
experience, experiencce in which LDAP only plays a small and relatively recent
part.
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.
> for instance:
> One attractive thing about using SMTP is that SMTP servers for small
> sites can implement CONNEG without a separate server, so the cost is
> kept low for small sites. Another one is that if there is a separate
> server then it's probably easier for the mail system administrator to
> configure his/her MTAs to talk to that server (and to fix bugs in
> that configuration) than for the mail system administrator to configure
> DNS so that external queries go to that server.
> If queries are made via SMTP then the interface to the database is not
> standardized, so MTA vendors end up supporting multiple interfaces.
> Some might see this as an advantage, since it allows use of a variety
> of existing back-ends. Actually enough MTAs support mail forwarding
> via LDAP (or other database) that getting recipient capabilities from
> the same source is probably a straightforward extension.
There's no "probably" about it, although it is also true that more generic
callouts aren't exactly rocket science to implement.
> And assuming that the SMTP client-SMTP server connection has a
> significantly longer delay path than the SMTP server-database connection
> (which seems reasonable) then it could take less time overall to deliver
> the message via SMTP alone than via SMTP + a database query, provided
> the queries can be made in the same SMTP session as when the message
> is delivered.
> I think there are benefits that favor of a rescap-like approach also.
> One is that it allows the conversion to be done by the sender's
> MUA - or at any rate as early as possible - whereas with SMTP
> this is not always possible because a number of sites either
> block access to port 25 on nonlocal servers, or impose interception
> proxies that pretend to be the remote server even if it's really a
> relay or firewall. I'm very much in favor of having negotiation
> and transformation work predictably and with accountability to the
> sender rather than having some random MTA in the chain decide that
> a conversion is needed.
I agree that predictability is nice, but that's not something any approach can
ever guarantee. Indeed, I can argue that a directory approach will lead to less
predictability, not more, if for no other reason than directory access will
tend to work locally but not remotely. SMTP access with appropriate caching, on
the other hand, has the potential to work both locally and globally.
Ned
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.