This section is non-normative.
+ +This section is non-normative.
+ +The Solid Protocol and the Linked Data Platform (LDP) [LDP] both use relative referencing of URIs [RFC3986].
+ +As HTTP clients assign a URI to a resource when using PUT and PATCH, relative references in representation content are deterministic in both the Solid Protocol and LDP.
LDP does not specify URI patterns for resources when using the POST method, e.g., POST http://example.org/foo/ may result in creating a resource with URI http://example.org/foo/bar, http://example.org/baz/qux/quxx, http://example.org/{uuid} or something else. In Solid Protocol, the URI of a new resource resulting from, e.g., POST http://example.org/foo/, is in context of the request URI, and therefore http://example.org/foo/bar will be created, and it is not possible to construct the new URI besides under the direct hierarchy of http://example.org/foo/.
Solid Protocol's server behaviour in that regard is compatible with LDP even if only ldp:Container is advertised in the HTTP Link header of the request URI, i.e., http://example.org/foo/ as the effective request URI of POST. Thus, it is possible to have a Solid Protocol server as a particular specialisation of LDP with respect to behaviours around POST to containers. Clients that are interoperable with LDP servers would also be interoperable with Solid Protocol servers with respect to relative referencing. Although LDP servers cannot guarantee the URI pattern resulting from POST requests, the fact that Solid Protocol servers can does not impact interoperability between Solid Protocol servers and LDP clients.
Solid Protocol clients may not fully interoperate with LDP servers, e.g., it is possible for an LDP server implementation to assign URIs to new resources that are not compatible with Solid Protocol. An LDP server needs to also conform to Solid Protocol server requirements in order to participate in the Solid ecosystem.
+Content-Type in messages with payload.