ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Jim's issues - one more try

2007-06-11 16:18:22


--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