Subject: [media-types] Notice for a potential media type registration: application/td+json

From: Matthias Kovatsch <[email-masked]>
Date: Fri, 3 May 2019 09:51:25 +0000

Dear IANA

The Web of Things WG at W3C is getting ready to transition to Candidate Recommendation for the WoT Thing Description specification: https://w3c.github.io/wot-thing-description

Section 10 (https://w3c.github.io/wot-thing-description/#iana-section) intents to register "application/td+json" as well as a CoAP Content-Format ID (256-9999 range with IETF Review or IESG Approval).

Could you please provide a Preliminary Community Review based on the Registration Template, also attached below for convenience?

Thank you and best wishes,
Matthias

----------------------

Type name:    application

Subtype name:    td+json

Required parameters:    None

Optional parameters:    None

Encoding considerations:    See RFC 6839, section 3.1.

Security considerations:
    See RFC 8259.
    Since WoT Thing Description is intended to be a pure data exchange format for Thing metadata, the serialization SHOULD NOT be passed through a code execution mechanism such as JavaScript's eval() function to be parsed. An (invalid) document may contain code that, when executed, could lead to unexpected side effects compromising the security of a system.
    WoT Thing Descriptions can be evaluated with a JSON-LD 1.1 processor, which typically follows links to remote contexts (i.e., TD context extensions, see § 6.3 Context Extension) automatically, resulting in the transfer of files without the explicit request of the Consumer for each one. If remote contexts are served by third parties, it may allow them to gather usage patterns or similar information leading to privacy concerns. While implementations on resource-constrained devices are expected to perform raw JSON processing (as opposed to JSON-LD processing), implementations in general SHOULD statically cache vetted versions of their supported context extensions and not to follow links to remote contexts. Supported context extensions can be managed through a secure software update mechanism instead.
    Context Extensions (see § 6.3 Context Extension) that are loaded from the Web over non-secure connections, such as HTTP, run the risk of being altered by an attacker such that they may modify the TD Information Model in a way that could compromise security. For this reason, Consumer again SHOULD vet and cache remote contexts before allowing the system to use it.
    Given that JSON-LD processing usually includes the substitution of long IRIs with short terms, WoT Thing Descriptions may expand considerably when processed using a JSON-LD 1.1 processor and, in the worst case, the resulting data might consume all of the recipient's resources. Consumers SHOULD treat any TD metadata with due skepticism.

Interoperability considerations:
    See RFC 8259.
    Rules for processing both conforming and non-conforming content are defined in this specification.

Published specification:    https://w3c.github.io/wot-thing-description

Applications that use this media type:
    All participating entities in the W3C Web of Things, that is, Things, Consumers, and Intermediaries as defined in the Web of Things (WoT) Architecture.

Fragment identifier considerations:    See RFC 6839, section 3.1

Additional information:

    Magic number(s):        Not Applicable
    File extension(s):        .jsontd
    Macintosh file type code(s):        TEXT

Person & email address to contact for further information:
    Matthias Kovatsch <[email-masked]>

Intended usage:    COMMON

Restrictions on usage:    None

Author(s):
    The WoT Thing Description specification is a product of the Web of Things Working Group.

Change controller:    W3C

Provisional registration? (standards tree only):    No

---

From: Matthias Kovatsch <[email-masked]>
Date: Fri, 3 May 2019 09:36:35 +0000

Dear IANA

----------------------

Type name:    application

Subtype name:    td+json

Security considerations:
    See RFC 8259.

Additional information:

Intended usage:    COMMON

Author(s):

Change controller:    W3C

---

From: Mark Baker <[email-masked]>
Date: Fri, 3 May 2019 10:26:57 -0400

Hi Matthias. Can you explain why application/ld+json, the JSON-LD
media type, was insufficient for your needs? Thanks.

---

From: Matthias Kovatsch <[email-masked]>
Date: Fri, 3 May 2019 15:10:08 +0000

Dear Mark

> Can you explain why application/ld+json, the JSON-LD media type,
> was insufficient for your needs? Thanks.

The main reason is avoiding an entry barrier for IoT devices and developers. While WoT Thing Description (TD) has a syntax compatible with JSON-LD (1.1) to enable "semantic processing," we already got strong comments during the WG charter period that we should not have a dependency on RDF. Thus, we put quite some effort that TDs are also processable with a "raw JSON approach," meaning no knowledge of JSON-LD is necessary. Furthermore, this helps in resource-constrained environments that cannot afford JSON-LD processing, which is common in IoT (we have experience with running code here).

There are also technical reasons such as using Web Linking to express different relations between Things. The "type" target attribute should identify it as a Thing, however, it can only take a media type, i.e., no parameters such as the profile. We also investigated a CBOR representation of TD. In the future, we might want to register "application/td+cbor" for a CBOR representation based on the same TD Information Model.

I hope this explains our choice.

Best wishes,
Matthias