--On June 11, 2007 3:48:00 PM -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:
On Jun 11, 2007, at 3:02 PM, Eric Allman wrote:
My thought would be to search for a new record type if you can
(i.e., if your resolver supports the new type, be it XPTR or SSP).
Wildcards would be used to catch these. If you can't, or if
there is no such record, then fall back to TXT, at which point
you have to search up the tree. The intent would be to
(someday) deprecate the TXT search, if possible, which it
probably isn't, but it does give you a way to do the lookups
more efficiently (wildcarding) if both sides are willing to
play. My hunch is that most of the big players will.
It would appear section 5.1 item 3 of SSP requirements excludes use
of wildcards.
3. SSP's publishing mechanism MUST be defined such that it does
not
lead to multiple records of different protocols residing at
the
same location.
My interpretation of that is that a "place" is defined by an RR type
as well as the address --- this requirement is to avoid overloading
of TXT records.
A wildcard record of any type MUST appear at the _same_ location as
those of other protocols also making use of a wildcard resource
record.
If SSP were to define a new RR type, must this RR type always
remain backward compatible, or would there be versioned RRsets? It
seems likely other protocol extensions will attempt to extend such
an RR record, much as was done with TXT RRs.
I'm assuming no versioning, and that other protocols would define
their own RR types.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html