[httpapi] Re: Link Hint 02 feedback

[Darrel Miller <[e-mail]>]

Herbert,

> we have asked whether HTTP API WG would be interested and received no helpful response

In the Google doc you referenced, you mentioned this email from me Re: [dispatch] HTTP profile negotiation -- implementation evidence (was: HTTP profile negotiation - httpapi?)<https://mailarchive.ietf.org/arch/msg/dispatch/5gj5RWakDt-XbbsYjtLtn84sHBM/>

I just want to reiterate that was an individual opinion without a chair hat.  If there is support from participants of the HTTPAPI working group to work on this effort, I as a chair would be fully supportive.

Darrel
________________________________
From: Herbert Van de Sompel <[e-mail]>
Sent: Thursday, February 27, 2025 6:44 AM
To: Mark Nottingham <mnot=[e-mail]>
Cc: Phil Archer <[e-mail]>; [e-mail] <[e-mail]>
Subject: [httpapi] Re: Link Hint 02 feedback

On Thu, Feb 27, 2025 at 2:31 AM Mark Nottingham <mnot=[e-mail]<mailto:[e-mail]>> wrote:
Hmm. RFC 6906 defines the profile link relation, but AFAIK there isn't any way to communicate this in HTTP. Since the scope of this effort is *HTTP* based hints, we should probably define how to do that first.

I think the options are:

1) Just use the Link header field
2) Put a parameter on the media type
3) Define a new field

(1) is problematic because it requires modelling all possible links as hints, and that adds complexity that we're trying to get away from. Web linking is great if you need to have integration between links expressed in content and headers (for example), but for protocol-level details (such as something you might use for lower-layer dispatch, like a media type) it really should be a primary protocol mechanism, not something buried down inside a generic mechanism like this. In particular you don't want to force someone to parse all of the links on a response just to get one bit of information out if it's on the critical path.

(2) is problematic IIRC because it's effectively usurping individual media types' ability to control their own name space (would have to check with the media type folks to be sure) and parameters are stripped/dropped by some software (still?).

That might just leave (3). I know that <https://datatracker.ietf.org/doc/html/draft-svensson-profiled-representations> started down this path; personally I'd go a bit further and a) define a Profile header rather than reusing Link, and b) making it a Client Hint (since we have that now).


I am involved in the Profile Negotiation I-D which, honestly, is in limbo because:
* It is unclear where the specification should occur, IETF or W3C:
- we have asked whether HTTP API WG would be interested and received no helpful response
- there exists a parallel W3C document that has a broader scope but, as it comes to the scope of the I-D, describes to a large extent the same approach be it more as an implementation guideline than a spec: https://www.w3.org/TR/dx-prof-conneg/
* my co-authors don't respond to my mails anymore; I assume they are discouraged
- for those interested, additional background about the Profile Negotiation I-D history is at https://docs.google.com/document/d/1WUGML4cfthRBKzMW729thjlCZjPWku__IjEjdNWq9pU/edit?usp=sharing

But, going back to Mark's response to Phil's mail:

* Indeed, the I-D chose to express the existence of profiles available for negotiation by means of the Link header (using the "alternate" link relation). The major motivation was reuse of an existing header rather than introducing a new one. Using the Link header, an approach is needed to express profiles for media types for which the "profile" attribute has not been defined. And landed on the "formats" Link Hint. But, since it is not clear how Link Hints need to be serialized in a Link header, that aspect of the I-D has been in limbo for a long time now.
* Using a dedicated Profile header (symmetrical to Accept-Profile), as suggested by Mark, would be an option but I think it would run into the same problem as the Link header approach: It would need to list available media-types and their associated profiles. The question then becomes which attribute to use to convey profile URIs: (a) "profile" for media types that have defined that attribute and another (e.g. "formats") for those that haven't? (b) another (e.g. "formats") in all cases, i.e. also when "profile" has been defined. Quite inelegant either way.
* Note, BTW, that for media types for which "profile" has been defined, negotiation using Accept also comes with challenges and led colleagues that work on JSON-LD to look at Profile Negotiation as a way out, see https://github.com/w3c/json-ld-syntax/issues/436

Cheers

Herbert



Cheers,


