Re: [dnssd] [core] CoAP resource discovery and DNS-SD

Toerless Eckert <tte@cs.fau.de> Sat, 14 May 2022 14:28 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD28C14F736; Sat, 14 May 2022 07:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 JjJwicfY218R; Sat, 14 May 2022 07:28:34 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F577C14F72F; Sat, 14 May 2022 07:28:31 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 5D0C358C4AF; Sat, 14 May 2022 16:28:26 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 468284EAEB1; Sat, 14 May 2022 16:28:26 +0200 (CEST)
Date: Sat, 14 May 2022 16:28:26 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Carsten Bormann <cabo@tzi.org>
Cc: core@ietf.org, dnssd@ietf.org
Message-ID: <Yn+8iu6vpWiqnIQU@faui48e.informatik.uni-erlangen.de>
References: <Yn7nnX096f0LdonI@faui48e.informatik.uni-erlangen.de> <C813906A-E7EB-4A69-9E94-14528E49E607@tzi.org> <Yn7rThJtz+VhJsa0@faui48e.informatik.uni-erlangen.de> <9AB469D2-FC4B-4BE2-A8D8-265378B85328@tzi.org> <Yn7xUaU4yzVz+qkd@faui48e.informatik.uni-erlangen.de> <510DBA42-6057-417E-9613-BD18C37E9EE8@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <510DBA42-6057-417E-9613-BD18C37E9EE8@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/bDWHUb5o38xEznfaY5JQ8rURqIc>
Subject: Re: [dnssd] [core] CoAP resource discovery and DNS-SD
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2022 14:28:37 -0000

On Sat, May 14, 2022 at 02:08:00AM +0200, Carsten Bormann wrote:
> > Likewise, for other parameters, the client gets replies from multiple
> > instances, but they resource differs in some details and those are expressed
> > in those additional parameters.
> 
> RFC 6690 is based on web linking, and that is quite flexible with request to defining target attributes.

Except that rfc5988 didn't have the element of discovery or multicast, but rfc6690
came up with them - and then did not inherit whats good about DNS-SD, which
arguably was the best and most widely deployed discovery mechanism we had defined.

> If we think this is a use case we want to address, we could define these target attributes.  I’d assume it would be pretty much up to the querier to interpret them, but the attribute definitions should be well-defined.

Sure. How about this definition:

REQ: GET /.well-known/core?rt=<resource>

     RES: 2.05 Content
     Content-Format: 40
     Payload:
     </b>;rt=s.service-name;p=num;w=num;key=value;

If service-name is an rfc6335 registered service name, then it
can be mapped into a resource type by using the s.service-name notation.
The prefix s. is reserved for this purpose, no other resource types shall
use it.

p(riority) and w(weight) have the semantic defined in rfc2782 and
are used by the requester to select which discovered instance to select.

If the service-name uses rfc6763 key-value property pairs (encoded in
DNS TXT RR), those are represented equally as key=value.

Given the likely slightly different string rules in coap and dns-sd,
it is necessary anyhow to design the possible values such that they
conform to dns-sd and coap rules. Hence it should also be easily
possible to pick key names that do not conflict with pre-existing
coap target attribute names.

This should be all there is to it.

Actually a Q: In DNS SD, we might have a key=val1,val2,val3
Given how "," seems to be a reserved structure character (like ";'),
what would be a good separator inside a value to structure it ?

Cheers
    Toerless

> RFC 8828 (and 5988 before that) did not create a registry for target attributes.
> We followed suit in RFC 6690, but have since toyed with the idea that maybe we should set up a CoRE-specific registry, as encouraged in [1].

That is fine, but when designers of solutions are toying with
supporting DNS-SD and COAP i think the main issue is to avoid
duplication of registration effort or introduction of inconsistencies.
Hence the above text i wrote would avoid such duplication and rely
only on rfc6763 - and coap-friendly definition of the DNS-SD
key=property pairs by each service-name (== resource type).

Aka: With all the many services registered by IANA for DNS-SD, so
far there does not seem to have been a need to standardize any
key=value across different services, thats why i suspect we
would also not necessarily see that need in CoAP.

Cheers
    toerless

> Grüße, Carsten
> 
> [1]: https://www.rfc-editor.org/rfc/rfc8288.html#section-2.2

-- 
---
tte@cs.fau.de