Requirements on Accept / Content-Type should be loosened to account for non-LD use

[trwnh]

Background: application/activity+json vs application/ld+json in AS2-Core vs AP

I wasn't sure whether to file this in https://github.com/w3c/activitystreams or https://github.com/w3c/activitypub, but I'm filing it here in ActivityPub because of implications of the specific wording used in ActivityPub but not ActivityStreams. It is an issue that otherwise might also apply to ActivityStreams, depending on certain conditions. (EDIT: I've split out w3c/activitystreams#684 at least.)

So AS2-Core says that an AS2 document is application/activity+json, but you SHOULD treat ld+json with the activitystreams profile as equivalent. But AP requires that clients MUST use ld+json with the activitystreams profile, and servers aren't required to respond to requests for application/activity+json (even though they SHOULD -- and in the case of the outbox this is even downgraded to a MAY for seemingly no reason -- see #570 for more).

In practice, implementations that use "extension" terms have varying levels of support for including additional term definitions, and signaling the additional semantics might not be done at all. So we end up in a situation where some clients have extra knowledge, but some clients don't, and thus they can't safely use the same representation anymore. But they can't reliably negotiate this because the requirements that AP places on the Accept and Content-Type headers are too strict. Saying that you MUST use ld+json even when you don't understand ld+json is flawed when you should be able to negotiate for activity+json without the implications of ld+json.

Recommended actions

• When requesting and serving ActivityPub resources:
  • Allow using either application/activity+json or application/ld+json, depending on whether you use / conform to JSON-LD or not.
  • Note that application/ld+json carries additional expectations regarding "@context"
  • Account for profiles during content negotiation? (See also Do profiles of application/activity+json also profile application/ld+json? activitystreams#684 as mentioned before)

Related issues:

• Clarify permissibility of additional Accept media types during content negotiation #502

[evanp]

I think we should fold this into #570 . We should simply declare in the AP doc that activity+json and ld+json with profile are defined as equivalent in AS2 Core and can be used as equivalents anywhere in AP.

[trwnh]

#570 is a specific discrepancy between SHOULD/MAY/SHOULD.

This issue is the more general question about the actual equivalence, and the requirement to always use ld+json in HTTP requests and responses even when JSON-LD isn't being used (or when the requirements of ld+json might be violated out of naivete or ignorance.)

[evanp]

activity+json is a proper subset of ld+json. That is a definition.

There is no daylight between them. There is no such thing as using ActivityPub without using JSON-LD.

Every Activity Streams Document must be formatted like a compacted JSON-LD document, no matter what tools you used to generate it.

That doesn't mean you have to use jsonld.js or jsonld.py. We cannot define what tools people use to publish or consume AS2. We'd like it to be possible to do so with a lot of different kinds if tools -- from printf() statements to JSON formatters to JSON-LD parsers.

If we identify aspects of AS2 that are inappropriate for a profile of JSON-LD, we need to deprecate them in this version of AS2 and remove them in future versions. In my review, I think they are small.

[trwnh]

By "JSON-LD being used", I don't mean how a document was generated; I mean how a document is processed.

The processing model of ld+json is "linked data". Using this type indicates an intent to process linked data, i.e. as a form of knowledge graph.

The processing model of activity+json is "activity streams". Using this type indicates an intent to do stuff with activities. We don't get too in-depth or detailed about what that stuff might entail, but it can differ from linked data processing.

In the base case, activity+json does not require a @context, while ld+json does. This is covered in the linked AS2 issues.

However, the current issue is about AP's use of HTTP's Accept and Content-Type headers. Requiring requests to use ld+json even if they don't understand or adhere to JSON-LD requirements can be confusing. The profile needs to be recognized to be applied. A request might Accept ld+json with the profile but receive a Content-Type of ld+json without the profile. This is not a violation, because profiles are optional, and ignoring profiles shouldn't alter the base media type constraints or processing model. (The related issue #502 deals with permissibility of using additional types, and this issue deals with the permissibility of using activity+json instead of ld+json.)