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

[Toerless Eckert <[e-mail]>]

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...

> > 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 <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/anima
> > 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]