What are the semantics of Accept-Post

[acoburn]

The LDP specification mentions the recommended use of the Accept-Post response header (in cases where POST is supported). The header itself is defined in a draft IETF document.

In the examples from the LDP documentation, this header is shown to list the various RDF serializations that a server will accept, along with any specific non-RDF mime types. Yet if a Solid server supports ldp:NonRDFSource resources of arbitrary type, it is clearly not practicable to list every known data serialization.

Is it within the scope of the Solid specification to describe what to do in this case? Should the presence of a format in this list merely indicate that the server definitely supports that format? and that the absence of a given format has no significance? Or should a server indicate only the RDF serializations that are supported? E.g.:

Accept-Post: text/turtle, application/ld+json, application/n-triples

Alternatively, should that response header contain a wildcard mime type for all possible NonRDFSource types? E.g.:

Accept-Post: text/turtle, application/ld+json, application/n-triples, */*

[csarven]

Well, to what extent do we want to apply the robustness principle?

Overall, I don't think the semantics of Accept-Post should depend on knowledge of LDP/RDF in Solid's case. We shouldn't bake anything on top in my opinion.

...

Should the presence of a format in this list merely indicate that the server definitely supports that format?

I think that's probably the safest and most efficient way of going at it.

and that the absence of a given format has no significance?

But then not listed would mean it is not supported, right? It may have no significance in that a client may want to try a request any way but that's actually unspecified territory (besides however conneg and response happens to be).

Or should a server indicate only the RDF serializations that are supported?

I don't think so. The server may want to indicate only the serializations that it supports for the Request-URI however eg. some containers may be for RDFSource while others may be for NonRDFSource, and yet another would be a mix. I don't think the Solid spec should reserve Accept-Post for listing only RDFSources - if that's what you are getting at.

Alternatively, should that response header contain a wildcard mime type for all possible NonRDFSource types?

I don't think the wildcard should be reserved for NonRDFSource. If used, isn't it redundant to list specific types?

There may be a sort of a middle ground by using the "media range". For example, instead of listing all image types, perhaps do image/*?

I think one issue we had was how a server can indicate whether they'll handle text/html (or application/xhtml+xml or image/svg+xml..) as RDFSource or NonRDFSource, or maybe even as either. More broadly - probably redundant or overkill! - should a server also say which of the listed types can be handled as RDFSource and which as NonRDFSource? Gave a straw man shot at that here: https://github.com/solid/solid-spec/issues/202#issuecomment-512976989 and gave up. The question may also be if they are all just RDFSources in disguise?

[timbl]

The IETF header spec needs to define the semantics.
We shouldn't answer it here. If we do decide here, it is reasonable for the spec to follow this.

Does solid in fact need this? It does need accept-patch, but maybe not accept-post

[csarven]

POST is used extensively so Accept-Post is useful.

One area in which it helps is some existing specs require specific media types for exchange. To give out-of-spec content negotiation a chance, OPTIONS with Accept-Post is needed whilst implementations keep conformance with those specs eg. ActivityPub, Web Annotation, LDN, as well as future specs. That essentially allows servers and clients to agree on something other than Turtle and JSON-LD (pending #45 for Solid), if they so wish.

I have some implementation experience with Accept-Post. It would be useful to know if existing implementations rely on Accept-Patch. The only media type that's been used for PATCH to date that I know of is application/sparql-update. Is Accept-Patch actually needed on those grounds? I don't think so, but that's also not grounds to dismiss Accept-Patch as we'd like to support other media types for PATCH. At the very least, the spec leaves an open door for things to evolve independently.