Subject: Re: [httpapi] linkset draft ready for next steps

From: Erik Wilde <[email-masked]>
Date: Sun, 4 Jul 2021 14:10:44 +0200

hello rich.

On 2021-06-08 16:17, Salz, Rich wrote:
> So I think that this is the plan we should follow.  Julian will post his comments (ideally this week, perhaps next) and the authors will respond and perhaps post a new draft. If there's disagreement or controversy, we'll repeat that cycle until issues are settled.  Once that's done, we'll issue a working group last call (WGLC) and proceed.

we just published a new version after resolving all open issues without 
any remaining disagreements. we think that we now are ready for the next 
step, and we're curious to see the result of the WGLC.

thanks a lot to julian for all his valuable and constructive feedback, 
it helped to improve the draft.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Julian Reschke <[email-masked]>
Date: Thu, 8 Jul 2021 16:15:32 +0200

Am 04.07.2021 um 14:10 schrieb Erik Wilde:
>> So I think that this is the plan we should follow.  Julian will post
>> his comments (ideally this week, perhaps next) and the authors will
>> respond and perhaps post a new draft. If there's disagreement or
>> controversy, we'll repeat that cycle until issues are settled.  Once
>> that's done, we'll issue a working group last call (WGLC) and proceed.
>
> ...

Here's some more...

The one-two-one mapping between link header field syntax and JSON makes
the JSON really complex. I understand that this is done for round-tripping.

There is however one case where I would argue that complexity could be
removed without major loss. See
<https://www.ietf.org/archive/id/draft-ietf-httpapi-linkset-03.html#section-4.2.4.2>
which is about mapping RFC 8187 syntax, which allows inclusion of
language tags. I'm not aware of this being used in practice (and I'm
author of that RFC). Dropping the language information from JSON would
simpliy the datamodel somewhat.

Best regards, Julian

---

From: Phil Archer <[email-masked]>
Date: Thu, 8 Jul 2021 14:35:30 +0000

Can I clarify your comment please Julian.

Are you suggesting that Linkset could drop support for multilingual titles on a given link? And does that apply to both the native HTTP Link header format and the JSON format, or just one? Such a move would remove complexity that may be little used. For better or worse, it seems that in the real world, a vanishingly small number of websites use content negotiation by language. The new W3C website design is not using it, for example, and is instead going for a {domain}/{lang}/{page} structure. So, yes, having a single link to a resource that is made available with language-based conneg is probably an edge case hanging on by its fingernails.

Even so, it is part of HTTP and so leaving it out might be problematic, process-wise if nothing else? Apologies if I've misunderstood your comment.

Phil

Phil Archer
Director, Web Solutions, GS1
https://www.gs1.org

Meet GS1 Digital Link Developers at
https://groups.google.com/forum/#!forum/gs1-digital-link-developers

https://philarcher.org
+44 (0)7887 767755
@philarcher1
Skype: philarcher

On 08 July 2021 15:16, httpapi wrote:
Am 04.07.2021 um 14:10 schrieb Erik Wilde:
> we just published a new version after resolving all open issues
> without any remaining disagreements. we think that we now are ready
> for the next step, and we're curious to see the result of the WGLC.
>

Here's some more...

The one-two-one mapping between link header field syntax and JSON makes the JSON really complex. I understand that this is done for round-tripping.

There is however one case where I would argue that complexity could be removed without major loss. See <https://www.ietf.org/archive/id/draft-ietf-httpapi-linkset-03.html#section-4.2.4.2>
which is about mapping RFC 8187 syntax, which allows inclusion of language tags. I'm not aware of this being used in practice (and I'm author of that RFC). Dropping the language information from JSON would simpliy the datamodel somewhat.

Best regards, Julian

--
httpapi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/httpapi

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.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 8 Jul 2021 17:11:46 +0200

> Even so, it is part of HTTP and so leaving it out might be problematic, process-wise if nothing else? Apologies if I've misunderstood your comment.

For now I was just considering the JSON format due to the complexity it
adds.

I can understand if feature parity has higher priority than terseness,
but wanted at least see some discussion.

Best regards, Julian

---

From: Phil Archer <[email-masked]>
Date: Thu, 29 Jul 2021 08:21:56 +0000

We need to come back to this discussion and come to a resolution before we can progress to last call (and thanks MNot for your comments today as well).

As indicated earlier, I don't have a strong opinion that we definitely should or definitely should not support multilingual labels in the JSON format. However, it does 'feel right' to me that the JSON serialization and the Web Linking serialization are equivalent in the information they can contain. Round tripping between formats is not a requirement but it never feels right to me to throw away data or functionality unless the gain is substantial.

When I created a JSON Linkset visualization tool [1] I included support for multilingual labels (and there's one in the sample used in the demo) without any difficulty.

So Julian and others, would you be OK with keeping this?

Phil

[1] https://github.com/gs1/linkset

Phil Archer

https://philarcher.org
+44 (0)7887 767755
@philarcher1
Skype: philarcher

On 08 July 2021 16:12, httpapi wrote:
> Even so, it is part of HTTP and so leaving it out might be problematic, process-wise if nothing else? Apologies if I've misunderstood your comment.

For now I was just considering the JSON format due to the complexity it adds.

I can understand if feature parity has higher priority than terseness, but wanted at least see some discussion.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Jul 2021 12:33:47 +0200

> [1] https://github.com/gs1/linkset

I have no problem keeping it. I just wanted to clarify, that I, in my
role as author of the spec that made things that complicated, wouldn't
object to dropping the complexity...

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Thu, 29 Jul 2021 12:47:45 +0200

hello julian.

On 2021-07-29 12:33, Julian Reschke wrote:
>> We need to come back to this discussion and come to a resolution 
>> before we can progress to last call (and thanks MNot for your comments 
>> today as well).
>> When I created a JSON Linkset visualization tool [1] I included 
>> support for multilingual labels (and there's one in the sample used in 
>> the demo) without any difficulty.

;-) that's good to hear! one of the goals of the spec was to align with 
the model of RFC 8288 without trying to change/improve it. i do agree 
than in hindsight, maybe the web linking model would look slightly 
different today and so would linksets as a result, but given that we 
have implementations already, i am glad to hear that we can keep the 
model as it is.

thanks and cheers,

dret.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 30 Jul 2021 07:26:45 +1000

See my comments - the problem is that the JSON format as described aligns with the model of the Link header, *not* the abstract model for links in 8288.

> On 29 Jul 2021, at 8:47 pm, Erik Wilde <[email-masked]> wrote:
> 
> hello julian.
> 
> ;-) that's good to hear! one of the goals of the spec was to align with the model of RFC 8288 without trying to change/improve it. i do agree than in hindsight, maybe the web linking model would look slightly different today and so would linksets as a result, but given that we have implementations already, i am glad to hear that we can keep the model as it is.
> 
> thanks and cheers,
> 
> dret.
> 
> -- 

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