Linkset profiles and preferences

[termontwouter]

Opening this to continue the discussion without spamming PR #180.

To characterize the nature of the discussion:

• As @dmitrizagidulin has emphasized, there is an underlying philosophical disagreement at play here, about the nature of resources and representations.
• As @gibsonf1 stated, the resource-based terminology of the spec, which we inherit from Solid, influences many of our decisions.
• While I agree with both, it is a tension we will probably not resolve, so we better focus on finding a good compromise on the practical aspects.

The status quo of the current draft:

• A primary resource's responses have Link headers to its auxiliary information.
• These web links are not further qualified (only the rel parameter is specified).
• The links MAY have their anchor as target, effectively making the primary resource the source of its own auxiliary information.

The main remaining issue is that in the latter case (anchor == target), resources cannot have (non-auxiliary) representations in the same media type as their auxiliaries, since it would be unclear which information to serve.

Potential ways forward

1. Keep the current status quo, and let servers supporting the latter functionality declare unsupported media types.

2. Specify that requests for auxiliary information should indicate this with a Prefer header. This entails:

   • Requests for resources with a media type that is also used for auxiliary information can result in different data depending only the header's presence. (I.m.o. a non-issue, since the Prefer header spec contains similar examples. Moreover, responses can indicate whether a preference was applied, with the Preference-Applied header.)

   • The Prefer header spec explicitly states that implementers "SHOULD NOT use the Prefer header mechanism for content negotiation", since doing so might impact caching. (They require listing Prefer in the Vary header when doing so anyway.)

   • Only LWS-specific clients can make use of this feature, since it adds requirements/behavior on top of the Web Links & Linksets RFCs.

3. Specify that requests for auxiliary information should indicate this with a profile parameter appended to the media type. (Note that *the Linkset spec explicitly mentions this parameter, for such use cases, so any client understanding Linksets can make use of this feature.) This entails:

   • Requests for resources with a media type that is also used for auxiliary information can result in different data depending only the parameter's presence. (I.m.o. a non-issue; rather the point of requesting a specific profile.)

   • Strictly speaking, this 'moves' the problem from the shared media type to the shared profiled media type, which again cannot appear as a separate data resource. (I.m.o. a non-issue, since we can define the profile to only have semantics as an LWS auxiliary, never as a data resource.)

Option (3) is the approach currently drafted in PR #180.

---

Note that options (2) and (3) are not necessarily mutually exclusive: there have been attempts at standardizing Prefer: profile=xyz as a way to indicate media-type-independent profiles. For example Prefer: profile=lws-meta could indicate a request for metadata, regardless of the media type.

In particular, one could make a case for using it uniformly (cf. #188) for the StorageDescription CID, and for Container's JSON-LD representation as well. Instead of introducing multiple application/lws+format types, LWS would then simply require clients to add the type-independent profile preference whenever they're interested in metadata rather than data.

[termontwouter]

Actually, if we want uniformity (cf. #188), it could also be an option to use a suffixed media type for the link sets as well. Similar to how we use application/lws+json for general metadata (storage descriptions, containers etc.), we could add a application/lws+linkset for the metadata-specific link set. Just as with application/lws+json, a client is not supposed to put it as data resource on the storage.

Note that application/lws+linkset+json, and in fact also application/lws+ld+json, are equally valid media types (RFC 6838), regardless of the continuation of the Media Type Suffixes draft.