Subject: [core] I-D Action: draft-ietf-core-interfaces-03.txt

From: [email-masked]
Date: Mon, 06 Jul 2015 07:47:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.

        Title           : CoRE Interfaces
        Authors         : Zach Shelby
                          Matthieu Vial
                          Michael Koster
	Filename        : draft-ietf-core-interfaces-03.txt
	Pages           : 27
	Date            : 2015-07-06

Abstract:
   This document defines well-known REST interface descriptions for
   Batch, Sensor, Parameter and Actuator types for use in contrained web
   servers using the CoRE Link Format.  A short reference is provided
   for each type that can be efficiently included in the interface
   description attribute of the CoRE Link Format.  These descriptions
   are intended to be for general use in resource designs or for
   inclusion in more specific interface profiles.  In addition, this
   document defines the concepts of Function Set and Binding.  The
   former is the basis element to create RESTful profiles and the latter
   helps the configuration of links between resources located on one or
   more endpoints.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-interfaces-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 6 Jul 2015 17:17:37 +0200

Hello core-interfaces authors,

I've previously expressed my concern for the consistency of the name
resolution in core-interfaces (querying /s gives "n":"light" which
should be /s/light, but querying /s/humidity gives "n":"humidity" which
should be /s/humidity), and they still apply to the latest draft.

Do my suggestions in [1] catch the idea of the draft correctly, let me
know and I'll shape them into patches.

Best regards
Christian Amsüss

[1] https://www.ietf.org/mail-archive/web/core/current/msg05787.html

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 8 Jul 2015 11:28:05 +0200

Hello Matthieu,

On Tue, Jul 07, 2015 at 11:40:52AM +0200, Matthieu Vial wrote:
> > [...] querying /s gives "n":"light" which
> > should be /s/humidity [...]
>
> Querying /s gives senml with "n" being a URI relative to the queried URI /s
> so just "light".

But that's right to the point: A relative URI `light` based on a URI
`coap://my-host/s` evaluates to `coap://my-host/light` by the usual
rules of RFC3986 section 5.2. (And the context of the example makes it
clear that the intended resource is `coap://my-host/s/light`).

My proposed fix to -core-interfaces is to rename the batch from
`coap://my-host/s` to `coap://my-host/s/`, then things work out.

> Since we don't want to support .. path navigation querying /l gives senml
> with absolute path to reference /s/light.

Nothing wrong about that; the values of "n" (or more precisely: the
complete representable URI) are already restricted to escape friendly
characters in draft-jennings-core-senml-01 section 4 ("The resulting
concatenated name MUST consist [...]"), so restricting it to only use
"downward" relative URIs does not seem too far fetched if so desired.

I've only listed the `/l` example because it shows that the intention of
the mentioned "concatenation" or "appending" is actually RFC3986
relative URL chaining; it's the `/s` / `humidity` example that produce a
wrong URIs, and the `/s/humidity` / `humidity` example that is not
technially wrong but overly verbose.

But there is agreement that relative URL concatenation should be
happening between "bn" and "n", right?

Best regards
Christian