[core] resource-directory-12: Request for reviews, annotated Change Log
Christian Amsüss <c.amsuess@energyharvesting.at> Tue, 31 October 2017 09:32 UTC
Return-Path: <c.amsuess@energyharvesting.at>
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 A3A4613F6FB; Tue, 31 Oct 2017 02:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55a64X3HCi_3; Tue, 31 Oct 2017 02:32:50 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ED01395F0; Tue, 31 Oct 2017 02:32:49 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7C7D54830E; Tue, 31 Oct 2017 10:32:45 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 80A462A; Tue, 31 Oct 2017 10:32:41 +0100 (CET)
Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6286657; Tue, 31 Oct 2017 10:32:41 +0100 (CET)
Received: (nullmailer pid 12829 invoked by uid 1000); Tue, 31 Oct 2017 09:32:40 -0000
Date: Tue, 31 Oct 2017 10:32:40 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: core@ietf.org
Cc: draft-ietf-core-resource-directory@ietf.org
Message-ID: <20171031093240.wfwdhs7dwkfofheh@hephaistos.amsuess.com>
References: <150938830831.7809.14214960601515419982@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="7rqtqwgn2fqpj2c3"
Content-Disposition: inline
In-Reply-To: <150938830831.7809.14214960601515419982@ietfa.amsl.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/7iTDNIm4f-x7JUzv_Jxp0SkcED4>
Subject: [core] resource-directory-12: Request for reviews, annotated Change Log
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 31 Oct 2017 09:32:58 -0000
Hello CoRE working group, On Mon, Oct 30, 2017 at 11:31:48AM -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Constrained RESTful Environments WG of the IETF. With the document nearing completion, the authors would like to ask the working group for reviews on the submitted draft. Even though the document contains a change log, some changes were big enough to deserve some more explanation, so we'd like to provide the WG with some further notes and examples with the changelog entries: ---- o clarified where relative references are resolved, and how context and anchor interact o new appendix on the interaction with RFCs 6690, 5988 and 3986 In particular, we now preserve the full resolved statements from Link Format documents submitted to the RD, including the context and link relations. This means that at resource lookup, clients need to be able to understand the anchor= attribute. Key example: | Req: GET /rd-lookup/res?rt=temperature | | Res: 2.05 Content | </sensors/temp>;rt="temperature";if="sensor";anchor="coap://[2001:db8::123]" Example of a more complex original statement: | Req: GET /rd-lookup/res?rel=describedby | | Res: 2.05 Content | <http://example.com/temp-info.html>;rel="describedby";anchor="coap://[2001:db8::123]/sensors/temp" ---- o lookup interface: group and endpoint lookup return group and registration resources as link targets This removes the need for a dedicated "list all groups/endpoints" interface on the registration side. Key example: | Req: GET /rd-lookup/ep?et=power-node | | Res: 2.05 Content | </rd/1234>;con="coap://[2001:db8::127]";ep="node5";et="power-node";ct="40";lt="600", | </rd/4521>;con="coap://[2001:db8::129]";ep="node7";et="power-node";ct="40";lt="600";d="floor-3" Note that as with all URIs in the RD, none of the concrete paths is prescribed. Were a different implementation used, the same example could be: | Req: GET /~resdir/ep-lookup?et=power-node | | Res: 2.05 Content | </~resdir/+reg/node5>;con="coap://[2001:db8::127]";ep="node5";et="power-node";lt="600", | </~resdir/+reg/floor-3/node7>;con="coap://[2001:db8::129]";ep="node7";et="power-node";lt="600";d="floor-3" This also allows an unambiguous syntax for putting registered endpoints into groups: | Req: POST /rd-group?gp=lights&con=coap://[ff35:30:2001:db8::1] | Payload: | </rd/1234>,</rd/4521> | | Res: 2.01 Created | Location: /rd-group/12 ---- o updated chapter "Finding a Resource Directory"; now distinguishes configuration-provided, network-provided and heuristic sources Endpoints can be pre-configured to use a particular way to find their RD, be it per IP uni-, multi- or anycast, DNS name or DNS-SD service. Endpoints without explicit configuration look for an RD location that comes with the network (eg. from SLAAC); in absence thereof, heuristics for finding an RD are described (multicast discovery, ask the 6LBR). ---- Further changes: o added Content Model section, including ER diagram o removed domain lookup interface; domains are now plain attributes of groups and endpoints o improved text on: atomicity, idempotency, lookup with multiple parameters, endpoint removal, simple registration o updated LWM2M description o lookup interface: search parameters work the same across all entities o removed all methods that modify links in an existing registration (POST with payload, PATCH and iPATCH) o removed plurality definition (was only needed for link modification) o enhanced IANA registry text o state that lookup resources can be observable o More examples and improved text Best regards Christian -- Christian Amsüss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614
- [core] I-D Action: draft-ietf-core-resource-direc… internet-drafts
- [core] resource-directory-12: Request for reviews… Christian Amsüss