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.

?