Subject: [core] draft-bormann-core-links-json: call for adoption

From: Andrew Mcgregor <[email-masked]>
Date: Tue, 21 May 2013 10:27:35 +1000

Consensus of the room in Orlando was to adopt draft-bormann-core-links-json as
a working group document.  This email is a call for confirmation of that
consensus.  Please respond if you support the adoption of this document.

>From the charter:

    5) A definition of how to use CoAP to advertise about or query for a
    Device's description. This description may include the device name and
    a list of its Resources, each with a URL, an interface description URI
    (pointing e.g. to a Web Application Description Language (WADL)
    document) and an optional name or identifier. The name taxonomy used
    for this description will be consistent with other IETF work,
    e.g. draft-cheshire-dnsext-dns-sd.

This is for making the resource discovery information available to
backends.  On a technical level, this is a no-brainer.

• May 2013 Submission to IESG of "Representing CoRE Link Collections
  in JSON" for Proposed Standard

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 8143 7128

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 20 May 2013 23:50:05 -0400

+1

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Mcgregor
Sent: Monday, May 20, 2013 8:28 PM
To: [email-masked]
Subject: [core] draft-bormann-core-links-json: call for adoption

Consensus of the room in Orlando was to adopt
draft-bormann-core-links-json as a working group document.  This email
is a call for confirmation of that consensus.  Please respond if you
support the adoption of this document.

    5) A definition of how to use CoAP to advertise about or query for a
    Device's description. This description may include the device name
and
    a list of its Resources, each with a URL, an interface description
URI
    (pointing e.g. to a Web Application Description Language (WADL)
    document) and an optional name or identifier. The name taxonomy used
    for this description will be consistent with other IETF work,
    e.g. draft-cheshire-dnsext-dns-sd.

* May 2013 Submission to IESG of "Representing CoRE Link Collections
  in JSON" for Proposed Standard

--

---

From: peter van der Stok <[email-masked]>
Date: Tue, 21 May 2013 09:04:10 +0200

I don't know.
Could the contents of links-json not be combined with core-interfaces?

I can imagine that we have other documents defining the json contents 
for different management subjects

Peter van der stok

Rahman, Akbar schreef op 2013-05-21 05:50:
> +1
> 
> Akbar
> 
> FROM: [email-masked] [mailto:[email-masked]] ON BEHALF
> OF Andrew Mcgregor
> SENT: Monday, May 20, 2013 8:28 PM
> TO: [email-masked]
> SUBJECT: [core] draft-bormann-core-links-json: call for adoption
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 May 2013 10:40:49 +0200

> Could the contents of links-json not be combined with core-interfaces?

Core-Interfaces is meant as an informational document describing good approaches, while links-json actually defines a format.

> I can imagine that we have other documents defining the json contents for different management subjects

Right, but they are on quite different timelines.
Generally I'd expect all future documents defining a format to define the (or a) JSON version, if that is desired.
links-json just fills in that gap retroactively for 6690.

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Tue, 21 May 2013 10:56:01 +0200

Starts to make sense. So, you partially agree about core-interfaces 
being the base document (informationally or not).
Will other "links-exi" documents then also be based on core-interfaces?
Or do we need still another document?
I mention this need for some generally understood structure beforehand, 
because at the moment writing a document about for example "coap based 
management" takes some thinking about which documents (just from core) 
are relevant and possibly normative.

Greetings,

peter

Carsten Bormann schreef op 2013-05-21 10:40:
> Core-Interfaces is meant as an informational document describing good
> approaches, while links-json actually defines a format.
> 
> Generally I'd expect all future documents defining a format to define
> the (or a) JSON version, if that is desired.

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 22 May 2013 06:28:06 +0000

+1

Not sure if I agree with the fact that it is only suitable outside the constraint environment though; the JSON variant seems easy enough to parse. How to avoid IOP trouble due to two endpoints using the different formats?

Some things for consideration:
- Change ".well-known/core" to ".well-known/jlink" or something?
- Register new mime type?
- Does this allow multivalue attributes, e.g. through arrays? Definitely possible in JSON, but it would break easy conversion to the conventional link format.
- In JCARD, we started with a similar construction. However we later changed to a construction of {"name", "parameter", "type", "value"} to allow more flexibility and signalling, especially concerning the type (e.g. string or integer) of the value.

Bert

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: 2013年5月21日 11:50
To: Andrew Mcgregor; [email-masked]
Subject: Re: [core] draft-bormann-core-links-json: call for adoption

+1

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Mcgregor
Sent: Monday, May 20, 2013 8:28 PM
To: [email-masked]
Subject: [core] draft-bormann-core-links-json: call for adoption

Consensus of the room in Orlando was to adopt draft-bormann-core-links-json as a working group document.  This email is a call for confirmation of that consensus.  Please respond if you support the adoption of this document.

From the charter:

This is for making the resource discovery information available to backends.  On a technical level, this is a no-brainer.

--
Andrew McGregor | SRE | [email-masked]<mailto:[email-masked]> | +61 4 8143 7128

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 May 2013 09:13:21 +0200

> Not sure if I agree with the fact that it is only suitable outside the constraint environment though; the JSON variant seems easy enough to parse. How to avoid IOP trouble due to two endpoints usin…

