Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

On 02-Aug-23 14:22, Toerless Eckert wrote:
> On Sat, Jul 29, 2023 at 10:17:38AM +1200, Brian E Carpenter wrote:
>> On 27-Jul-23 01:44, Toerless Eckert wrote:
>>> DNS-SD TXT RR's are a sequenze of zero limited strings "key1=value1" ... "keyn=valuen"
>>>
>>> In my current grash/dsn-sd draft i have just proposed to encode this in
>>> CBOR with as little as possible changes, e.g.:
>>>
>>> [ "key1=value1", ...  "keyn=valuen" ]
>>
>> You have? That's not what I see in draft-eckert-anima-grasp-dnssd-05
> 
> I guess the draft is missing an example, but the definition:
> 
> *( &(kvpairs:7)      => { *(tstr: any) },
> 
> is meant to be that... and now writing it, i am again showing my ignorance of CDDL...
> 
> *( &(kvpairs:7)      => [ *(tstr: any) ],
> 
> Sigh.. what's the difference...

In CDDL, {...} is called a map, in Python and JSON it's called a dictionary.
[...] is an array (a.k.a. list).
So mainly the {...} isn't ordered and  [...] is ordered.

    Brian

> 
>>> Thinking that one needs to be able to parse this when using DNS-SD, so why
>>> parse differently. But of course that logic was flawed, only e.g.: a
>>> GRASP/DNS-SD proxy would need to be able to parse both encodings. And you
>>> obviously want to use the maximum of CBOR and minimum or none of
>>> application parsing.
>>
>> Exactly. And the way you use maps is well suited to any programming
>> language that knows how to use JSON maps, and much easier than
>> parsing the rather primitive formats in DNS records.
> 
> Right.
> 
>>> [ [ "key1", "value1" ], ...  [ "keyn", "valuen" ] ]
>>
>> (N.B. That is lists, not maps. Not that it matters much.)
> 
> Right. Btw.: In DNS-SD, valueI is optional, and if left out, the assumed value is "1",
> that need to be in our encoding.
> 
>>> And given how DNS-SD also has the shortening option "key1" implying "key1=1",
>>> this could also be
>>>
>>> [ "key1",  ...  "keyn" ]
>>>
>>> If all the keys only had values 0 or 1. Which is what Esko proposed.
>>
>> You can define that the *absence* of a key means False, 0, or "" (empty string),
>> *presence* of a key alone means True, and *presence* of [key, value] means
>> a value. I'm sure that's parsable.
> 
> I thought the alternatives for each element would be:
> 
>      [ [ "key1" ], ...
>      [ [ "key1", "value1" ], ...
>      [ [ "key1", [ "value1", ... "valueN" ], ...
> 
> The last one is kinda inofficial "," concatenated key1=value1,...,valueN
> 
>> But I still like maps.
> 
> I am lost right now about pro/cons... Need to find the 8" tape with my CBOR/CDDL braindump ;-)
> 
> Cheers
>      Toerless
> 
>>     Brian
>>>
>>> Chers
>>>       toerless
>>>
>>> On Tue, Jul 25, 2023 at 03:46:11PM +0200, Carsten Bormann wrote:
>>>> On 25. Jul 2023, at 15:07, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>>>>
>>>>> I have resisted suggestions that we put an array for the objective-value, and
>>>>> also that it have a string that needs to be parsed like "mode=prm,foo=1,bar=2"...
>>>>
>>>> You give a good reason not to do this at all.
>>>> But if you want to do this, do resist the urge to do a parsable string by all means.
>>>>
>>>> (I need to write that draft, CBOR anti-patterns :-) (*)
>>>>
>>>> Grüße, Carsten
>>>>
>>>> (*) Yes, anti-pattern drafts are now a thing:
>>>> https://www.ietf.org/archive/id/draft-bormann-restatement-00.html
>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> Anima@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 