Content Type for Thing Model (IANA registration needed)

[sebastiankb]

In today's TD call we were thinking about own content type for TDT. That would help to distinguish between TD and TDT when both are exchanged or requested.

[egekorkan]

This is a rather important issue since all the TD based on TM examples are using the TD content type which is simply wrong

[sebastiankb]

I will check with IANA and ask for the registration steps.

[sebastiankb]

A first draft for IANA (simple c&p from TD and replace TD with TM):

application/tm+json Media Type Registration

Type name: application

Subtype name: tm+json

Required parameters: None

Optional parameters: None

Encoding considerations: See RFC 6839, section 3.1.

Security considerations: See RFC 8259, section 12.

Since a WoT Thing Model 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 Model can be evaluated with a JSON-LD 1.1 processor, which typically follows links to remote contexts (i.e., TD context extensions, see W3C WoT Thing Description 1.1, section 7) 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 W3C WoT Thing Description 1.1, section 7) 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 [RFC3987] with short terms, WoT Thing Models 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://www.w3.org/TR/wot-thing-description11/

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): .jsontm, .tm.json, .tm.jsonld

Macintosh file type code(s): TEXT

Person & email address to contact for further information: tbd

Intended usage: COMMON

Restrictions on usage: None

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

Change controller: W3C

[sebastiankb]

For TD we should also ask for a change request with further file extensions:

File extension(s): .jsontd, .td.json, .td.jsonld

[JKRhb]

Does the media type registration for application/tm+json automatically include a CoAP Content-Format registration? Not sure if TMs are going to be exchanged using CoAP in practice but having the possibility to do so wouldn't hurt, I guess?

[sebastiankb]

not sure, @ektrah do you know more?

[ektrah]

CoAP Content-Format registrations are not automatic, but you can just include the registration in your request to IANA and they will handle it.

[sebastiankb]

for record: https://mailarchive.ietf.org/arch/msg/media-types/18Vt76FzOXhNxUD3Hax3ssNNNyg/

[sebastiankb]

from today's TD call:

• there is also a PR from @mmccool that provides some update about the TD content type entry https://github.com/w3c/wot-thing-description/pull/1428
• we should invite @plehegar to get some feedback about the new extension to the existing TD content type registration + about the Thing Model registration (see above)

[mmccool]

So this proposed draft ALSO includes inline assertions for security which has the same problem as the ones I just resolved for the TD (which also involved resolving some inconsistencies). It would be good also to update the TD IANA registration for TD1.1, which has new security considerations, etc. I think it should be OK to just list section numbers for the referenced specification for security considerations rather than repeating the text.

[mmccool]

There were a number of other issues I raised (as editor notes in my PR updating the Security considerations) about the TD IANA consideration, including simple things like contact information (the current one still lists Matthias as the main contact...). Yes, the TD IANA registration is a separate topic, but we should coordinate them.

[sebastiankb]

just for record: I just submitted the form to IANA. Status can be checked here: https://tools.iana.org/public-view/viewticket/1233681

[sebastiankb]

I received some feedback from IANA:

• Security considerations: wrong references in WD3 (linked sections were not available, compare WD3 version --> latest WD fixed this issue

• Fragment identifier considerations: It looks like "RFC 6901, section 6" can also be mentioned above (in addition to "RFC 6901, section 3") --> Commit added this text

[danielpeintner]

• Commit added this text

to not forget.. as mentioned in the call the commit does not properly link section 6

[egekorkan]

This issue is addressed more than a year ago, closing