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

From: "Paul Libbrecht" <[email-masked]>
Date: Wed, 12 Jun 2019 23:27:35 +0200

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

---

From: Matthias Kovatsch <[email-masked]>
Date: Sat, 15 Jun 2019 10:22:34 +0000

Dear Paul

Thank you very much for pointing us to the clipboard flavor names. I have been trying to figure out more from the IANA side, but they appear to be only managed by Microsoft and Apple, resp. Is there any IANA recommendation around it – as it is not even part of the registration form (https://www.iana.org/form/media-types). Can you or anyone else help on this?

I have also been thinking about the very specific “json-td” flavor name. One motivation has been that TD can be treated like JSON, for human “reasoning” and processing pipelines. At the moment, the most specific tools that we have are online editors that provide some syntax highlighting. Yet I think, no information would be lost when it is copied around as JSON. Technically, TDs are a specialization of JSON-LD, which in turn is a specialization of JSON, which again could be seen as a specialization of Unicode text.

Could someone explain, what for instance, the “public.json” flavor provides on top of “public.utf8-plain-text” when copy-pasting JSON documents? From this I could extrapolate what “json-td” could offer atop “json”. Are there any folks having arguments to have “json-ld” as a clipboard flavor name?

Thanks a lot,
Matthias

---

From: "Paul Libbrecht" <[email-masked]>
Date: Mon, 17 Jun 2019 08:37:14 +0200

Dear Matthias,

you’re basically asking for precision about my assertion:

> type-specificity is likely to give the best user-experience

Here is my interpretation and I am happy to hear about others’ point 
of view:

Type-specificity allows services to be specific (so, a user knows what 
to read and write because the UI is able to express it); lack of 
specificity gives freedom to users but this freedom is bound to a 
broader interpretation range.

As an example: text/html or text/json is only presented as text to 
people who understand it and is known to be sometimes quite painful to 
read. Similarly, using a generic editor for an OWL-RDF-encoded ontology 
works but requires the editors to be properly understood (I’ve never 
met newbie users to be confortable with Protégé for example).

So while I am happy to support the possibility of editing given by the 
text and json-ld nature; I still think that a specific type is the only 
way to make tools able to offer relevant services.

Note that the clipboard type is the most specific information you can 
use for a tool to be chosen as relevant or not; only an adjusted 
clipboard type can make it more specialised.
Finally, because there is sub-typing (alas only on macOS), slightly more 
generic services might still be applicable (e.g. json-ld browser or json 
structured display).

thanks.

Paul

On 15 Jun 2019, at 12:22, Matthias Kovatsch wrote:

> Dear Paul
>
> Thank you very much for pointing us to the clipboard flavor names. I 
> have been trying to figure out more from the IANA side, but they 
> appear to be only managed by Microsoft and Apple, resp. Is there any 
> IANA recommendation around it – as it is not even part of the 
> registration form (https://www.iana.org/form/media-types). Can you or 
> anyone else help on this?
>
> I have also been thinking about the very specific “json-td” flavor 
> name. One motivation has been that TD can be treated like JSON, for 
> human “reasoning” and processing pipelines. At the moment, the 
> most specific tools that we have are online editors that provide some 
> syntax highlighting. Yet I think, no information would be lost when it 
> is copied around as JSON. Technically, TDs are a specialization of 
> JSON-LD, which in turn is a specialization of JSON, which again could 
> be seen as a specialization of Unicode text.
>
> Could someone explain, what for instance, the “public.json” flavor 
> provides on top of “public.utf8-plain-text” when copy-pasting JSON 
> documents? From this I could extrapolate what “json-td” could 
> offer atop “json”. Are there any folks having arguments to have 
> “json-ld” as a clipboard flavor name?
>
> Thanks a lot,
> Matthias

---

From: Matthias Kovatsch <[email-masked]>
Date: Thu, 20 Jun 2019 21:26:25 +0000

Dear Paul

Unfortunately, there have not been any other voices to come to a better conclusion…

I have been thinking and I see your argument enabling tools to offer relevant services. What I am worried about is creating an incompatibility to valid alternative tool that work at the JSON or JSON-LD level; I assume the majority wouldn’t add such a specific identifier when they focus at a far more general level. However, there is no identifier for JSON-LD and, for some reason, not even JSON. The resulting level of interoperability across tools is then public.utf8-plain-text / CF_UNICODETEXT, which is indeed to coarse-grained to provide relevant services.

The new HTML 5.3 spec now includes these clipboard identifiers, which is pretty late considering the reach of HTML. Anyhow, it is an example for “adding it later”.

Hence, my conclusion for the moment would be to leave it out for the current version of the WoT TD spec. We should consult with the JSON-LD 1.1 Working Group if they think a JSON-LD clipboard flavor name/identifier would be useful (I think it would) and should be defined for the upcoming JSON-LD 1.1 spec. This then also entrails checking with the authors/editor of RFC 8259 if it wouldn’t make sense to define one for JSON. I hope that this then provides enough input to choose the right level. We have already been considering a 1.1 version of the TD format in the WoT WG charter discussion, which then would include the update for clipboard identifiers.

I hope we will get some more feedback until then also. Hearing from tool vendors would be great!

Best wishes,
Matthias