Oops, that should have been section 3.6.1, not 3.5 referenced below, and
correspondingly 3.6.1.1 and 3.6.1.2 in my example.
Tony
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.
>
> Tony Hansen
> [EMAIL PROTECTED]
>
> 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
http://mipassoc.org/dkim/ietf-list-rules.html
