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

Thanks! I guess the logic is: If you can describe a semantic to the order of elements, then its a list/array, else should be a map/object. AFAIK, there is no definition of ordering in kvpairs in DNS-SD, so it should be e.g.: kvpairmap = ?{ +kvpair } kvpair = [ key : str , ?( value: str) } ??

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

On 2. Aug 2023, at 05:40, Brian E Carpenter wrote: > > In CDDL, {...} is called a map, in Python and JSON it's called a dictionary. (In JSON, it is called an object. In Ruby, it’s called a Hash. In Erlang, it’s called a Map. Etc.) > [...] is an array (a.k.a. list). > So mainly the {...} isn

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

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

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

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 w

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

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 h

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

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 w

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

Brian E Carpenter wrote: >> Since we are doing this in std >> track documents (so they get the >> ultimate considerations, of IESG >> action, in effect), the value of >> the registry is that it lets people >> find the document that goes >> with the value. > Yes, makes sense. oka

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

On 26-Jul-23 09:06, Michael Richardson wrote: Brian E Carpenter wrote: > That makes sense, but it probably needs to be normatively specified, > which would avoid any need to change RFC 8995, except perhaps an > erratum to delete that "(list of)" wart. I didn't get the "(list of)

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

Brian E Carpenter wrote: > That makes sense, but it probably needs to be normatively specified, > which would avoid any need to change RFC 8995, except perhaps an > erratum to delete that "(list of)" wart. I didn't get the "(list of)" wart... >> (IP addresses could change not be

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

On 26-Jul-23 01:07, Michael Richardson wrote: Brian E Carpenter wrote: > Yes, but you can map them in CBOR just as > draft-eckert-anima-grasp-dnssd already describes. (Think JSON but code > CBOR.) My only real concern is how to extend the objective for the > AN_join_registra

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

On 25. Jul 2023, at 15:07, Michael Richardson 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,

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

Brian E Carpenter wrote: > Yes, but you can map them in CBOR just as > draft-eckert-anima-grasp-dnssd already describes. (Think JSON but code > CBOR.) My only real concern is how to extend the objective for the > AN_join_registrar. It seems lame to use plain text when a JSON-style

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

From: Michael Richardson Sent: Monday, July 17, 2023 11:47 PM To: Brian E Carpenter Cc: Fries, Steffen (T CST) ; anima@ietf.org Subject: Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd Brian E Carpenter wrote: > I can't answer that, but note that the AN_Proxy and AN_j

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

use this approach also for GRASP. Best regards Steffen > -Original Message- > From: Michael Richardson > Sent: Monday, July 17, 2023 11:47 PM > To: Brian E Carpenter > Cc: Fries, Steffen (T CST) ; anima@ietf.org > Subject: Re: [Anima] New Version of draft-eckert

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

Brian E Carpenter wrote: > I can't answer that, but note that the AN_Proxy and AN_join_registrar > GRASP objectives defined in RFC 8995 include an objective-value field. > For AN_Proxy that field is "any" so is currently undefined and could be > extended in any way we want. For AN

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

Steffen, On 18-Jul-23 00:46, Fries, Steffen wrote: Hi, I've read the latest version of draft-eckert-anima-grasp-dnssd-05 (https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/ ), which has been updated just recently

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

Hi, I've read the latest version of draft-eckert-anima-grasp-dnssd-05 (https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/), which has been updated just recently. It targets provisioning of service discovery information similar as mDNS but solely relying on GRASP. This approach see