Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Registration of target attribute "profile" for the Link-Header #501

Open
larsgsvensson opened this issue Oct 26, 2018 · 28 comments

Comments

@larsgsvensson
Copy link
Contributor

commented Oct 26, 2018

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

larsgsvensson added a commit that referenced this issue Oct 26, 2018
Update index.html
Added references to issues #500 and #501
@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

@larsgsvensson

This comment has been minimized.

Copy link
Contributor Author

commented Oct 26, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 29, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 29, 2018

@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

This comment has been minimized.

Copy link

commented Nov 8, 2018

👍 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

This comment has been minimized.

Copy link
Member

commented Dec 19, 2018

+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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 5, 2019

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 added a commit to ProfileNegotiation/I-D-Profile-Negotiation that referenced this issue Mar 30, 2019
Update I-D-Profile-Negotiation.xml
Added text to say that hierarchies of profiles etc. are out of scope
Added/edited text about the Link header "profile" attribute (addressing w3c/dxwg#501 and #8)
Cleaned up references to use the RFC citation libraries as much as possible
Moved two paragraphs from the intro to 4.1 and 3.2 (addressing #5)
Further minor fixes...

@larsgsvensson larsgsvensson moved this from To do to In progress in Content Negotiation by Profile Apr 3, 2019

@larsgsvensson larsgsvensson self-assigned this Apr 3, 2019

@larsgsvensson

This comment has been minimized.

Copy link
Contributor Author

commented Apr 3, 2019

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

@larsgsvensson

This comment has been minimized.

@dret

This comment has been minimized.

Copy link
Member

commented Jun 20, 2019

@hvdsomp

This comment has been minimized.

Copy link

commented Jun 20, 2019

@larsgsvensson

This comment has been minimized.

Copy link
Contributor Author

commented Jul 1, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 19, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 19, 2019

@hvdsomp

This comment has been minimized.

Copy link

commented Aug 19, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 19, 2019

@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

This comment has been minimized.

Copy link

commented Aug 27, 2019

Yes, fine by me, thank you!

@hvdsomp

This comment has been minimized.

Copy link

commented Aug 28, 2019

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

@larsgsvensson

This comment has been minimized.

Copy link
Contributor Author

commented Aug 28, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 30, 2019

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

@RubenVerborgh

This comment has been minimized.

Copy link
Member

commented Aug 30, 2019

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

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Aug 31, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 1, 2019

@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

This comment has been minimized.

Copy link

commented Sep 2, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 2, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 2, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
7 participants
You can’t perform that action at this time.