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

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

The relevance of HTTP is even less obvious to me because HTTP and directory 
services (LDAP or otherwise) tend to be used in very different ways.  I don't 
see many sites exporting their company directories via either HTTP or LDAP.  
Nor do I see how any of this is relevant  to the problem of exporting recpient 
capability information for content negotiation.

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

Well, I guess it hinges on what is meant by "large".  Are there a significant
number of sites "large" enough to not have their MX servers deliver directly
to recipient mailboxes, but not "large" enough to be already using a database
to store recipient information?  I suspect the answer is yes because there
are other reasons besides scale that a site would not have its MX servers
deliver directly to recipient mailboxes.  Inbound firewalls are fairly common,
and some of them operate as relays.

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

not to dismiss your experience at all - but your stated justification didn't
seem (to me) to be particularly relevant.

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

again, is this a fax-specific extension or is it supposed to be generally
applicable?   I'll readily admit that fax machines don't need a directory.
but should the level of interest within the fax group be used as a measure
of the merit of the idea for other uses of email? 

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

The last two statements seem fairly odd.  Maybe the problem is the use of the
word "directory" which isn't my favorite word for this anyway.  So let's not
call this a directory - let's call it a capability discovery protocol.  Now if
the capability discovery protocol is defined in such a way that in order for
your recipients to benefit from content negotiation you have to make it accessible 
(just like if you want to be able to accept mail then you have to make port 25 
accessible) then it seems fairly likely that sites that want to enable content 
negotation for their recipients will do so.  On the other hand, port 25 is one 
of the few ports that is commonly blocked/filtered for outgoing traffic - 
perhaps even more often (and with more drastic filtering) than port 80.

So the argument that a facility that requires direct connection over port 25
(from the origin to the MX server, not necessarily to the final MTA)
in order to work properly (i.e. in order to let the sender control the 
conversion) will function both locally and globally seems a bit dubious.

Keith