Re: [IANA #1160740] Request for media type application/ld+json

So just to clarify – application/ld+json is the correct thing to use for the media type of JSON-LD files.  Yes?

But the ability to have a “custom” type that is marked with +ld+json has been rejected.  Correct?

Leonard

From: Ivan Herman <ivan@w3.org>
Date: Friday, February 21, 2020 at 5:26 PM
To: Manu Sporny <msporny@digitalbazaar.com>, Robert Sanderson <azaroth42@gmail.com>, Benjamin Young <byoung@bigbluehat.com>, Gregg Kellogg <gregg@greggkellogg.net>, Dave Longley <dlongley@digitalbazaar.com>
Cc: W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
Subject: Fwd: [IANA #1160740] Request for media type application/ld+json
Resent-From: <public-json-ld-wg@w3.org>
Resent-Date: Friday, February 21, 2020 at 5:26 PM

Guys,

see below. It seems that the *+ld+json is an issue for IETF and cannot be done.

I think that, at this point, we should remove this thing from the JSON-LD spec and finalize the spec with ld+json. I do not think we should make the progress towards a Rec stop because of that.

Manu, Dave, there is a different discussion to take up on the DID side. But that should not affect the advancement of JSON-LD

WDYT?

Ivan


Begin forwarded message:

From: "Amanda Baber via RT" <iana-mime@iana.org<mailto:iana-mime@iana.org>>
Subject: [IANA #1160740] Request for media type application/ld+json
Date: 21 February 2020 at 16:43:31 GMT-5
To: ivan@w3.org<mailto:ivan@w3.org>
Reply-To: iana-mime@iana.org<mailto:iana-mime@iana.org>
Message-Id: <rt-4.4.3-4390-1582321411-1337.1160740-37-0@icann.org<mailto:rt-4.4.3-4390-1582321411-1337.1160740-37-0@icann.org>>

Dear Ivan,

The reviewers have identified issues with the following statement in the optional parameters section:

"Other specifications MAY create further structured subtypes by using +ld+json as a suffix for a new base subtype, as in application/example+ld+json. Unless defined otherwise, such subtypes use the same fragment identifier behavior as application/ld+json."

This paragraph effectively creates a new suffix called "+ld+json". The issues:

a) the suffix would need to be registered at https://www.iana.org/assignments/media-type-structured-suffix<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fmedia-type-structured-suffix&data=02%7C01%7Clrosenth%40adobe.com%7C463b0c7851504c1a7d4d08d7b71d17de%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637179207907683874&sdata=jWYERfZBRjYnxXQMr%2BavosMGMAooo%2FmPZeDEM98L3e8%3D&reserved=0>;

b) if the suffix registration request is submitted, it is likely to be denied at this time, because this requires a larger discussion in IETF;

c) the easiest way to approve the media type registration is to remove the above paragraph from the registration, then initiate discussion in IETF about nested suffixes (which one of the reviewers can take on). If the discussion results in "nested suffixes are OK", this registration can be updated to include the above paragraph.

Should we ask the reviewers if they can approve the template without the quoted paragraph?

In addition, can language be added to the template to indicate that it's an update to an existing registration?

Best regards,

Amanda Baber
Lead IANA Services Specialist


On Thu Jan 23 10:54:03 2020, ivan@w3.org<mailto:ivan@w3.org> wrote:


Name: Ivan Herman
Email: ivan@w3.org<mailto:ivan@w3.org>

Media type name: application
Media subtype name: ld+json

Required parameters: None

Optional parameters:
profile

A non-empty list of space-separated URIs identifying specific
constraints or conventions that apply to a JSON-LD document according
to [RFC6906]. A profile does not change the semantics of the resource
representation when processed without profile knowledge, so that
clients both with and without knowledge of a profiled resource can
safely use the same representation. The profile parameter MAY be used
by clients to express their preferences in the content negotiation
process. If the profile parameter is given, a server SHOULD return a
document that honors the profiles in the list which it recognizes, and
MUST ignore the profiles in the list which it does not recognize. It
is RECOMMENDED that profile URIs are dereferenceable and provide
useful documentation at that URI. For more information and background
please refer to [RFC6906].

This specification defines six values for the profile parameter.

http://www.w3.org/ns/json-ld#expanded

 To request or specify expanded JSON-LD document form.
http://www.w3.org/ns/json-ld#compacted

 To request or specify compacted JSON-LD document form.
http://www.w3.org/ns/json-ld#context

 To request or specify a JSON-LD context document.
http://www.w3.org/ns/json-ld#flattened

 To request or specify flattened JSON-LD document form.
