Tony Hansen wrote:
Base section 3.5 currently defines both a set of values expected to be
found by any query mechanism, and a representation of the values when
provided by any textually-formatted query mechanism. The discussion of
q=dns then constrains itself to using the textual format within the TXT
RR record.
Perhaps section 3.5 should be rewritten to make that separation more
explicit:
3.5.1 name/value pairs returned by any query mechanism
3.5.2 a textual-format for representing those values
If this were done, I would have no problem with punting the semantics of
the DKK name/value pairs to section 3.5.1. And then the DKK draft would
define exactly two things:
* the q= parameter name and/or options
* the syntax of the record
This also provides a basic template for any future query mechanisms.
Doesn't that presuppose that q= defines just isomorphic semantics with
different transport and/or encoding? Is that really what we want? I'm sort
of thinking that if we in the future wanted to extend dkim, would we always
want, say, TXT to have to be extended too? And especially in some far future
where we wanted bigger records and decided that TCP/not-DNS was a more
appropriate transport?
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html