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

[Eric Allman]

--On June 11, 2007 3:48:00 PM -0700 Douglas Otis 
<dotis at mail-abuse.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