On Fri, 2004-06-04 at 12:02, Bob Atkinson wrote:
I can tell you that, having worked on Caller ID for more than a year and
a half, and having had it basically stable since a year ago, I
continually and routinely keep coming across valuable new things that
people will want to say about these sorts of policies.
If you want examples, take a look at the attributes we have on the
Caller ID <m> element to today. Or think about what one might wish to
say about ones willingness or desire to participate in forensics
gathering to support prosecution of spammers. And so on.
I'm quite convinced that this sort of innovation will only pick up, once
this stuff is used more heavily.
The ones that we can think of before we spec-freeze we can build in. The
other ones need a robust extensibility mechanism for.
Bob
You are making my point. If XML syntax is to be used for the text
record, this syntax must be both concise and ouster if to be used within
DNS. The virtual header applied to the text record should begin:
<?xml version="1.0" encoding="US-ASCII" standalone='yes'?>
This single document approach gets rid of a concern how this can be
registered with IANA, or how extensions to this definition are applied.
If this is to be extended, it would be done through the standards
process where the token _MARID-* indicates a single stand-alone header,
all backward compatible in succession.
There is a good reason to lock record definitions down. A vendor may
consider it good to have continuously evolving mail standards with
features added for every possible contingency without a need for
review. This would then allow continuous revision of basic mail
software as these features diffuse. Those using such a system would
likely think differently as each vendor adds their trademark widget that
overlooks network integrity and security.
Such innovation MUST NOT occur as appendages to a TXT record. There is
about 100 bytes needed with XML to just declare these definitions which
often contain several k bytes of structural information. This says
nothing of the added payload these "features" could create. There is no
means to design a safe and sane record if the goal of this standards
process is to leave the record definition wide open.
Any value there may have been using XML syntax is lost with such an
open-ended approach. Such feature rot will be destructive as these
features grow the size of the text record without recourse. Records
queried for every message domain seen within a mail stream should
consider the impact of unlimited growth together with the possible use
of secure DNS.
Stop the practice of tossing in a laundry list of definitions. Define
the structure in a single clean document where it indicates a splice
point for the insertion of the TXT rr following the token. This single
document would then define both the prefix and the suffix needed to
interpret the TXT rr. It would also mean those writing software to
interpret this document could anticipate the scope and use of the
information without being saddled with an ongoing chore of revisiting
this process every few weeks or months. Having a standalone document
also reduces the complexity of design needed to parse the record.
Define the use of the record adequately to be reasonably certain a new
draft will not be needed in the next few months. If it becomes apparent
over time more is needed, expand the header to include this "vital"
feature not considered during the initial design. A DNS text record can
not be considered as a web page where everyone is allowed to add their
John Henry.
-Doug