Subject: [core] CoRE Interfaces draft roadmap

From: Michael Koster <[email-masked]>
Date: Tue, 29 Mar 2016 07:44:12 -0700

Hi,

I would like to summarize the current state of the CoRE Interfaces draft and start discussion on coming up with a roadmap for this draft.

The bulk of the CoRE Interfaces draft describes a set reusable interface types, which are meant to be used a a hypermedia control to define resource structure and behavior, independently of the media types a resource may expose.

Many of the defined interfaces are collection types, and there is a general description of collections and details on how the different specified collection types work.

The draft also defines the concept of link binding, which is a way to create a hyperlink from one resource to another for automatically communicating asynchronous state updates. 

The defines a set of resource observation and notification controls (pmin, pmax, lt, gt, and st) that enable an observince client or binding to specify filter conditions for asynchronous notification using observe or link bindings.

Additionally, the draft defines the consept of a RETS API function set, and proposes a function set definition style using URI templates and WADL.

This draft is being reorganized to clearly separate three main areas, 1. interface definitions and collections, 2. Observation and notification including link bindings, and 3. Function set definition.

It has been proposed to separate the 3 main areas into separate drafts.

Observe, notifications, and binding:
OMA LWM2M normatively uses the notification attributes, and we have taken a lot of effort to align this section with LWM2M, also making a CR to LWM2M in the process. There is some ongoing development around link bindings and extending the obeserve attributes with another use case that requires 3 new optional attributes.

Interfaces and collections:
OCF (used to be OIC) borrows heavily from this draft. Their resource model is based on interface types and uses the terminology from this draft. Their implementation is considerably different, and is still in the process of being developed. We could work with the OCF and converge the interface and collection definition to include OCF collection types, and influence the OCF collection types to be aligned with the eventual RFC.

Function sets:
This concept was reused to some extent in Resource Directory and CoAP Pubsub drafts to specify how functions like registration, publish, subscribe, etc are mapped to a REST API. There seems to be confusion about whether this is some formal methodology and how useful it is. Do we want to propagate another conceptiual abstraction around REST APIs, particularly as this is not well aligned with the T2TRG work on REST APIs.

I think it might be a good idea to do the following:

1. Focus the interfaces draft exclusively on interfaces and collections, and make it clear that this is not the IETF officialy endorsed way to use REST. Build compatibility with OCF collections to the most reasonable extent, otherwise, try to fnid best practice guidance. 

2. Create a separate draft to describe observe attributes and notification control. Get OMA to refer to this draft for their notification attributes. Keep it simple and focused.

3. Tone down the formality of function set definition and remove the perception that CoRE Interfaces defines REST function sets. Instead, find some descriptive language that accomplishes the same thing in RD, Pubsub, Interfaces, and other drafts that want to define REST API profiles for mapping functions.

Best regards,

MIchael