Do we need to support tokens, and if so, how?

[RubenVerborgh]

No description provided.

[RubenVerborgh]

See #8 (comment) and w3c/dxwg#290

[larsgsvensson]

Tokens are considered important in the W3C work on profiles, particularly for the Query String Implementation, so I think we need to cater for that.

[RubenVerborgh]

Oh… that's a part of the spec I really don't like. I understand how it ended up there, and I'm probably too puristic, but that's a very pragmatic solution for the short term, that is bound to cause trouble in the longer term.

Especially

A short token to specify a profile may be used as long as there is a discoverable mapping from it to the profile's identifying URI [ID5] (5.5)

is bound to cause trouble. Nothing is mentioned about the sustainability of that mapping, etc. This is going to bite back so hard, just because implementers want to look in the query string but not in the headers.

But yes, if I dislike it, I should have been more active in the DXWG, my bad 🙂

That said, I'm not sure to what extent we could/should bring such tokens, which seem to be an artifact of an API, to the protocol level.

[larsgsvensson]

What we could do is to keep tokens out of Accept-Profile / Content-Profile and only keep them in the profile target attribute in the Link header. And we probably also need a solution for the 300 Multiple Choices reply

[larsgsvensson]

This has been resolved over at DXWG/conneg-by-ap:

Servers can use a second link header to publish any mapping between a profile URI and the corresponding token. This is now part of conneg-by-ap in example 12, and the Link header attribute token is defined in the same document in §7.1

Thus this issue can be closed