Re: Boundaries between AP and AS2, and between AS2 and non-AS2

The question is about media types as may be used with Content-Type, not the
URI scheme component or URNs.

In the default https: instantiation, ActivityPub says objects have ids and
may be dereferenced with a specific Accept header. It does not say that all
ids are objects in this way, however. Properties can have JSON string
values that are ids; are those necessarily AP objects? Do they necessarily
dereference to AS2 documents or representations?

If we say yes and conclude all ids referenced by ActivityPub objects MUST
also be ActivityPub objects, then this entails the following:

- (1) Not all AS2 documents are AP objects, because they can refer to
non-AP objects.
- (2) AP publishers and consumers cannot be sure whether they are working
with an AP object or an AS2 document, because all AP objects are serialized
as AS2 documents, and you can't tell which AS2 documents are also AP
objects, but per (1) some AS2 documents are non-AP.
- (3) AP is a fork of the Web, because it cannot be used to talk about
anything on the Web unless it has an AS2 representation that is an AP
object.

These all seem like contentious things to say!

If we say no and conclude that some ids referenced by ActivityPub objects
might not be ActivityPub objects, then we can maintain that AP is
compatible with the Web, and it's just a way to publish activities as AS2
documents. Less things break fundamentally, at the cost of uncertainty.

But if there's uncertainty, then we can try to clarify it. That's what this
thread is asking -- is there a way to be more explicitly clear about the
boundaries of an AS2 document?

We can try to do this in a few ways:

- Publishers author reasonably complete AS2 documents that already contain
the information needed to process them, without loading any linked
resources. Consumers MAY browse those links like any web browser, but they
can't expect AS2 in every case.
- Publishers might annotate certain ids as having AS2 representations;
consumers check for this before loading more information.
- A processing model for AS2 defines that all linked resources expected to
be dereferenced are marked up as a special form of reified as:Link. Perhaps
with a certain link rel or mediaType, consumers can know which links to
more safely load. AS2 processors wishing to comvert AS2 documents to
JSON-LD or vice-versa need to reify or unreify any as:Link as appropriate.

In practice, that might end up being the difference between this:

```json
{"actor": "https://alice.example/#alice"}
```

And this:

```json
{"actor": {"type": "Person", "url": {"href": "https://alice.example/#alice
"}}}
```

You could even do this:

```json
{
  "actor": {
    "id": "https://alice.example/",
    "type": "Person",
    "url": [{
      "href": "https://alice.example/#alice",
      "mediaType": "application/activity+json",
      "rel": "self"
    },
    {
      "href": "https://alice.example/#alice",
      "mediaType": "text/html",
      "rel": "self"
    }]
  }
}
```

But this leaves two follow-up questions:

- What is the link context of an as:Link? Can it be assumed to be the
current AS2 document, or the current node? This matters for the rel=self
link. https://github.com/w3c/activitystreams/issues/665
- How can we bridge the gap from mediaType being a "hint" to being an
indication that content negotiation is required and that it should be used
with an Accept header? https://github.com/w3c/activitystreams/issues/726