Dxwg: Registration of target attribute "profile" for the Link-Header

[larsgsvensson]

The examples given for the use of the http Link header uses the target attribute profile that is not yet registered. Cf. https://tools.ietf.org/html/rfc5988#section-5.4

[nicholascar]

I don’t understand as I see it register here:
https://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1

[larsgsvensson]

https://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1 is the registry of link _relation types_ (i. e. what comes in rel="...". The issue about profile="..." requires a new target attribute in Link

[rob-metalinkage]

profile is defined - and explained here https://tools.ietf.org/html/rfc6906

AFIACT it is consistent with our model, but not as explicitly defined (seems a bit vague really)

note that is says:
"Note that, at the same
time, it is possible for profile target URIs to use dereferencable
URIs and to use a representation (which is outside the scope of this
specification) that represents the information about the profile in a
human- or machine-readable way."

[larsgsvensson]

I might have gotten this wrong, so apologies up front...
RFC 6906 defines the _link relation type_ "profile" (as in
Link: <urn:example:profiles:1>; rel="profile" relating the context URI to <urn:example:profiles:1> as the profile URI for the context URI).
The case I'm trying to model is that two URIs are linked through the relation "alternate" (saying that one URI is an alternative representation of the other; rel="alternate"). In this case I want to say which profile the alternative representation ("link target", in RFC 5988 lingo) has. Since the link relation is already "alternate", I need to have a target attribute "profile", so that I can say
Link: <http://some.domain/alternative/representation>; rel="alternate"; type="text/turtle" profile="urn:example:profile:1"
I don't think I can do that with RFC 6906.

[rob-metalinkage]

ahh - i see - you dont want the link relation "profile" at all - we need to explain this better both both cases.

so rel="profile" is to designate the profile of the current resource
and rel="alternate" profile="X"

Agreed - we can see

what about the list of alternates (profiles) supported - does this need a special link rel too?

[larsgsvensson]

@rob-metalinkage scripsit:

what about the list of alternates (profiles) supported - does this need a special link rel too?

My suggestion is to have a Link header that lists the cartesian product of all media types and profiles as shown in Example 2. Would that work for you?

[azaroth42]

:+1: to this issue. There isn't a registry for parameters on the link header entries, so this would require a new RFC to add the parameter, obsoleting 5988.

[dret]

+1 to @azaroth42: the WD as just published seems to assume that there is a registry of target attributes. there is no such thing. RFC 5988 just was updated (see #632), and there still is no profile target attribute or a registry for all target attributes, but there is a section on how to define new ones: https://tools.ietf.org/html/rfc8288#section-2.2

[larsgsvensson]

Just as a reminder to myself: The syntax for the profile attribute must somehow also allow the server to map a profile URI to a profile token. Cf. #290

[larsgsvensson]

There is now text in the proposed I-D that defines the link header target attribute "profile"

[larsgsvensson]

See also @hvdsomp 's suggestion to include the attribute 'profile' in the new Link-Hints registry

[dret]

On 2019-06-19 06:01, Lars G. Svensson wrote:

See also @hvdsomp https://github.com/hvdsomp 's suggestion to include
the attribute 'profile' in the new Link-Hints registry
https://github.com/ProfileNegotiation/I-D-Profile-Negotiation/issues/17#issuecomment-498547785

just as a note: the link-hint draft has been around for a while and
abandoned for a while, and it's less than certain that the draft (and
thus the registry) will make it to the finish line.

[hvdsomp]

Yes, I get that. I still feel that this attribute should be defined generically, not tied to this specific spec. Solidarity!

On Jun 20, 2019, at 18:06, Erik Wilde [e-mail] wrote:

On 2019-06-19 06:01, Lars G. Svensson wrote:

See also @hvdsomp https://github.com/hvdsomp 's suggestion to include
the attribute 'profile' in the new Link-Hints registry
https://github.com/ProfileNegotiation/I-D-Profile-Negotiation/issues/17#issuecomment-498547785

just as a note: the link-hint draft has been around for a while and
abandoned for a while, and it's less than certain that the draft (and
thus the registry) will make it to the finish line.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[larsgsvensson]

@hvdsomp scripsit:

Yes, I get that. I still feel that this attribute should be defined generically, not tied to this specific spec. Solidarity!

