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
Perhaps section 3.5 should be rewritten to make that separation more
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.
Mark Delany wrote:
OLD: TXT records are encoded as described in Section 3.6.1.
So I've circulated the draft DKK to a couple of people to get the
roughest edges off.
One of the big questions asked in that draft relates to the
relationship between TXT and DKK semantics. Which one is authoritative
and which one is a mirror? Or should base be authoritative and both
the TXT and DKK simply be particular representations?
I guess by way of example. The MX RR only defines the contents and not
the semantics, so perhaps DKK and TXT should do similar with the
semantics defined in the base?
NOTE WELL: This list operates according to