Subject: [core] Concerning the format in the profile draft

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 4 Jun 2013 00:48:48 +0000

Hello all,

We, the authors of the profile description draft, would like to ask feedback on the draft from the WG as follows.

  http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile-description/

To recap: the draft provides a new resource ".well-known/profile", which gives a profile description of the resource. Currently this description includes supported options, content type and block size. We would like to add supported methods (GET/PUT/POST/DELETE) too. The profile information is especially useful for automated discovery and handling of constrained resources. A general proxy/gateway would be an example that benefits from this.

Especially the following question (as suggested in Orlando) requires attention:

  Continue using a separate JSON based ".well-known/profile" or merge with the ".well-known/core" link format?

We discussed these options internally. During that discussion, we identified several arguments in favour of either option. Please find below a list of arguments we found:

In favour of JSON ".well-known/profile":
- Allow hierarchical structure through nested JSON fields;
- Allow usage of field types, such as integer, float and string;
- Keep link format lean and simple;
- Server can treat the ".well-known/profile" file as opaque data; it does not need to handle or implement JSON.

In favour of integration with ".well-known/core" link format:
- No need to add JSON parser to client for this functionality;
- Coding in link format is more compact than in JSON;
- Link format is slightly simpler to parse.

We were also thinking of some kind of hybrid solution, where we add an attribute to ".well-known/core" that indicates if ".well-known/profile" is supported. The latter will then provide the more detailed profile information.

What are your thoughts? We would be happy to receive your feedback and considerations!

Best regards,
Bert

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 5 Jun 2013 13:31:06 +0000

Dear Bert

My main concern about the profile draft is its overlap with /.well-known/core. I think your profile should concentrate on the endpoint in general instead of individual resources. From my practical experience, information about supported options and buffer sizes is independent from the resources anyway.

Currently, there is no way to learn about the application profile (e.g., OMA Lightweight) an endpoint implements. Currently, a client has to guess this from the resource structure or requires some out-of-band knowledge. There are other bindings coming up, e.g., BACnet, so it would be good to provide this information in such an endpoint profile.

Ciao
Matthias

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bert Greevenbosch
> Sent: Dienstag, 4. Juni 2013 02:49
> To: [email-masked]
> Subject: [core] Concerning the format in the profile draft
> 
> Hello all,
> 
> To recap: the draft provides a new resource ".well-known/profile", which
> gives a profile description of the resource. Currently this description includes
> supported options, content type and block size. We would like to add
> supported methods (GET/PUT/POST/DELETE) too. The profile information is
> especially useful for automated discovery and handling of constrained
> resources. A general proxy/gateway would be an example that benefits from
> this.
> 
> We discussed these options internally. During that discussion, we identified
> several arguments in favour of either option. Please find below a list of
> arguments we found:
> 
> We were also thinking of some kind of hybrid solution, where we add an
> attribute to ".well-known/core" that indicates if ".well-known/profile" is
> supported. The latter will then provide the more detailed profile information.
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 6 Jun 2013 11:18:44 +0000

> ...profile should concentrate on the endpoint in general instead of individual resources...

Agree!

I'm wondering when such a profile is needed, i.e. in what use cases would a client have to fetch an explicit profile of an endpoint? (versus the standard CoAp approach of just trial-and-error to see if an option is supported, or not. Or versus the out-of-band approach where knowledge of a spec combined with Link Format resource types gives enough information on supported options.)

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: Wednesday, June 05, 2013 15:31
To: Bert Greevenbosch; [email-masked]
Subject: Re: [core] Concerning the format in the profile draft

Dear Bert

