[httpapi] Re: Link Hint 02 feedback

[Herbert Van de Sompel <[e-mail]>]

On Sat, Mar 1, 2025 at 6:22 PM Darrel Miller <[e-mail]> wrote:

> 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.
>
>
Thanks for the clarification, Darrel! I corrected the Google doc
accordingly.

Greetings

Herbert





> 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]> 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]> 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]>
> > Sent: 26 February 2025 11:15
> > To: Nottingham Mark <[e-mail]>
> > Cc: [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]> 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]>
> 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] To unsubscribe send an email
> >>> to [e-mail]
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >
> > --
> > httpapi mailing list -- [e-mail] To unsubscribe send an email
> to [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]
> To unsubscribe send an email to [e-mail]
>
>
>
> --
> ==================
> Herbert Van de Sompel
> https://hvdsomp.info
> https://orcid.org/0000-0002-0715-6126
>


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