Jon,
things like layer violations are a concern for good and serious
engineering reasons. also good and serious operations reasons.
JK> Layers are tools for problem analysis. Layers can always be collapsed if
JK> the problem space covers more than one. It's not necessarily sensible to
JK> recast a problem to fit into a layered model which was designed for another
JK> problem.
Layers are tools for design, as well as analysis. Collapsing layers
requires very, very careful attention to the implications.
Layers provide discipline. Crossing layers requires even more
discipline.
In this case, one of the implications is to kill reall
store-and-forward and real mobility, as has been described quite a few
time.
JK> Taking all that into consideration, I've come to believe that
allowing the
JK> publisher to identify the identities that a record applies to might
be the
JK> best way.
I'm not entirely sure what you mean by this, but it sounds quite a bit
like defining a general method of letting others define specifics. On
the average, protocols that do that do not work.
JK> Not at all, we can specify a set of options. Write them in stone if you
JK> like. Let a publisher choose which suit them.
In the world of Internet protocols, options are often very expensive,
adding quite a bit of implementation and operations complexity,
increasing the likelihood of bugs, and often adding small practical
value, unless used primarily as a means of evolution, rather than
long-term variation.
One of the real secrets to Internet protocol success has been the
definition of tight, useful protocols with common, core facilities
that do not require options. If you want to see an example of the
alternative, take a look at the OSI protocols.
On the average, artificial intelligence algorithms do not work well at
the core of a high volume networking service like email. Alas, that's
the technical base that would be required to implement the sort of
description-based service you (and others) are suggesting.
JK> I'm never sure
JK> what anyone means by the term, it's been so abused. If you mean "simple
JK> heuristics", I agree that this is probably what's needed, but I can't see
JK> that it would be hideously expensive. Equally, I don't know what you mean
JK> by "at the core". I'm guessing you don't mean "in the infrastructure".
As I said, this approach does not work for high-volume, transfer
protocols.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>