Re: [core] 🔔 WGLC on draft-ietf-core-coap-senml

[Peter Saint-Andre - Filament <[e-mail]>]

On 7/20/17 4:36 PM, Ari Keränen wrote:
> 
>> On 19 Jul 2017, at 16.31, Peter Saint-Andre - Filament
>> <[e-mail]> wrote:
>> 
>> On 7/19/17 6:45 AM, Ari Keränen wrote:

<snip/>

> OK. The urn:dev is now progressing in CoRE so I guess we can do the
> allocation for that and move forward with it.

Excellent!

>>>>>> Please note that this set is more restricted than the range
>>>>>> of characters allowed for URIs in general (RFC 3986) or
>>>>>> URNs in particular (RFC 8141). At the least it would be
>>>>>> helpful to point this out, because AFAICS it will limit the
>>>>>> URI schemes or URN namespaces that can be used.
>>>>> 
>>>>> Good point. I'd suggest text:
>>>>> 
>>>>> "Note that the character set for SenML names is a subset of
>>>>> the characters allowed in URIs. The restricted set was chosen
>>>>> to enable efficient and safe use of names in various systems
>>>>> (e.g., as database keys)."
>>>> 
>>>> I suggest that we also say something like "The restrictions
>>>> imply that care needs to be taken in the choice of URIs or URNs
>>>> as SenML names." Furthermore, if someone wants to use a URI
>>>> scheme that allows characters outside that set (e.g., the 'tag'
>>>> scheme), then do those characters need to be encoded somehow?
>>>> (Ick.) If not, then we should say so.
>>> 
>>> One should not try to put "full URIs" into the names. Rather the
>>> names can be used as part of a URI.
>> 
>> I'm confused. What I see in the draft right now is that names
>> (whether "Name" or "Base Name + Name" = concatenated name) are
>> URIs, with URIs from the URN scheme used as examples. Is that a
>> misunderstanding on my part?
> 
> URIs that conform to the restricted character set ("A" to "Z", "a" to
> "z", "0" to "9", "-", ":", ".", "/", "_"), such as urn:dev, are OK.
> For example URL with brackets would not be OK (see section 5.1.6 for
> example with IPv6 address).

So I'll repeat my concern: How do we handle such URLs? Are they forbidden?

If they are not forbidden, do characters like brackets get escaped
somehow? (I hope we don't go down that road.)

If they are forbidden, then most URI schemes and URN namespaces won't be
usable. For example, URIs schemes such as 'tag' (RFC 4151) and 'ni' (RFC
6920) don't conform to the restricted character set, and there are
characters allowed in URN syntax (e.g., '@', '%', '?', '[', ']', '#',
'~', '+', '=', '&') that don't conform either. Thus it might even be
misleading to say that names are URIs because so few URI schemes or URN
namespaces can be employed here. We might need to say something like this...

OLD

   The Name value is concatenated to the Base Name value to get the name
   of the sensor.  The resulting name needs to uniquely identify and
   differentiate the sensor from all others.  It is RECOMMENDED that the
   full names are represented as URIs [RFC3986] or URNs [RFC2141].  One
   way to create a unique name is to include some bit string that has
   guaranteed uniqueness (such as a 1-wire address) that is assigned to
   the device.  Some of the examples in this draft use the device URN
   type as specified in [I-D.arkko-core-dev-urn].  UUIDs [RFC4122] are
   another way to generate a unique name.  Note that long-term stable
   unique identifiers are problematic for privacy reasons and should be
   used with care or avoided as described in [RFC7721].

   The resulting concatenated name MUST consist only of characters out
   of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or
   "_" and it MUST start with a character out of the set "A" to "Z", "a"
   to "z", or "0" to "9".  This restricted character set was chosen so
   that these names can be directly used as in other types of URI
   including segments of an HTTP path with no special encoding and can
   be directly used in many databases and analytic systems.  [RFC5952]
   contains advice on encoding an IPv6 address in a name.

NEW

   The Name value is concatenated to the Base Name value to yield the
   name of the sensor.  The resulting concatenated name needs to
   uniquely identify and differentiate the sensor from all others.
   The concatenated name MUST consist only of characters out of the set
   "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", and "_";
   furthermore, it MUST start with a character out of the set "A" to
   "Z", "a" to "z", or "0" to "9".  This restricted character set was
   chosen so that concatenated names can be used directly within
   various URI schemes (including segments of an HTTP path with no
   special encoding) and can be used directly in many databases and
   analytic systems.  [RFC5952] contains advice on encoding an IPv6
   address in a name.

   Although it is RECOMMENDED that concatenated names are represented
   as URIs [RFC3986] or URNs [RFC8141], the restricted character set
   specified above puts strict limits on the URI schemes and URN
   namespaces that can be used.  As a result, implementers need to take
   care in choosing the naming scheme for concatenated names, because
   such names both need to be unique and need to conform to the
   restricted character set.  One approach is to include a bit
   string that has guaranteed uniqueness (such as a 1-wire address).
   Another, shown in some of the examples within this document, is to
   use the device URN namespace as specified in
   [I-D.arkko-core-dev-urn].  A third approach is to use UUIDs
   [RFC4122].  Unfortunately, the restricted character set does not
   allow the use of some URI schemes that might otherwise be
   attractive, such as the 'tag' scheme [RFC4151] and the 'ni' scheme
   [RFC6920].  Note also that long-term, stable, unique identifiers are
   problematic for privacy reasons and should be used with care or
   avoided entirely as described in [RFC7721].

>>> Perhaps something we should be more clear about.
>> 
>> Yes, clarity would be good.
> 
> Will add clarification about the URIs.

See above for proposed text.

>>> Now: https://github.com/core-wg/senml-spec/issues/73
>>> 
>>>>>> Section 4.6
>>>>>> 
>>>>>> Up to this point in the document, SenML has been defined as
>>>>>> a format for representing sensor measurements. Given that a
>>>>>> sensor measures something in the world, what does it mean
>>>>>> to *set* the value of a sensor or a sensor measurement?
>>>>> 
>>>>> I guess this needs to be elaborated also in the intro (it's
>>>>> hinted in the abstract).
>>>> 
>>>> That's the barest of hints. :-) I almost provided a comment
>>>> about it, but let it go.
>>> 
>>> Admittedly :) Do you have any proposal how to make it better?
>> 
>> One option is to remove the configuration and actuation use cases.
>> They seem to be an afterthought. Perhaps define them more carefully
>> in a separate I-D that re-uses SenML, thus not holding up the core
>> SenML work any further.
>> 
>> If people really want to support these use cases now and in the
>> core spec, then I can suggest improvements to the text.
> 
> There is already use for these so I think we should include the
> functionality in the base spec.

OK, I will take a closer look at the text and propose some improvements.

Peter