Jim,
I think your note is particularly useful for prompting us to consider
what the history of Internet does and does not contribute to the
current consideration.
To state my own biases at the start:
1. For all intents and purposes, the Internet has literally no
large-scale experience with interesting policy mechanism operated
among participants lacking prior arrangement.
2. BGP probably counts as an exception, but we should note just how
constrained it is, if we evaluate it as communicating "policy".
3. The DNS is a simple lookup mechanism and our experience with it is
in producing simple records. both in terms of searching
and in terms of complex records, efforts to make it act more like a
general purpose data based have all failed, or at least been highly
problematic.
4. Reliance on the DNS for core Internet infrastructure operation
dictates that its reliability and performance of those tasks be
guarded vigorously, even at the expense of interesting new
applications.
So with that in mind:
JL> In arguing against extensibility, John Levine argues that it's a bad
JL> thing (he used the word "chaotic") to have information in a MARID record
JL> that is not understood by everyone.
I took John's foundation statement as being:
One of the main points of MARID, as I understand it, is to develop
something that can be implemented relatively quickly and will
interoperate among senders and recipients all over the net.
These match my own understanding and are extremely important as input
to a design process. History with Internet standards that succeed in
matching these requirements dictate considerable simplicity and very,
very limited choice in the core functionality. Extensibility is
restricted to be outside that core.
JL> To rebut this, I note that substantially every successful data format
JL> and protocol contains buckets for information that isn't globally
JL> understood.
Such information is never part of the core that is needed to get basic
functionality out of the service. Things work quite well without any
of the extensibility.
JL> For example, consider headers in RFC 2822 mail messages.
...
JL> A similar story applies to the headers in HTTP.
Internet protocols used between participants without prior arrangement
must specify a small, tight core that everyone supports, and that
small tight core must do something very useful. Any extensibility must
be optional value-add.
This is certainly true for email headers, for smtp, and for http headers.
There is a very big and very basic difference between extensibility
support between consenting participants, versus extensibility that
impacts non-consenting participants.
It is also worth noting that extensibility is typically a good thing
only AFTER the core is operational. For all of the freedom with
RFC733/RFC822 headers, folks didn't take all that much advantage of
the freedom for many years. And SMTP options did not appear for 10
years. If you want masses of sites to implement something new
quickly, make sure that development and adoption take a minimum of
effort.
JL> Given that we *know* that we'll need more information in the future
The problem is that we have no serious idea what that information will
be. We all think we do, but there is no experiential basis for
knowing what is true. All of the deployed, successful, large-scale
systems use remarkably simplistic schemes. Any expectations that
there will be deployment of clever, large-scale "policy" analysis
engines is not supported by experience, no matter how appealing such
engines might seem.
I think John Levine's follow-up point, about separation of reputation
versus authentication are also fundamental.
JL> (most of us are here to reduce spam, not just authenticate MTAs), it
JL> behooves us to plan the extensibility now.
Please take a look at the history of the SNMP security field. It was
an example of a place-holder provided with similar thinking. Security
obviously would be needed and we would figure out what that meant
later, so let's leave a field that will be define later.
It turned out that the security that was need required a rewrite of
SNMP.
Extensibility is best provided when there is a pretty good idea of the
details that will determine how it will be used. The problem for the
current discussion is that the "pretty good idea" does not have all
that much empirical basis, nor even community consensus.
JL> SPF's current modifiers are
JL> a step in the right direction (they have the ignore what you don't
JL> understand ethos), but as I've argued elsewhere, they aren't sufficient.
The problem is that there is actually very little operational
experience USING those values to do Internet-scale mail filtering.
JL> PS: John also continues the misconception that anything that uses XML
JL> will be big enough to require DNS TCP. This just isn't true. It looks
JL> like most XML-encoded stuff runs about 20% bigger than SPF-encoded
JL> stuff.
I think the real issue is the generic and potentially unbounded nature
of the extensibility, rather than the syntax used for encoding it. Of
course, verbosity is not without its issues, for DNS records.
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>