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

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

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."

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.

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?

@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?

👍 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.

+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

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

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

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

@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.

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"

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

@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.

?

Yes, fine by me, thank you!

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

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.

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 ProfileNegotiation/I-D-Profile-Negotiation#12 and ProfileNegotiation/I-D-Profile-Negotiation#8.
@nicholascar, @rob-metalinkage, @RubenVerborgh: What do you think?
And ACTION-290

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

@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?

@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?

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.

@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).

@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.