Consider HTTP 300 as realization for list profiles / list tokens

[azaroth42]

OPTIONS is not cacheable, and there isn't a profile parameter for the Link header construct ... so ... how about an HTTP 300 Multiple Choices response?

HTTP 300 says:

For request methods other than HEAD, the server SHOULD generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred.

This would allow the response to describe the URIs of the representations, and their metadata, thus including both profile URI and token, if any. The disadvantage is that it would be a custom response format, but one that is likely very obvious and could tie back to other DXWG deliverables.

[azaroth42]

Alternatively, or in addition, the document returned could be referenced from a link header. That would mean that we would register a new rel type, similar (abstractly) to the timemap rel type registered by Memento. (RFC7089) Then dereferencing that representation would give the information about the available profiles (and any tokens).

[larsgsvensson]

@azaroth42 scripsit:

That would mean that we would register a new rel type, similar (abstractly) to the timemap rel type registered by Memento. (RFC7089)

Or we use the 'profile' target attribute as proposed in w3c/dxwg#501.

We could also consider to extend the text/uri-list media type by adding the possibility to convey profile (and token?) information, à la

<http response>
HTTP/1.1 300 Multiple Choices
Content-Type: text/extended-uri-list

https://example.com/some/resource/profile-1 profile="urn:example:profile-1^profile-1-token"
https://example.com/some/resoucre/profile-2 profile="urn:example:profile-2^profile-2-token"

The syntax for profiles is only meant as an example . The basic idea is to to extend text/uri-list to

*line
line = URI [WSP "profile=" URI [^profile-token]] \r\n
WSP = SP / HTAB # from RFC 5234

so that we can specify which profile the resource representation conforms to and (optionally) which token can be used instead of the profile URI.

[larsgsvensson]

@azaroth42 We discussed this issue in the CNEG meeting on 2019-09-12. The decision was to move this to future work. Is that OK for you?

[nicholascar]

I agree with marking as future work, this comment’s just for future readers.

it would be a custom response format

Goven that we now have the Alternate Profiles data model, the body payload could be conformant with that, serialised in an RDF format or tabulated in HTML (we have examples of both in the doc).

[azaroth42]

Sure, no problem. Thanks for checking in!

[larsgsvensson]

Thanks @azaroth42. I've marked this as future-work.

[rob-metalinkage]

possible solution: after

The server SHOULD attempt to reply with a profile that best matches the client request.

add

The server MAY respond with the ALTR representation and a HTTP 300 code as a fallback if unable to determine an appropriate response, such as when an explicit media type not supported is requested.