IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 28 July 2023 22:17 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B75C151074 for <anima@ietfa.amsl.com>; Fri, 28 Jul 2023 15:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.091, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgOPFfM04Aj8 for <anima@ietfa.amsl.com>; Fri, 28 Jul 2023 15:17:43 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED975C15109B for <anima@ietf.org>; Fri, 28 Jul 2023 15:17:43 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-686ba29ccb1so1633970b3a.1 for <anima@ietf.org>; Fri, 28 Jul 2023 15:17:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690582663; x=1691187463; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Ot4wjd+FNBuLIJNrFup3rQk6fgjIF+9jP0ujxRtk0N0=; b=rolqgmwJh+FmCabWtk/NJLULMAz4+XFPr1VOa78wjPg7ZaJdqw64SKT5Cl+wFduYKi RyHJq9bP6s/MTfjFLPOqxNPx+JVhBp3tz54mh0XDk1Qx6XHtA/r8TQXw81N+KSX9Kx/a 7Wip/W+bHK0eQM2OdL56PDFu0HCcxy8/7FI+sFHkj9RCowGZlcw3SYDkYEOj/+030yGR vnj5F91SIBPmO47FpP6+IGn7krt8rEyj0HREDF82Lw1UBiBNz0wL6skwjagu/q6eQ9sX y+D+8rw9iY94X+zAcZOfYwiGl1AqSNTdKGlKSqYBQhwnIgDRMc18ozpCXAC3VXyVBYcn /jbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690582663; x=1691187463; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ot4wjd+FNBuLIJNrFup3rQk6fgjIF+9jP0ujxRtk0N0=; b=U1/bilSZ3k6lMKQZsGRRlE/Rq9G7pC4swVkR6PCwO8JScjFGIlqHK9CKQGltwWXgCV REkxMkLULQAKOhuqQnuLocIkZX1Q/a/poBbDldqwbXhhJwyDp2WWdZApNtlHpe5OnazT 9KRoTfCRZo5DDIaqqjzRZgEmOQ712HWvkx1OZwcPhj7xw90X7irs6skJBLob535E5DlB 2oh2MjjeCIGCZSM+n4cp98dGgjeFJwezF0CZgc4KGSE2hm90kDDCouxJh0H7kcJ4GiJI oOaKJGcnZtLDGh4pbiTi8Jn7g9cY+50xp3PFmBtXOfZAblQl49UzNsxwgOAHGGad5Rw7 MKXw==
X-Gm-Message-State: ABy/qLYa1YiXxVjBy+pr6/ke6aNs7NKgUg6VuCgp4hUP5VcPcj7R40z6 gDUXKRj2Bx7EiBD4aMZU/K+PfKwUwVQsQA==
X-Google-Smtp-Source: APBJJlF00OtIEslrcMa+FWb+998QxKgu0zxjNxjIlxuYbUBUsrf5q8Enaf7WSVI87ZeUVdwMwkS8uQ==
X-Received: by 2002:a05:6a00:2e8d:b0:667:d0ff:6a0f with SMTP id fd13-20020a056a002e8d00b00667d0ff6a0fmr4058986pfb.5.1690582663321; Fri, 28 Jul 2023 15:17:43 -0700 (PDT)
Received: from ?IPV6:2406:e003:10cc:9901:b2e1:1101:7ba7:19fd? ([2406:e003:10cc:9901:b2e1:1101:7ba7:19fd]) by smtp.gmail.com with ESMTPSA id g23-20020aa78757000000b006758ae3952bsm3637519pfo.122.2023.07.28.15.17.42 for <anima@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jul 2023 15:17:43 -0700 (PDT)
Message-ID: <08b559ce-7903-1887-f51d-a3dcb49c0d36@gmail.com>
Date: Sat, 29 Jul 2023 10:17:38 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: anima@ietf.org
References: <DB9PR10MB63549176EF0E405161B85649F33BA@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM> <1808d3ce-c03a-6871-a208-0845ad691427@gmail.com> <4024.1689630438@localhost> <DB9PR10MB63543A608EA0141A9860F65EF302A@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM> <6c2888e7-a2bd-b5ba-2aea-04dc26e95173@gmail.com> <2512.1690290441@localhost> <1C974DB3-2FCA-4B41-83E7-A9C095D7512B@tzi.org> <ZMEjTHl41WmjELL5@faui48e.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <ZMEjTHl41WmjELL5@faui48e.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/ZNTDBpLXhk4hp1DBx3u7vlFSv0Y>
Subject: Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jul 2023 22:17:47 -0000

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 <mcr+ietf@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
>

v2.23.0 | Report a Bug | By Email