I'd say: stick with RFC 6690 in the constrained environment...

> - Change ".well-known/core" to ".well-known/jlink" or something?

Again, I don't argue for moving over the constrained nodes to JSON links.

> - Register new mime type?

Yep:    application/link-format+json
(Section 3; the IANA boilerplate has to filled in, next).

> - Does this allow multivalue attributes, e.g. through arrays? Definitely possible in JSON, but it would break easy conversion to the conventional link format.

Yes, it does (and no, it wouldn't break link-format or RFC 5988):

   If a Link attribute ("parmname") is present more than once in a
   "link-value", its values are then represented as a JSON array of JSON
   string values; this array becomes the value of the JSON name/value
   pair where the attribute name is the JSON name. 

(Section 2).

> - In JCARD, we started with a similar construction. However we later changed to a construction of {"name", "parameter", "type", "value"} to allow more flexibility and signalling, especially concern…

I think the jcardcal format is constrained by the need to do round-tripping into the legacy format, so you want to make the type information explicit.
I'm not sure we have the same considerations here.
(Also, since link-format attributes are RFC 5988 attributes and thus always string values, we follow this by even handling "ct" as a string:

   [{"href":"/sensors","ct":"40","title":"Sensor Index"},{"href":"/
   sensors/temp","rt":"temperature-c","if":"sensor"},{"href":"/sensors/
   light","rt":"light-lux","if":"sensor"},{"href":"http://
   www.example.com/sensors/t123","anchor":"/sensors/
   temp","rel":"describedby"},{"href":"/t","anchor":"/sensors/
   temp","rel":"alternate"}]
)

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 22 May 2013 10:05:41 +0000

+1

I think this is useful for building larger "Cloud services" around constrained devices and M2M applications. I do not see a direct connection to core-interfaces, though.

In Orlando Carsten recalled the original incentive for writing up this format. Unfortunately, the minutes etherpad keeps resetting my connection attempts and I cannot recall the outcome. Anyone can? :)

Ciao
Matthias

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Mcgregor
Sent: Tuesday, May 21, 2013 2:28
To: [email-masked]
Subject: [core] draft-bormann-core-links-json: call for adoption

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 May 2013 12:37:01 +0200

> In Orlando Carsten recalled the original incentive for writing up this format. Unfortunately, the minutes etherpad keeps resetting my connection attempts and I cannot recall the outcome. Anyone can…

The minutes are at:

http://www.ietf.org/proceedings/86/minutes/minutes-86-core

Specifically:

>         draft-bormann-core-links-json [65:00, 123]
> 
> Objective:
>         - Gauge interest by WG
> 
> Carsten quickly recaps the reasons for draft-bormann-core-links-json-02.
> - Kerry: relation to current RFC4627bis work?
>   Carsten doesn't think there is a relation.  This uses JSON as is.
>   (We are assuming that there is never semantic information on the
>   sequence of link-format attributes.)
> - Zach: thinks this should be standardized, maybe not necessarily in CoRE.
> - Carsten: calls for consensus. 5 have read a version of it. 5 think
>   IETF should do it. 3 think document is a good start for this. 3
>   willing to review.
> - Matthias: not sure whether CoRE is the place to work on this in
>   IETF.

Well, maybe the audio is more useful... (http://www.ietf.org/audio/ietf86/ietf86-caribbean6-20130312-1300-pm1.mp3, if you actually look into it, start at 65:00).

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 May 2013 12:57:42 +0200

> Well, maybe the audio is more useful... (http://www.ietf.org/audio/ietf86/ietf86-caribbean6-20130312-1300-pm1.mp3, if you actually look into it, start at 65:00).

Oops, the file name in the minutes was wrong (fixed); make that ietf86-caribbean5-20130313-1300-pm1.mp3

What I said:
-- It is sad that we have different serializations for things
-- On the backend, web-app, services side, it is quite usual these days to find information in JSON format
-- It is useful to have a single [i.e., standard] way to express link-format information in JSON
-- As a side-effect, we create good precedent for application developers to represent link-format information in the same way in different applications.
   We make it simpler for application developers to think about link-format because they know how it looks like in JSON.  But that is a side effect.

Switching to the how from the why:
-- That is not rocket science -- [showing slide] this is essentially the technical content of the draft.
-- The main decision is what name are we using for the Path component of the link.
-- We settled on href because this is already taken so there can't be a conflict.
-- One little detail: Content-Format (ct) looks like a number in link-format, but looks like a string in the JSON.
   We don't have a distinction between number and string in the link-format... so we are treating everything as a string.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 22 May 2013 11:50:11 +0000

Thank you very much for digging that up!

> -- As a side-effect, we create good precedent for application developers to
> represent link-format information in the same way in different applications.
>    We make it simpler for application developers to think about link-format
> because they know how it looks like in JSON.  But that is a side effect.

Yes, that perfectly matches the experience we are currently making in a "Cloud + Internet of Things" project. There is some appeal to make this format more general, but pushing it forward within CoRE sounds good (as it is pretty simple there).

Ciao
Matthias

---

From: Zach Shelby <[email-masked]>
Date: Mon, 27 May 2013 22:32:13 +0300

I support the adoption of this draft.

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