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+i...@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

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to