we're certainly on the same page when it comes to solidarity. And I don't see how defining the 'profile' attribute in the RFC restricts it to be used only within the scope of that specific spec.
The RFC is only specification document for the attribute. That does not tie the attribute to be used only in the context of profile-negotiation (i. e. Accept-Profile and Content-Profile). A similar case is wdrs:isDefinedBy: It's specified in POWDER but my gut feeling is that this property is mainly used outside of POWDER descriptions.

[larsgsvensson]

I have a general feeling that this issue has been adequately discussed and that we've reached consensus that the text in the IETF draft covers this. @dret, @hvdsomp, @azaroth42: do you agree?
If yes, I think we can mark this issue as "due-for-closing"

[dret]

On 2019-08-19 11:51, Lars G. Svensson wrote:

I have a general feeling that this issue has been adequately discussed
and that we've reached consensus that the text in the IETF draft
https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation.html#rfc.section.6
covers this. @dret https://github.com/dret, @hvdsomp
https://github.com/hvdsomp, @azaroth42 https://github.com/azaroth42:
do you agree?
If yes, I think we can mark this issue as "due-for-closing"

fine with me. thanks!

[hvdsomp]

Lacking a registry for target attributes, defining one in an RFC is probably the next best thing. It can be interpreted to be aligned with the Target Attributes section of RFC8288.

I wonder, however, whether the text in the current I-D makes the below intent expressed by @larsgsvensson clear enough, especially since that text also talks about Content-Profile:

That does not tie the attribute to be used only in the context of profile-negotiation

[larsgsvensson]

@hvdsomp scripsit:

I wonder, however, whether the text in the current I-D makes the below intent expressed by @larsgsvensson clear enough, especially since that text also talks about Content-Profile:

That does not tie the attribute to be used only in the context of profile-negotiation

Would it help to change this text to

Note that this is only a hint; for example it does not override the value of an http header field such as "Content-Profile" of an HTTP response obtained by actually following the link.

?

[azaroth42]

Yes, fine by me, thank you!

[hvdsomp]

Oops, I had missed @larsgsvensson above suggestion. Minimalist change but ok for me. Cheers.

[larsgsvensson]

OK, thank you all. There seems to be consensus that the text in the IETF draft covers this:

When used in a Link header field, the "profile" attribute is a hint indicating which profile the resource representation retrieved by dereferencing the link conforms to. Note that this is only a hint; for example it does not override the "Content-Profile" header field of a HTTP response obtained by actually following the link. Multiple "profile" attributes on a single link value indicate that the resource representation conforms to multiple profiles.

Now we only have to resolve #290 and we're ready to close.

[larsgsvensson]

The discussion over in #290 (unfortunately) has implications for this issue, too.
The preferred way of publishing URI/token mappings discussed there is to use the Link header and the target attribute profile discussed here. That way a host could declare that for the resource https://example.org/some/resource the URI urn:example:foo is mapped to the token bar by adding the following Link header to the http response:

Link: <https://example.org/some/resource>
    profile="urn:example:foo token=bar"

Currently, the I-D defines the value of the profile parameter as absolute-URI. That means that if we want to support tokens, we need to extend the syntax of the profile attribute to something like
absolute-URI[<delimiting-character>"token"=token] (where the first "token" is the string "token" and the second "token" is a token defined as in RFC 7230 §3.2.6) which would allow

profile="urn:example:foo|token=bar"

