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
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.
[ [ "key1", "value1" ], ... [ "keyn", "valuen" ] ]
(N.B. That is lists, not maps. Not that it matters much.)
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.
But I still like maps.
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 <[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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