> On 26 Feb 2025, at 11:15 pm, Phil Archer <[e-mail]<mailto:[e-mail]>> wrote:
>
> Thanks very much for working on this, Mark. I can see the potential in GS1's implementation of RFC 9264 (Herbert and Erik W's work on Linksets).
>
> An issue that has been around for a long time is that a media type is often only half the story. An application will typically want content that is serialized as, say, application/json, but it wants JSON that uses a specific vocabulary/data model. A hint of 'profile', that takes a URI as value, would probably be sufficient for this? Then a service can offer links to the same data (I'm thinking product descriptions but could be anything), following  different data models, all of which are serialized as JSON.
>
> Phil
>
> ---
>
> Phil Archer
> Web Solutions Director, GS1
> https://www.gs1.org
>
> https://philarcher.org
> [phone]
> @philarcher.bsky.social
>
> -----Original Message-----
> From: Herbert Van de Sompel <[e-mail]<mailto:[e-mail]>>
> Sent: 26 February 2025 11:15
> To: Nottingham Mark <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [httpapi] Re: Link Hint 02 feedback
>
> Hi Mark
>
> Thanks for the helpful clarification.
>
> I’m totally ok with simplification too. As you indicate, it’s about “hints”.
>
> Greetings
>
> Herbert
>
>> On Feb 26, 2025, at 09:08, Mark Nottingham <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Hi Herbert,
>>
>> This draft is a transitional step away from using JSON as the base data model. What I'd like to do is to use a subset of JSON or Structured Fields data types, and then describe how to map them into another format. What I've done here is to start that process by removing the most complex structures (objects).
>>
>> It'd be helpful to know how people feel about this -- especially whether the constraint and loss of information is acceptable. Personally I'm OK with it, since 'hints' shouldn't be too detailed (IMO).
>>
>> Cheers,
>>
>>
>>> On 26 Feb 2025, at 6:53 pm, Herbert Van de Sompel <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>> hi all,
>>>
>>> I was happy to see the publication of a new version of the Link Hints I-D. I do want to share some feedback:
>>>
>>> (1) From the outset of this effort, I have failed to understand the motivation for making JSON the canonical serialization format. I assume that boat has sailed but think that the draft would benefit from some extra wording to make it more accessible to those who are more familiar with HTTP/HTML links:
>>>
>>> (*) Given there is no formal definition of the canonical JSON structure for Link Hints, a description of the opening example provided in Section 2 would be helpful for those less familiar with expressing links in JSON.
>>>
>>> (*) Since Appendix A describes how JSON Link Hints are mapped to links in the HTTP header, it would be helpful to represent the examples provided there in a verbose manner that aligns with the opening example of Section 2:
>>> - this would allow understanding where the rel="sample" comes from in
>>> both examples
>>> - this would allow understanding how the content of the second example relates to that of the Section 2 example. That is really not obvious to me, because the content of the second example is contained in square brackets that I can't seem to map to the opening example.
>>> - use of a more realistic/intuitive complex example might also help.
>>>
>>> (*) It might be nice to include an example/appendix regarding representation of Link Hints in (JSON) Link Sets.
>>>
>>> (2) Section 5.1 lists some reserved names. Should "anchor" and "title*" be included there? It looks like title* would not be allowed on the basis of the restricted character set for Link Hints but maybe being explicit could be helpful?
>>>
>>> Greetings
>>>
>>> Herbert
>>>
>>> --
>>> ==================
>>> Herbert Van de Sompel
>>> https://hvdsomp.info
>>> https://orcid.org/0000-0002-0715-6126
>>> --
>>> httpapi mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email
>>> to [e-mail]<mailto:[e-mail]>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>
> --
> httpapi mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>
> CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are  confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium).
> If you are not the addressee, or if this has been copied or sent to you in error, you must not use data herein for any purpose, you must delete it, and should inform the sender.
> GS1 disclaims liability for accuracy or completeness, and opinions expressed are those of the author alone.
> GS1 may monitor communications.
> Third party rights acknowledged.
> (c) 2020.

--
Mark Nottingham   https://www.mnot.net/

--
httpapi mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--
==================
Herbert Van de Sompel
https://hvdsomp.info
https://orcid.org/0000-0002-0715-6126