Ciao
Matthias

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bert Greevenbosch
> We, the authors of the profile description draft, would like to ask
> feedback on the draft from the WG as follows.
>
> To recap: the draft provides a new resource ".well-known/profile",
> which gives a profile description of the resource. Currently this
> description includes supported options, content type and block size.
> We would like to add supported methods (GET/PUT/POST/DELETE) too. The
> profile information is especially useful for automated discovery and
> handling of constrained resources. A general proxy/gateway would be an
> example that benefits from this.
>
> We discussed these options internally. During that discussion, we
> identified several arguments in favour of either option. Please find
> below a list of arguments we found:
>
> - Server can treat the ".well-known/profile" file as opaque data; it
> does not need to handle or implement JSON.
>
> attribute to ".well-known/core" that indicates if
> ".well-known/profile" is supported. The latter will then provide the more detailed profile information.
>

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Rick Bullotta <[email-masked]>
Date: Thu, 6 Jun 2013 11:51:08 +0000

If I understand the situation correctly, the ability to access a device's profile in this way is extremely useful in situations when a development environment/platform (e.g. our ThingWorx platform) wants to access the metadata for a device even when the device itself is offline.  It provides a durable catalog for this metadata information, enabling development activities to occur independent of connection status.  Additionally, with some further design work, this resource repository can become an excellent mechanism for accessing and managing the definition(s) of "generic profiles" (e.g. an energy meter, a traffic light, a refrigerated shipping container) and their association to specific devices.

Apologies if I misunderstood - new to the discussions!

Cheers,

Rick Bullotta
ThingWorx

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Thursday, June 06, 2013 7:19 AM
To: Kovatsch Matthias; Bert Greevenbosch; [email-masked]
Subject: Re: [core] Concerning the format in the profile draft

Agree!

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: Wednesday, June 05, 2013 15:31
To: Bert Greevenbosch; [email-masked]
Subject: Re: [core] Concerning the format in the profile draft

Dear Bert

Ciao
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 6 Jun 2013 13:27:45 +0000

> I'm wondering when such a profile is needed, i.e. in what use cases would a
> client have to fetch an explicit profile of an endpoint? (versus the standard
> CoAp approach of just trial-and-error to see if an option is supported, or not.
> Or versus the out-of-band approach where knowledge of a spec combined
> with Link Format resource types gives enough information on supported
> options.)

You will not need it in closed deployments without heterogeneity (just like what we had before).
I becomes interesting, in my opinion, when you build ad hoc applications like Web mashups. There the profile might be unknown a priori, but needed for successful interaction (e.g., deciphering the OMA Object IDs).

Ciao
Matthias

---

From: Zach Shelby <[email-masked]>
Date: Thu, 6 Jun 2013 18:18:23 +0200

> My main concern about the profile draft is its overlap with /.well-known/core. I think your profile should concentrate on the endpoint in general instead of individual resources. From my practical…

I tend to agree, information about an endpoint's CoAP implementation capabilities is separate from the list of resources it has available. 

> Currently, there is no way to learn about the application profile (e.g., OMA Lightweight) an endpoint implements. Currently, a client has to guess this from the resource structure or requires some…

Why would this be mixed with information about the CoAP implementation? We already have a means for indicating what semantics a resource has using the Resource Type link attribute. In the case of OMA Lightweight, the specification actually specifies the Resource Type "oma.lwm2m" which indicates the root resource of the Object tree:

</oma>;rt=oma.lwm2m,</oma/2/0>,</oma/3/0>

The first link is the root of the OMA tree, and the second and third links are Object Instances. 

Similarly, if other REST interfaces were hosted on that endpoint, they should probably indicate themselves with a Resource Type. So I think we have this covered with our existing mechanisms.

Zach 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Zach Shelby <[email-masked]>
Date: Thu, 6 Jun 2013 18:25:34 +0200

Hi Rick,

On Jun 6, 2013, at 1:51 PM, Rick Bullotta <[email-masked]> wrote:

> If I understand the situation correctly, the ability to access a device's profile in this way is extremely useful in situations when a development environment/platform (e.g. our ThingWorx platform) wants to access the metadata for a device even when the device itself is offline.  It provides a durable catalog for this metadata information, enabling development activities to occur independent of connection status.  

No, the draft that Bert et al. were discussing here is about discovering the CoAP protocol capabilities that an endpoint supports using a special URI that can be requested. For example does an endpoint support a special CoAP option. "Profile" is probably a really poor term to describe that (confuses me at least). 

