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

Esko Dijk <esko.dijk@iotconsultancy.nl> Mon, 16 May 2022 08:37 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBD2C14F748; Mon, 16 May 2022 01:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 (1024-bit key) header.d=iotconsultancy.nl
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 q5VXdlqTk5_j; Mon, 16 May 2022 01:37:38 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E859C14F741; Mon, 16 May 2022 01:37:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EBjpOZqCPcWrhhAv5WoGdVxtplcpeGkwTungafrOYfG+7u65Rg4KsjHy0qYPCyuEy+PMPiYIedw5XFBjWhhdOLILu57u4cYNw8QzoyoatQj8m2nlSutVI8LBIOH7PAzCUpe5z0NA5BYJBnnQ7J+2s5wlTl7Z9fl4zrgpwkdWllv12o30HKEjWvZg5TPgM9vspUUuy8iQi7Fzq0hPYJqyUxKgmqnM2sxu1fKOtsprmuMas1gnzdamhF+tlNDJcy15eJ8Z73Fjxw4+rQoM3EVoRPe5EsgxISFCO8YU0hdq2hv5Wl/NRDRLSsOWY9btgpd66X4m9Jti6i9fC3jmyCF2zA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DQUyTYBzc9ukJSILka9l6+dKI5Es/91uCZOE9DuWl08=; b=VyjxFykqOIgRXvqlHMH7jgf7Na7RXCyoa+hOwG3FVge/KiXsYqRaQe2uzVJZpoyR0+W9tkSK8ccNqYWUtmymPkYvnrd65FCXEFhfy1Z2zhoygVGKJPvDo2oinv2G0q16hZGjVnIiKl9y1T+ziRMzaLUykiVQp/T2wQVQmFWE8GWuwieSoSWMQvANxR8CmsQiZ7D90gRN2TMH+5QKsCQoE8uPF8zaOKsq7RvcoU54Gz61Nb4VidR4MkiSi6cpIdKj5CqRHaJ97LFCc2cJ4gwTYnXPZUYnF2DLFzwEA3rTbJ9LyyXG5eOmsSSlYw6DgmJVmpCmMv+rfq8PaALOiQDLlg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DQUyTYBzc9ukJSILka9l6+dKI5Es/91uCZOE9DuWl08=; b=mxVrv6FrJhT5z2DQeA0UUqpo98N8rJNBXhYQWKNDIdOr9m71r3Dcd5rGi6kPUvwBW/r1pfWMnyagvd+9TKAE9O91rOVBUUEXXyp03S0YR0lmCSqlSgIoESOUa1LgamqpxR4Q5zPg8Yt04bEITROuRMWQTWP84qPrOOhKuK0G9hY=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by AM5P190MB0467.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:1b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.16; Mon, 16 May 2022 08:37:31 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::d19a:a24c:bd5c:95da]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::d19a:a24c:bd5c:95da%9]) with mapi id 15.20.5250.018; Mon, 16 May 2022 08:37:30 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Carsten Bormann <cabo@tzi.org>, Toerless Eckert <tte@cs.fau.de>
CC: "core@ietf.org" <core@ietf.org>, "dnssd@ietf.org" <dnssd@ietf.org>
Thread-Topic: [core] CoAP resource discovery and DNS-SD
Thread-Index: AQHYZyXL8eeINMqkC0KaoWxMkPUweq0dfwwAgADwZwCAACy+AIACjABA
Date: Mon, 16 May 2022 08:37:30 +0000
Message-ID: <DU0P190MB1978F84C3EF1762E81609B24FDCF9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
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> <Yn+8iu6vpWiqnIQU@faui48e.informatik.uni-erlangen.de> <1B438E3C-57C9-41CE-8885-AF37EDDEE106@tzi.org>
In-Reply-To: <1B438E3C-57C9-41CE-8885-AF37EDDEE106@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6e4b07ea-01ef-40f7-f902-08da37175105
x-ms-traffictypediagnostic: AM5P190MB0467:EE_
x-microsoft-antispam-prvs: <AM5P190MB04674A16E52FDDC49A2274D4FDCF9@AM5P190MB0467.EURP190.PROD.OUTLOOK.COM>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FV1Td73QX4a3kgjeDCT+Z1KHa4q7se9MF39Lzq+Mz8yqyym2vxKYmqveuumBc8023lRwl0bUJCrcJd3GonL65JjYeqFVRElcmV974wW1k03CEhcKJ1tlRU1S7tZNemn6F9OE6RvP2NPF+EbsFkB4+B90AaudgpaPHd35Jogd3A+6nOyvlsQTeB6lZFgwU2umr/cP0feG4IyZPN+4QN9Eynit1Ygu5pJ3/SrdQigLMw9UQNJNAOoSoctdEq7bK/vXLUA/ujX/nAR4zQZPqi/f9pQ9JYHfLH0DBRcEQcLTFBsBc7sFeIMv/NGLvOGtdYmDKilKu2Covb4jrzM49D/dUiGx26ygUe/0lytpyK4cFbtTPfCBU1+bpdg8PdOOCb/tT1UDidu6Oq9Aked9+Am3lnP6AUfkK3g7EK6SbOTM1cKKwrWLqdSb9jeD/c5FfjUDQkTjlQuyCTaHAVu+1O43QYVigEfVFz6WfleY5j5v0v4B/916C9BuIQGs4nJN20BIm3cSK5KcOI22wzv9PJp0hhv91Ygjed3IHFj+EROskHRVVNEe8AypjNpSip7O3Eijqe1TKDN29b5zXKpwNLd6ypOLk8qyteB4DQ/VvGmQeVI382kKi5+SxL8br7THz9f4OZ1irXJ9wWawGQfT7xjeaL77MYeIV/wejuqIzflQ0c6e3uSauFWSnaiKmwB5iZduLrC4HTeL/SciocmkhMAWqOOUZ2AtKsjTRJVmdQrnQwjvVmYh5OT3vQ76hm/tkLOCYoqnJDBE5rwiqAa3MbjjaB9kEqnK+HhZUdYQJ1+bHD8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0P190MB1978.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(136003)(376002)(366004)(346002)(39830400003)(396003)(76116006)(66946007)(4326008)(66476007)(66556008)(66446008)(54906003)(7696005)(83380400001)(33656002)(8676002)(64756008)(110136005)(44832011)(53546011)(9686003)(41300700001)(6506007)(316002)(66574015)(5660300002)(186003)(52536014)(122000001)(8936002)(2906002)(55016003)(38100700002)(38070700005)(71200400001)(86362001)(508600001)(966005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0: WizzwI3YYjX6/10aFsVvV5j6XfRqpYCA4svc0kek+kp3uzeLERGnlzjeD+ydeIfHdC5EG2jRb7m2asbMIrhSheY47XRsYOkZZSNsiUigcd1wn7DEQU7hQAb3KX6ohNWsmTrObaw+seEZrIqNInoNw1s8POZyaf9AIJ/BVqNzUXaLhdpy7WKHt0iVJdUUe4FtA4Yat8BUfgivZc0WUluQd3tuxpd1f6RwzWIoguffniAwGkRV4fg6vxEkh1fZhbqiIl7RVrp/AdEYDsy36LOE7O9hz7huqquW0t8OWnk1GxBTMQtcfwfaxnLXX1+OVYXINsCDKP/BCClP5IdbJMyN4hnBHl/Rd8S1BWwxy4ESDcghRqBmsFjANi+qZ6xczFUPqL4EdUbVT7tUSwlpCIig4i7bWTO5wZrXobWHgFDcDgb0+6aIMgCtuqc36Me0V/wAZ2bzKMLK+JCZ9sagi8U1f/pqPZ825jKHYpCFVYKgNwD3JWQTrvw9MAaHLe+MfqbSz9EC2332OQN9a99wwDciJTTHUnfBTEJy3rseWXET2jFBoxNuJtQZZqAKCwoBdLV4qkn0a56WqeDPtA8Y4P2eXYHnQdGwYndV6SmLdC9PqZsD5KqlJ87ikOEnkoNU5Tdsy6Of/+csVZMAsOQxldf/zud4LE4ZFGo64G+lEadupuAY0emuPW6tUqU5SPSbwoO3vfCEK/rfd6wfRU1vy2/4gPMP2P/gjKC///Rl7zD9jq+DKExUOBvLKQLJVoTqnIj33xBzfDhBc2EcCbVi1RRyrFS3wOp8vfQMs2qDwIDjAkGDtA9NhftORcZ3l8Jv9UaH6zOgldgwUIDFYuKhaiKwnhJ3aq+RXjSHJe74HPoXxod47L+pVlfwLFUZrHzbSoQqxeI4iSuwLx5sTKugIq8jF1j/nUxYV4ChAI8wLpXaOBrw4jQunRFi/Lj257ZJi+4bm521mUUgXaL8HOahEUsvy97g99RI8WoJmoU68TPFcV4Z72zxeDGLbHzOujbNw1vd5D0rX3Sw1ukhqF7Ng0KyoVYU0/Wj+aKrnr9OEgmTZb8FYK14MGHoR+4XX7Qe6DndB4yQzj1tyPF1roAjHfrDOE952VmNyfvTa8MjqpeJivxJmVgDKSnNQhBl6XDYFUJ8jg1CJ6WeSjvpQSAHG9OvYsOKSf5HeTQ6zfQ8G8AgGkOZZjyIIB5u4Ceo221dTSKM6oIuN92liyWZbNVWy43Ldb/qRjJSWLioy7up8BNIzTjLlXA1nHil+ZaxPOjQJm81k9OmopwUXDHaseCXYPLJ5yb7RqlzcF7JJU3oufg8+afuc6QKODN8/9y7Pn3LA5Iixba4zOFK8mghG80gde+VkusAXMl5nnhECs4o8+sjeU/ocpd2ANkibReismVRv49e/wyYSBz88pnrDaUKpUWqrqNjWZeSbcDxoOBh9aX5fNB5RF7pE06H2JAjU0iQKYWUaZZCthn5L7S+2SusjG1MDQVB9VlHgn1dmeDrgRn/BVi/uhZXNf6wtrMbmuCo4C5TXtt3EUNHcxn2nZ20i0b6bkPFNFQ7WUQNJuC9nCqrOzK7kOlyoA5o15iMdfp1NbyB7o6nl7uHiyKJ6crgl9ioy2SkTXQWRFG/gBNHZJTAzeohC19p5wcH7rJ8uzY4v/tfMTtnOcvhwHrEnur9DUpJrjjCmWBdKIZP1sy6lo31diaZWLncX60dVieWKJuc52FD9aqaaLJfFm6YzmHMfBOVUgj66cJMMWwF/UumvvUfikjLd4TX2An1OE+Kor+dzgoed/37LkBZ
x-ms-exchange-antispam-messagedata-1: LG8dWc1YNkeXfPadX2QdAiSvwgUFQtUplKw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0P190MB1978.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e4b07ea-01ef-40f7-f902-08da37175105
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2022 08:37:30.8843 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: syBN5qfX81FokPjmSEQxwfTmfwOm8DGTI4DTW2kyklLrVX10eSPQRDfVTmCuTXJSZwQulN/3OMqrvwWexHJ0pIvLBngZ9SfcKbWqqfMJW+A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0467
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/4FyMfHBSPpfrWxmvkTePrCUt-u8>
Subject: Re: [core] CoAP resource discovery and DNS-SD
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 May 2022 08:37:44 -0000

I also think that defining a standard "conversion" from DNS-SD service to a CoRE Link Format description would be of interest.
The work of Kerry Lynn that was mentioned ended up in this draft: https://datatracker.ietf.org/doc/html/draft-ietf-core-rd-dns-sd-05

From what I heard this was complex because the aim was to have a full, bi-directional translation between the two worlds. If you only consider DNS-SD translation to CoRE Link Format the problem becomes much easier.
For the reverse, CoRE Link Format to DNS-SD translation, I recall you could end up with fairly large and complex DNS descriptions to capture all the CoRE semantics correctly. (author Peter van der Stok knows about this)

A few remarks on the proposed rt=s.* method:

1- Although our current CoRE rt registry doesn't allow prefix registration e.g. "all s.* ", it could be written in an RFC IANA Section saying "IANA, please treat all s.* as reserved for RFC NNNN" . 
   So it should be possible I think to reserve rt "s.<servicename>" for referring to existing RFC 6335 services?
 
2- To me the semantics of the example line </b>;rt=s.<service-name>;p=<num1>;w=<num2>;<key>=<value> is not fully clear.
    For example the </b> defines that the protocol is "coap" if the Link Format description was fetched using the coap:// protocol at the server.  If the <servicename> entry defines another protocol say TCP transport, or anything non-CoAP, is the entry valid then?
    Or is it intended to be only used for <servicename> entries that make use of CoAP?

 3- Note that Link Format in principle allows to link to any other protocol that has a scheme, for example:
<bitcoin://[2001:db8::1]:5678>;rt=s.bitcoin;p=1;w=2;example1=example2

could be used to link to a non-CoAP service hosted on port 5678.  Due to a link format semantics limitation, the serving host has to include the IP address in the link entry even if it is hosted on the server itself.
So I wasn't sure if the request for for only CoAP-related services or any-protocol services to be advertised over link format.

Esko

-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Saturday, May 14, 2022 19:09
To: Toerless Eckert <tte@cs.fau.de>
Cc: core@ietf.org; dnssd@ietf.org
Subject: Re: [core] CoAP resource discovery and DNS-SD

On 2022-05-14, at 16:28, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> 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.

I don’t know what’s “except” about that — RFC 6990 truly is quite flexible with request to defining target attributes.

>> 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.

We don’t really have a way to insert one registry into another, but technically, this makes a lot of sense.

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

Works for me.

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

These of course can conflict with other target attribute names.
As the namespace for target attributes is not controlled at the moment, a trick like the s.servicename above could work here, too (on the left side of the =).

> 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.

Doing this manually works, too.

> This should be all there is to it.

Right; it should not be complicated.

> 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 ?

Section 2 of RFC 6690:
"Note that commas can also
   occur in quoted strings and URIs but do not end a description.”

We used space separators or multiple instances of the attribute, i.e.

key=“val1 val2 val3” (e.g., for rt=, if=, rel=)
Or
key=val1;key=val2;key=val3 (can’t remember outright where we did this).

The fact that we didn’t encourage to always use *one* of these in RFC6690 is haunting us a bit.

Grüße, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core