Resource creation behaviour when using the `Slug` header

In the current LDP specification, a client is allowed to hint for a resource name at creation time by setting the Slug header in the POST request (see section 5.2.3.10). However, since the usage of the Slug header is quite flexible, the LDP spec does not specify the expected behaviour when requesting for the creation of a resource with a slug that's already present in the parent's containments.

Depending on the implementation, different behaviours may therefore be expected:

• Preventing the creation of a new resource with the same slug altogether, and returning a 409 Conflict response to the client, potentially including a Link <iri>; rel="ldp:constrainedBy" header, wit iri pointing to a vocabulary defining a term specifying "The requested IRI already exists"
• Creating the resource combining the slug to a generated ID, and returning the resource IRI to the client in the response's Location header

Since these two behaviours are compliant by the LDP spec, I don't know if imposing one over the other is desirable in the Solid spec, but it may be worth mentioning that these outcomes are possible in the LDP section of the Solid spec, as a non-normative remark.

Do you think this needs to be addressed, and if so as a normative or a non-normative bit ?

Start with the LDP specification, especially section 5.2.3.10 and its Slug guidance, then review the Solid specification section that discusses LDP behavior and the existing issue comments. Resolve whether duplicate-slug outcomes should be described and whether that text should be normative or non-normative; done means the specification wording and decision are clear.