We do have a mechanism already to do what you describe. That is the CoRE Link Format (RFC6690) format that we use to describe the resources and their meta-data that an endpoint has available. By default these links can be discovered from any endpoint by doing a GET request to /.well-known/core. We also have a mechanism to post these links to a central Resource Directory where they are available even when the endpoint is off-line:

http://tools.ietf.org/html/draft-ietf-core-resource-directory

> Additionally, with some further design work, this resource repository can become an excellent mechanism for accessing and managing the definition(s) of "generic profiles" (e.g. an energy meter, a traffic light, a refrigerated shipping container) and their association to specific devices.

Exactly! The new OMA Lightweight standard defines a complete Object model and provides an Object registry, so when you see such a link, you know exactly what the resource is about (Light Control Object, Location Object, Device Object etc.). 

Regards,
Zach

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 6 Jun 2013 23:55:22 +0000

> Why would this be mixed with information about the CoAP implementation? We
> already have a means for indicating what semantics a resource has using the
> Resource Type link attribute. In the case of OMA Lightweight, the specification
> actually specifies the Resource Type "oma.lwm2m" which indicates the root
> resource of the Object tree:
> 

Ah, okay. A while ago, OMA Objects were at the root, I think. This looks good now.

> Similarly, if other REST interfaces were hosted on that endpoint, they should
> probably indicate themselves with a Resource Type. So I think we have this
> covered with our existing mechanisms.

So the remaining information for /.well-known/profile would be Options and sizes. Nonetheless, this is covered by the corresponding error messages and block size negotiation...

Ciao
Matthias

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 7 Jun 2013 08:46:04 +0000

Hi Matthias,

Indeed the overlap with ".well-known/core" is an issue. This is why we are considering merging it. I think that we should avoid sending double information, i.e. avoid putting information from ".well-known/core" into ".well-known/profile". An issue with that would be that a client/proxy that wants to remember all info needs to aggregate information from the two resources though.

As for the granularity resources/endpoints, I understand your concern. Indeed I believe that most of the time an endpoint uses the same options/block sizes for all of its resources. However, there may be exceptions. For example, when the endpoint is a physical device wired to some other devices, those other devices may have different capabilities. That may lead to support or not for block / observe, different blocksizes, etc.

If all resources on the endpoint share the same profile information, then in ".well-known/profile" all can be signalled using the default <.> resource.

Best regards,
Bert

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]] 
Sent: 2013年6月5日 21:31
To: Bert Greevenbosch; [email-masked]
Subject: RE: Concerning the format in the profile draft

Dear Bert

Ciao
Matthias

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 7 Jun 2013 09:01:57 +0000

Hi Esko,

> I'm wondering when such a profile is needed, i.e. in what use cases would a client have to fetch an explicit profile of an endpoint? (versus the standard CoAp approach of just trial-and-error to se…

Thank you for your feedback.

I wouldn't like to be dependent on trial-and-error in all cases. For example, when using block, it is useful to know the max. blocksize in advance. Otherwise the client would first need to receive a 4.13 "Entity to large" error, then diagnose that it needs to include a block option or use a smaller block size (at this point, does the client know the server supports block at all?), and try again. More detailed knowledge about the server's capability would reduce wasting messages, and would reduce the number of possibile diagnoses when an error has been received too.

With an expectation that more and more options will be defined (after all, we reserved quite a large option number space), it will become harder and harder to find the optimal settings just by trying. As indicated in the example above, the limited number of possible errors would also complicate the diagnostic process when more options become specified.

Best regards,
Bert

-----Original Message-----
From: Dijk, Esko [mailto:[email-masked]] 
Sent: 2013年6月6日 19:19
To: Kovatsch Matthias; Bert Greevenbosch; [email-masked]
Subject: RE: Concerning the format in the profile draft

Agree!

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: Wednesday, June 05, 2013 15:31
To: Bert Greevenbosch; [email-masked]
Subject: Re: [core] Concerning the format in the profile draft

Dear Bert

Ciao
Matthias

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 7 Jun 2013 09:04:17 +0000

Hi Matthias,

