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

> On 22 Feb 2020, at 20:33, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> 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?

Yes and yes

Ivan

>  
> Leonard
>  
> From: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>
> Date: Friday, February 21, 2020 at 5:26 PM
> To: Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>>, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com>>, Benjamin Young <byoung@bigbluehat.com <mailto:byoung@bigbluehat.com>>, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>>, Dave Longley <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>>
> Cc: W3C JSON-LD Working Group <public-json-ld-wg@w3.org <mailto: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 <mailto: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>

----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: https://orcid.org/0000-0003-0782-2704