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