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" ] 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. [ [ "key1", "value1" ], ... [ "keyn", "valuen" ] ] 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. 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 -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima