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.
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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html