Indeed mash-ups and aggregating proxies are some of the entities that can benefit from this.

Although closed deployments are certainly important, the Internet of Things is also supposed to provide for open architectures. After all, this is where standardisation benefits us most. So I agree that the profile draft is most useful for deployments where entities need to get to know each other before they can perform optimal communication.

Best regards,
Bert

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]] 
Sent: 2013年6月6日 21:28
To: Dijk, Esko; Bert Greevenbosch; [email-masked]
Subject: RE: Concerning the format in the profile draft

Ciao
Matthias

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 7 Jun 2013 09:05:37 +0000

Hi Matthias and Zach,

I agree that the resource type does convey interesting information about the resource. I thought it was more related to the format of messages in the payload, than to the CoAP protocol itself though. 

Does the resource type specify all the CoAP capabilities of the resource? In other words, when a resource type is defined, is all associated profile info defined with it? That would mean that a resource type defines a fixed set of options and a fixed block size. How to deviate from this, and how to signal that?

Best regards,
Bert

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]] 
Sent: 2013年6月7日 7:55
To: Zach Shelby
Cc: Bert Greevenbosch; [email-masked]
Subject: AW: [core] Concerning the format in the profile draft

Ciao
Matthias

---

From: Bert Greevenbosch <[email-masked]>
Date: Sat, 8 Jun 2013 00:59:59 +0000

Hi Zach and Rick,

Indeed the profile draft currently just signals supported CoAP options, content format and blocksize. We are strongly considering removing the content format because it is already signalled in the link format. We would like to add supported methods GET/PUT/POST/DELETE.

I use the term "profile description" because it signals the subset of all what CoAP capabilities the entity supports. But I don't think the naming is critical. We could also call it "CoAP capabilities description" or something.

The profile draft is in the process of development, so we can certainly add more information as required.

As Zach mentions, the link format and resource directory already give some information about the resources. But in my view, this information currently is too limited. However, it is a reason that I wrote below the discussion points about whether or not to merge ".well-known/core" and ".well-known/profile". What do you think about this?

I think the profile information is useful in several deployments. Entities that benefit from it are e.g. general proxies/gateways that talk to multiple endpoints, clients that can find out about whether or not proxy-unsafe options are supported by the proxy, or which capabilities of a server they can exploit, and servers receiving less messages that they cannot handle. Finally, the information can be used for debugging/diagnostic purposes.

Thanks a lot for your feedback and considerations! What is your opinion?

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: 2013年6月7日 0:26
To: Rick Bullotta
Cc: [email-masked] WG
Subject: Re: [core] Concerning the format in the profile draft

Hi Rick,

Regards,
Zach

---

From: Jeroen Hoebeke <[email-masked]>
Date: Sun, 9 Jun 2013 21:28:04 +0200

> Indeed the profile draft currently just signals supported CoAP options, content format and blocksize. We are strongly considering removing the content format because it is already signalled in the…

At this moment the draft indeed only signals supported CoAP options. However, more information than supported CoAP options could be conveyed such as CoAP protocol parameters used by the server. The ability to retrieve this information via a well-defined mechanism is less cumbersome than having to use trial-and-error at all times. An out-of-band approach is suitable for retrieving whether an endpoint implements e.g. a Light object model, but will not tell everything about the options supported by the endpoint or the individual resources. A profile as proposed in the draft can help.

Regarding the discussion whether the profile should only express information about the endpoint and not about the individual resources:

Even when the endpoint supports a CoAP option, this does not imply that the option can be applied to a specific resource hosted by that endpoint (e.g. observe option). Of course, indicating that an option is supported by a resource can be done by adding an attribute to /.well-known/core. However, anticipating that more and more options will appear, it may become inconvenient to embed everything in /.well-known/core and inflating the size of this resource. Any thoughts about that? 

Finally, the profile concept could be used to provide other resource specific information that cannot be retrieved easily out-of-band. A quick example based on the core-interfaces draft: for a linked batch resource, the resource profile could list the current resources that are part of the linked batch or a resource profile could list the supported resource observation attributes. 

Kind regards,
Jeroen