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

["Paul Libbrecht" <[e-mail]>]

Dear Matthias,

It seems to me that this format is not unlikely going to be used in copy 
and paste scenarios. E.g. between editor applications which exchange 
configurations.
While I am too new to this standard to assert this, I would be 
interested to hear if you agree on that.

If you do, I would recommend that “clipboard flavour names” are 
included in your registration and replace the Macintosh file-type (which 
is not current anymore).
This was done by a few media-type declarations already (e.g. SVG or 
MathML) and ensures that applications that might include such do so 
right away with the same name.

Considering that type-specificity is likely to give the best 
user-experience, instead of aiming at text-type, I would like to suggest 
the following types for the Windows and macOS platforms:

* macOS UTI:  public.json-td extends public.json
* Windows: json-td

Note, however, that I have not found any software or specification that 
employs JSON-TD or even JSON-LD. If one is found for JSON-TD, this 
should probably be used. If one is found for JNSON-LD (which is far more 
generic), the extends of the UTI description should probably be 
adjusted.

Thanks in advance.

Paul




On 3 May 2019, at 11:36, Matthias Kovatsch wrote:

> 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 <[e-mail]>
>
> 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
>
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types