My personal feeling is that defining an extension to the profile attribute only to map tokens to URIs is a Bad Idea (TM), particularly since we might not need it (depending on #290). In order to future-proof the syntax, however, it could make sense to define a generic extension syntax, à la
absolute-URI[<delimiting-character>token=token] which would also allow

profile="urn:example:foo|bar=baz"

As <delimiting-character> we need something not allowed in absolute-URI. Blank (U+0020) or pipe (U+007C) come to mind. If we use blank, we also must mandate the use of quotation marks on the right hand side of profile="bla".
See also https://github.com/ProfileNegotiation/I-D-Profile-Negotiation/issues/12 and https://github.com/ProfileNegotiation/I-D-Profile-Negotiation/issues/8.
@nicholascar, @rob-metalinkage, @RubenVerborgh: What do you think?
And ACTION-290

[RubenVerborgh]

@larsgsvensson Agree with your assessment; extending the syntax is to be avoided.

[rob-metalinkage]

@larsgsvensson I think that is a good way to resolve this - if the IETF allows for additional parameters other specifications can standardise what they mean.

one minor tweak would be to allow token values to be lists (separated by , ? )
Certainly easy enough to implement this approach.

Also - it may be useful to allow servers to indicate what they know about profile hierarchies in a special token ( eg profileof=A,B,C) - if we can use URIs as token values legally?

[larsgsvensson]

@RubenVerborgh scripsit:

Agree with your assessment; extending the syntax is to be avoided.

Does that mean that you agree that we extend the syntax for the profile attribute to absolute-URI[" "token=token] or that you don't agree?

[hvdsomp]

I seem to remember having expressed significant concerns about the token approach in a private email exchange with @larsgsvensson and @RubenVerborgh. A very significant complication that is hard to motivate.

[larsgsvensson]

@hvdsomp scripsit:

I seem to remember having expressed significant concerns about the token approach

Yes, you have. That said, I think that an extensible syntax for the profile attribute that does not only allow for token=foo but for any parameter (e. g. foo=bar) does make sense. If people decide to use it for tokens, they may do so, but then that's outside of the IETF document's scope (which this issue is really about).

[larsgsvensson]

@rob-metalinkage scripsit:

... if we can use URIs as token values legally

RFC 7230 §3.2.6 defines token as follows:

Most HTTP header field values are defined using common syntax
components (token, quoted-string, and comment) separated by
whitespace or specific delimiting characters. Delimiters are chosen
from the set of US-ASCII visual characters not allowed in a token
(DQUOTE and "(),/:;<=>?@[]{}").

token = 1*tchar

tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except delimiters

That means that URIs cannot be used as tokens since e. g. the colon character is not allowed in tokens.

[RubenVerborgh]

That said, I think that an extensible syntax for the profile attribute that does _not only allow_ for token=foo but for _any parameter_ (e. g. foo=bar) does make sense. If people decide to use it for tokens, they may do so, but then that's outside of the IETF document's scope (which this issue is really about).

+1 to that. There might indeed be use cases for key/value pairs in the future. However, could you remind me why we would be adding those _inside_ of profile rather than as extra attributes to the Link header itself?

[larsgsvensson]

@RubenVerborgh scripsit:

However, could you remind me why we would be adding those inside of profile rather than as extra attributes to the Link header itself?

Because those key/value pairs would be attributes of the profile URI (i. e. the value of the profile attribute) and not of the link's context URI.

[RubenVerborgh]

Ah yes. But that actually opens up another avenue: why not just use _another_ Link header with the profile as context? Then we can attach the attributes we want.
Seems cleaner than reinventing the attributes extension point inside of a string.

[rob-metalinkage]

Sounds like a good idea.. can you propose a pr with an example and correct wording by any chance, since you are most expert in this area?

[RubenVerborgh]

Will do; just want to hear @larsgsvensson's feedback.

[larsgsvensson]

@RubenVerborgh scripsit:

why not just use another Link header with the profile as context? Then we can attach the attributes we want.
Seems cleaner than reinventing the attributes extension point inside of a string.

Brilliant! +1000, please go ahead!
Further thoughts: Then we can define the Link header attribute token in the W3C doc where we'd need to highlight that the mapping between the profile as context and the profile's token is only guaranteed to be valid for the requested resource.

[RubenVerborgh]

@larsgsvensson Thanks! Suggestion in https://github.com/w3c/dxwg/pull/1063.

[larsgsvensson]

Resolution: The IETF document will contain text to register the target attribute profile for the Link header as follows (cf. my comment above)

When used in a Link header field, the "profile" attribute is a hint indicating which profile the resource representation retrieved by dereferencing the link conforms to. Note that this is only a hint; for example it does not override the "Content-Profile" header field of a HTTP response obtained by actually following the link. Multiple "profile" attributes on a single link value indicate that the resource representation conforms to multiple profiles.

Since there is consensus on that, I mark this issue as "due-for-closing". The discussion about the mapping of tokens to URIs are really part of #290 so I shall comment there.

[agreiner]

Maybe we don't really need to worry so much about indicating tokens in headers. We already agreed in issue #453 that these tokens don't need to be globally unique, that they are just suggested or preferred identifiers. I would suggest we take that one step further and say that they are suggested/preferred specifiers, not identifiers. Rather than calling them alternative identifiers for profiles, we could limit their use to within application URLs. A given API may use any locally unique token to allow selection of a particular instance of a dataset that conforms to a profile, and it can always return the URI as the actual identifier for the profile used. A listing of available profiles can include the tokens or (better) full URIs for the dataset and also the actual URI identifiers for the profiles themselves. In this view, the token is simply a convenient specifier for use in a query string or the path of a URL. The suggested token needn't be specified anywhere except in the profile itself, and even that is just a helpful suggestion. This allows tokens to continue to be used where they are currently being used and where they nicely avoid complex URIs, and it avoids calling them a formal identifier for the profile. I don't see a need for the token to be dereferenceable on its own if the actual URI is included as the identifier in the server response.

[rob-metalinkage]

@agreiner that is exactly how this requirement has been met in the conneg-by-ap specification.

We can discuss changing the word from identifier - but neither identifier nor "specifier" have any formalised meaning here that affects the specification functionality - so its just a wording change we could consider the merits via a PR or separate issue. This issues is about the requirement which has been met.

[agreiner]

What I'm suggesting is that there would no longer even be a need to include token information in the headers.

[larsgsvensson]

@agreiner The need (or not) for conveying token/URI mappings in a machine-readable fashion has been discussed at length here and elsewhere. There is a requirement in #290 that we need to supply such mappings if we decide to allow the use of tokens (which we do). Do you have an alternate proposal for the implementation of machine-readable mappings?

[RubenVerborgh]

@agreiner It seems that many people (including myself) do not need it, but it matters to @rob-metalinkage and @nicholascar (as seen in https://github.com/w3c/dxwg/issues/290 indeed).

The good thing is that, with the merge of https://github.com/w3c/dxwg/pull/1063, the token mechanism now no longer interferes with anything else. It's a completely separate mechanism that can be ignored without consequence when the client or server wants to. So those who are not in favor of tokens are completely unaffected, which wasn't the case previously.

[agreiner]

@larsgsvensson I've not seen discussion that convinces me that we really need token mappings, and my reading of previous discussion on this issue is that we no longer even expect there to be a one-to-one mapping. Suggested tokens are only the preferred one. Tokens are only needed for the case where you want to keep your URIs clean in a QSA implementation. All other possible uses for tokens can be handled by URIs. There is no need to invent new link headers. I think the "as long as there is a discoverable mapping" went into the title because that is the typical assumption for the case where a thing has the same standing as a URI and can be used in the same ways. But we've moved away from that assumption. If URIs can be used everywhere else, then tokens need only fill the role of providing a nice-looking URI for API requests.

[rob-metalinkage]

The specification states ".. the profiles representations of resources conform to are unambiguously identified either by either a URI or a token. If the latter, it MUST be mappable to a URI within one particular client/server message pair."

There is no concept of "preferred token" in conneg-by-ap - its always specified by an unambguous mapping.

This is sort-of true "If URIs can be used everywhere else, then tokens need only fill the role of providing a nice-looking URI for API requests." - however more important than nice-looking is that existing APIs that use tokens to specify profiles can be made to conform to this specification by supporting a "list profiles" function that provides the URI mapping - a significant step forward in self-documentation of services - the motivation for the current committed implementors of conneg. So the subset of people include in "we" needs to include all the community that might use the spec - not a subset who might indeed not need one particular optional feature.

[RubenVerborgh]

I don’t think we should overstate the self-description. All it does is saying that a token T can be used instead of a URI U. That’s legacy compatibility, but no added value for description or otherwise. T does not carry more meaning than U (quite the contrary, because U has universal meaning and might be dereferenceable).

[nicholascar]

The original question of this Issue's been addressed, as @larsgsvensson says: the IETF document will contain text to register the target attribute profile for the Link header as follows:

When used in a Link header field, the "profile" attribute is a hint indicating which profile the resource representation retrieved by dereferencing the link conforms to. Note that this is only a hint; for example it does not override the "Content-Profile" header field of a HTTP response obtained by actually following the link. Multiple "profile" attributes on a single link value indicate that the resource representation conforms to multiple profiles.

Also, as @RubenVerborgh notes: with the merge of #1063, the token mechanism now no longer interferes with anything else.

This Issue's now been marked due-for-closing for quite some time and discussion here seems to have petered out. Any further discussion should be taken up in a new issue.