ietf-mxcomp
[Top] [All Lists]

RE: On Extensibility in MARID Records

2004-06-18 10:31:45

In discussing record sizes, Doug Otis constructs an argument about how
many address ranges or domain name references one could fit into a
512-byte DNS packet.  Sumamrizing his numbers, and filling in the blanks
from our actual proposals, we get:

               theoretical max   SPF today   XML as proposed
               ---------------   ---------   ---------------
Address Ranges              21          20                17
Domain Names                18          17                14

While I think that Doug believes this damns XML syntax, it actually
shows how reasonable XML syntax is.  There are probably only a handful
of domains on the face of the earth that send mail from more than 17
different address ranges.  Since that handful constitutes the largest
ISPs, any effort spent fetching their records (possibly through a couple
of indirections) can be amortized over a large number of mail messages.
(Doug's claims about bandwidth spent fetching records exceeding
bandwidth spent receiving email fails on this point.)

Doug then goes on with a bunch of calculations that show that, for
typical sized organizations, they're nowhere close to the limit.

He then says:
The space that is claimed to be available will be consumed by
perhaps a 60 byte XML namespace declaration. This is to allow
vendors the ability to "innovate" and there would be no review
of these declarations or associated payload. (A very bad idea
in my view.)
and later
Okay, now you pick two and then the next vendor picks a different
two.  These great innovations don't fit without expecting these
records to chain and chain and chain and chain and chain and
chain and chain and chain...

This shows several misconceptions:

1. Vendors don't force anyone to publish any extensions.  If there
   are vendor-promulgated extensions, presumably a domain will only
   publish a record that uses them if that domain sees some value
   in it.

2. The current spec is carefully written to allow IETF-standardized
   extensions with no penalty.  This sounds like the right balance
   of burdens to me:  the standard way is cheap, and the non-
   standard way costs.

3. Regardless of what happens in this debate, there *will* be
   extensions.  A domain that decides it's useful to publish
   the night-shift janitor's Hilbert number will stick
       night-shift-janitors-Hilbert-number=7
   onto the back of their SPF record.  No standard can keep
   this from happening.  Indeed, domains experimenting with
   doing this is exactly what leads to follow-on standards.
   A major point of XML is that it provides a way for
   independent organizations to do this, *without needing
   to first coordinate with each other*.

Doug then goes on to make a number of comments about other extensions I
mentioned.  To be very clear, I am NOT seriously proposing these
extensions at this time.  I do NOT believe that they are all useful.
They're certainly NOT yet well thought-out.  I merely brought them up in
response to John Levine asking what kinds of extensions had been
considered.

-- jimbo