Subject: [httpapi] should linkset update RFC 8288? looking for feedback

From: Erik Wilde <[email-masked]>
Date: Mon, 17 Jan 2022 17:16:41 -0800

happy 2022, httpapi people!

one question that came up during a last call review 
(https://github.com/ietf-wg-httpapi/linkset/issues/62; task 18) of the 
linkset draft was whether the specification should formally "update" RFC 
8288.

i discussed this question with my co-author and we came to the 
conclusion that you can probably argue either way. in the end the 
"right" answer may mostly depend on what IETF typically does when a spec 
does not change anything in an existing one, but adds to it.

we are fine either way, but wanted to get the group's (and most 
importantly, the chairs') feedback about this issue.

thanks a lot and kind regards,

dret.

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

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 18 Jan 2022 13:27:01 +1100

My response would be pretty firm "no".

As far as I can see, linkset only uses adds extensions, using existing extension points in the link specification.  That is not cause to insist on an "Updates/Updated by" relationship.  That should be reserved for occasions where the content of a document might need to be changed in some way that affects a conformant implementation.  For instance, if you redefined or clarified some aspect of how parameter handling works, that might be cause to update.

I know that this view is not uniform, but I tend to think that sparing use of these relations is a good policy.

On Tue, Jan 18, 2022, at 12:16, Erik Wilde wrote:
> httpapi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpapi

---

From: Erik Wilde <[email-masked]>
Date: Mon, 17 Jan 2022 18:34:18 -0800

hello martin.

thanks for voicing your opinion!

> As far as I can see, linkset only uses adds extensions, using existing extension points in the link specification.  That is not cause to insist on an "Updates/Updated by" relationship.  That should…

yes, thast was always my understanding. if you need to find the updating 
spec to correctly understand/implement the updated spec, then it clearly 
should be marked. that's not the case here.

> I know that this view is not uniform, but I tend to think that sparing use of these relations is a good policy.

let's see whether we get other opinions. i am definitely fine not doing 
the updating dance.

cheers,

dret.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Jan 2022 14:48:43 +1100

+1. 

> On 18 Jan 2022, at 1:27 pm, Martin Thomson <[email-masked]> wrote:
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Jan 2022 08:00:29 +0100

> I know that this view is not uniform, but I tend to think that sparing use of these relations is a good policy.

+1

Best regards, Julian

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jan 2022 12:56:38 +0000

>    happy 2022, httpapi people!

A low bar, but here's hoping it's better than its two predecessors.

Update is not the same as Obsoletes, so adding something can reasonably be seen as an update.  If the WG doesn't have strong consensus, we can push it to Francesca to decide.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 19 Jan 2022 09:08:24 +1100

> On 18 Jan 2022, at 11:56 pm, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> Update is not the same as Obsoletes, so adding something can reasonably be seen as an update.

Using that logic, every new HTTP header would  "update" HTTP. Which would quickly lead to an absurd outcome.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jan 2022 22:54:31 +0000

Shrug.

I didn't intend to express an opinion, just that the WG should decide.  Sorry if that wasn't clear.