Discrepancy on equivalence of activity+json (SHOULD/MAY/SHOULD)

[trwnh]

Context

AP Section 3.2:

[Servers] MUST present the ActivityStreams object representation in response to application/ld+json; profile="https://www.w3.org/ns/activitystreams", and SHOULD also present the ActivityStreams representation in response to application/activity+json as well. The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type in order to retrieve the activity.

AP Section 6:

[Clients] MUST make an HTTP POST request to [the actor's outbox] URL with the Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams". Servers MAY interpret a Content-Type or Accept header of application/activity+json as equivalent to application/ld+json; profile="https://www.w3.org/ns/activitystreams" for client-to-server interactions.

AP Section 7:

POST requests (eg. to the inbox) MUST be made with a Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams" and GET requests (see also 3.2 Retrieving objects) with an Accept header of application/ld+json; profile="https://www.w3.org/ns/activitystreams". Servers SHOULD interpret a Content-Type or Accept header of application/activity+json as equivalent to application/ld+json; profile="https://www.w3.org/ns/activitystreams" for server-to-server interactions.

Issue description

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.

• retrieving objects: SHOULD
• c2s/outbox interactions: MAY
• s2s/inbox interactions: SHOULD

I can't think of a good reason why there would be a discrepancy. Maybe someone else can think of one?

Split issues

• Do profiles of application/activity+json also profile application/ld+json? activitystreams#684
• ld+json with "activitystreams profile" violates expectations of ld+json profile= parameter activitystreams#685
• Requirements on Accept / Content-Type should be loosened to account for non-LD use #571

Recommended actions

This issue would benefit from being considered alongside the split issues, but perhaps minimally could be solved by considering whether that MAY should actually be a SHOULD. (There are larger questions about whether the equivalence actually holds and in which circumstances, but the split issues go into more detail there.)

[evanp]

We should make it clear that activity+json and ld+json plus the profile are equivalent for all parts of ActivityPub once, and get rid of the per-endpoint specifications. They are declared equivalent in AS2, and it's not reasonable to make a further distinction, to no practical use, in AP.

[trwnh]

I think it could make sense to extract the media type recommendations and have them in one place, but the exact equivalence depends on profiling, versioning, and the additional requirements of ld+json (as the linked issues get into in more depth).

[TallTed]

ld+json with a profile

This is sloppy, and will not be viable in the long term.

"with a profile" says that ld+json with any profile, not just profile="https://www.w3.org/ns/activitystreams", makes it equivalent to application/activity+json.

If I read the discussion correctly "any profile" is not really what is meant. On that basis, I strongly advise adjusting the title of the issue.