http://www.w3.org/ns/json-ld#frame

 To request or specify a JSON-LD frame document.
http://www.w3.org/ns/json-ld#framed

 To request or specify framed JSON-LD document form.

All other URIs starting with http://www.w3.org/ns/json-ld are reserved
for future use by JSON-LD specifications.

Other specifications MAY create further structured subtypes by using
+ld+json as a suffix for a new base subtype, as in
application/example+ld+json. Unless defined otherwise, such subtypes
use the same fragment identifier behavior as application/ld+json.

Other specifications may publish additional profile parameter URIs
with their own defined semantics. This includes the ability to
associate a file extension with a profile parameter.

When used as a media type parameter [RFC4288] in an HTTP Accept header
[RFC7231], the value of the profile parameter MUST be enclosed in
quotes (") if it contains special characters such as whitespace, which
is required when multiple profile URIs are combined.

When processing the "profile" media type parameter, it is important to
note that its value contains one or more URIs and not IRIs. In some
cases it might therefore be necessary to convert between IRIs and URIs
as specified in section 3 Relationship between IRIs and URIs of
[RFC3987].


Encoding considerations: binary
See RFC 8259, section 11. (The JavaScript Object Notation (JSON) Data
Interchange Format, https://tools.ietf.org/html/rfc8259#section-11)

Security considerations:
    See RFC 8259, section 12. (The JavaScript Object Notation (JSON)
Data Interchange Format, https://tools.ietf.org/html/rfc8259#section-

11)

Since JSON-LD is intended to be a pure data exchange format for
directed graphs, 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.

When processing JSON-LD documents, links to remote contexts and frames
are typically followed automatically, resulting in the transfer of
files without the explicit request of the user 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.
Specific implementations, such as the API defined in the JSON-LD 1.1
Processing Algorithms and API specification [JSON-LD11-API], may
provide fine-grained mechanisms to control this behavior.

JSON-LD contexts 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 JSON-LD active context in a way
that could compromise security. It is advised that any application
that depends on a remote context for mission critical purposes vet and
cache the remote context before allowing the system to use it.

Given that JSON-LD allows the substitution of long IRIs with short
terms, JSON-LD documents may expand considerably when processed and,
in the worst case, the resulting data might consume all of the
recipient's resources. Applications should treat any data with due
skepticism.

As JSON-LD places no limits on the IRI schemes that may be used, and
vocabulary-relative IRIs use string concatenation rather than IRI
resolution, it is possible to construct IRIs that may be used
maliciously, if dereferenced.

Interoperability considerations:
N/A

Published specification:
https://www.w3.org/TR/json-ld/


Applications which use this media:
Any programming environment that requires the exchange of directed
graphs. Implementations of JSON-LD have been created for JavaScript,
Python, Ruby, PHP, and C++.

Fragment identifier considerations:
Fragment identifiers used with application/ld+json are treated as in
RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax
(https://www.w3.org/TR/rdf11-concepts/#section-fragID).

Restrictions on usage:
None

Provisional registration? (standards tree only):
No

Additional information:

1. Deprecated alias names for this type: None
2. Magic number(s): N/A
3. File extension(s): .jsonld
4. Macintosh file type code: TEXT
5. Object Identifiers: N/A

General Comments:
This is not a new media type, it has already been registered at
https://www.iana.org/assignments/media-types/application/ld+json.

However, the latest specification has added some extra features
(primarily in the profile parameter) which would require an update of
the media type document.

Person to contact for further information:

1. Name: Ivan Herman
2. Email: ivan@w3.org

Intended usage: Common
Any programming environment that requires the exchange of directed
graphs. Implementations of JSON-LD have been created for JavaScript,
Python, Ruby, PHP, and C++.

Author/Change controller: World Wide Web Consortium (W3C)



----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FPeople%2FIvan%2F&data=02%7C01%7Clrosenth%40adobe.com%7C463b0c7851504c1a7d4d08d7b71d17de%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637179207907693862&sdata=c1FqepQ8rcHNm8niOdZ6Atl1B7zF5JF6XEX0JTiW4zk%3D&reserved=0>
mobile: +31-641044153
ORCID ID: https://orcid.org/0000-0003-0782-2704<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0003-0782-2704&data=02%7C01%7Clrosenth%40adobe.com%7C463b0c7851504c1a7d4d08d7b71d17de%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637179207907693862&sdata=ODnDXKcMCEQewVkK%2FsCDBIN2oOivom%2BFAMFzub4dk24%3D&reserved=0>