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.
> 
> Then you haven't looked very hard. The former is quite popular; the latter
> practically nonexistant.  And the fact that the same information is exposed
> either way yet one approach is preferred is directly relevant to the matter
> at hand.

what can I say - most of the company directories I've seen are not publically
accessible.  I don't doubt that many companies use HTTP to provide internal 
access; whether they make them available to the general public (which is what
I meant by "export") is a different question.  

> > > 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.
> 
> My point was they may make it available internally but not externally. And
> using anything that remotely smells like a directory protocols makes this
> outcome far more likely.

ah.  okay, I think we're in agreement about that (and that was very similar
to my point about LDAP) - though whether this capabliity discovery protocol
smells like a directory protocol may to some degree be a matter of social 
engineering, aka marketing.

> > 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.
> 
> Keith, my point was and is that the minute you start talking about using a
> directory protocol -- and I insist on using the term because it's the directory
> aspect that's important -- it makes the whole thing problematic in a way that
> piggybacking the information on top of other type of protocols does not.

well, if *we* insist on calling it a directory protocol then of course people 
will confuse it with other things they call directories.  On the other
hand sites seem happy to consider exporting limited information via DNS,
and extensive information via HTTP, SOAP, .NET, or whatever.  So if the
marketing lingo has to be "recipient capability web service" or some such,
so be it.  (as long as we don't actually *use* SOAP or .NET... :)

as to whether rescap would be branded a directory - the number of people who 
kept insisting that it should be LDAP was fairly significant, indicating
that many people couldn't readily distinguish the two problems.  this
even though one of the major reasons for making rescap a separate protocol was 
to distinguish it from directories and specifically to have a mechanism 
tailor-made for exporting public information.  but frankly part of that problem
was that some LDAP people were seeing rescap as a competitor/threat to LDAP.

as you say, it's not a sane world.  URNs have an even worse mis-perception 
problem, they always have, and it's not clear what to do about it.

> You can talk till you're blue in the face about how this is capabilities
> discovery, how that's intrinsicly different from a general directory
> protocol, and so on and so forth. It doesn't change the perception that
> a protocol intended solely for looking up stuff, no matter how innocuous
> that stuff is, no matter how divorced from the cporpoate directory or
> whatever it can be made, is somehow more problematic than piggybacking
> the exact same information on top of other protocols.

okay, I'll concede the point that there's this dark cloud over things
that (in the minds of network administrators) resemble directories.  
I don't think that should by itself stop working groups from using things 
that resemble directories if that's the right technical solution,
but it's useful to be aware of it.  it does I think illustrate that good
technical design is not always sufficient - unless we somehow convey
to users an understanding of new protocols, how they're meant to be used,
the risks associated with using them, etc.  And we haven't been very
effective at that since the 'net grew up...

> > 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.
> 
> I have pointed out previously that such direct connection isn't required by the
> present proposal. So this is nothing but another strawman.

ah, but either the client has a direct connection to the MX or it has to
relay the message to some MTA which may or may not be under control of the
client.  so the relaying case introduces the same problem that OPES had
when it was first proposed - that of having an intermediary make transformations
to the content that aren't authorized by either party of the conversation.

Keith