Subject: [Last-Call] Feedback on draft-ietf-calext-ical-relations

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Oct 2021 13:17:42 +1100

I was recently made aware of this draft.

A specification should not opt itself into the use of the link relation registry unless it's actually using link relations -- otherwise, there's going to be weird overlaps / misalignments. 

From a brief glance, this spec is *not* defining itself as a serialisation of links in the 8288 sense -- e.g., there's no link context, no mention of target attributes, etc. Basically, it needs to describe itself in terms of the model defined in [Section 2](https://www.rfc-editor.org/rfc/rfc8288.html#section-2).

Two alternative paths forward would address this concern:

1) Define this as a serialisation of 8288 links
2) Use a separate registry

Cheers,

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

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 28 Oct 2021 12:40:23 +0000

Thanks Mark for this feedback! I am cc’ing the calext working group for visibility.

Francesca

From: iesg <[email-masked]> on behalf of Mark Nottingham <[email-masked]>
Date: Wednesday, 27 October 2021 at 04:18
To: [email-masked] <[email-masked]>, The IESG <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Feedback on draft-ietf-calext-ical-relations
I was recently made aware of this draft.

>From a brief glance, this spec is *not* defining itself as a serialisation of links in the 8288 sense -- e.g., there's no link context, no mention of target attributes, etc. Basically, it needs to describe itself in terms of the model defined in [Section 2](https://protect2.fireeye.com/v1/url?k=340340b7-6b987855-3403002c-86073b36ea28-006bdccbf3349611&q=1&e=0f17a05e-7881-4187-8983-e29e01164a21&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8288.html%23section-2).

Cheers,

--
Mark Nottingham   https://protect2.fireeye.com/v1/url?k=f1cea606-ae559ee4-f1cee69d-86073b36ea28-1225c525f9ca44ba&q=1&e=0f17a05e-7881-4187-8983-e29e01164a21&u=https%3A%2F%2Fwww.mnot.net%2F

---

From: Michael Douglass <[email-masked]>
Date: Thu, 28 Oct 2021 12:37:50 -0400

On 10/28/21 08:40, Francesca Palombini wrote:
> *From: *iesg <[email-masked]> on behalf of Mark Nottingham 
> <[email-masked]>
> *Date: *Wednesday, 27 October 2021 at 04:18
> *To: [email-masked] <[email-masked]>, The IESG 
> <[email-masked]>, [email-masked] 
> <[email-masked]>
> *Cc: [email-masked] <[email-masked]>
> *Subject: *Feedback on draft-ietf-calext-ical-relations
>
> A specification should not opt itself into the use of the link 
> relation registry unless it's actually using link relations -- 
> otherwise, there's going to be weird overlaps / misalignments.
>
> >From a brief glance, this spec is *not* defining itself as a 
> serialisation of links in the 8288 sense -- e.g., there's no link 
> context, no mention of target attributes, etc. Basically, it needs to 
> describe itself in terms of the model defined in [Section 
> 2](https://protect2.fireeye.com/v1/url?k=340340b7-6b987855-3403002c-86073b36ea28-006bdccbf3349611&q=1&e=0f17a05e-7881-4187-8983-e29e01164a21&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8288.html%23section-2 
> <https://protect2.fireeye.com/v1/url?k=340340b7-6b987855-3403002c-86073b36ea28-006bdccbf3349611&q=1&e=0f17a05e-7881-4187-8983-e29e01164a21&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8288.html%23section-2>).
>
A third path might be to specify how it differs while trying to come 
closer to 1.

I think having 2 registries defining essentially the same concept would 
be more confusing and lead to more misalignments. At least this way we 
only define it once.

I accept the point on context and attributes. I think we can deal with 
that - e.g. context is the referencing entity and define a mapping of 
existing parameters to the 8288 defined attributes (e.g. "title"->"label")

RFC 8288 in Appendix A specifies how it differs from 2 other linking 
methods.

I'd also note that jsCalendar - RFC8984 - also references the registry 
in 8288

I'll try and come up with some changes today.

>
> Cheers,
>
> --
> Mark Nottingham 
> https://protect2.fireeye.com/v1/url?k=f1cea606-ae559ee4-f1cee69d-86073b36ea28-1225c525f9ca44ba&q=1&e=0f17a05e-7881-4187-8983-e29e01164a21&u=https%3A%2F%2Fwww.mnot.net%2F 
> <https://protect2.fireeye.com/v1/url?k=f1cea606-ae559ee4-f1cee69d-86073b36ea28-1225c525f9ca44ba&q=1&e=0f17a05e-7881-4187-8983-e29e01164a21&u=https%3A%2F%2Fwww.mnot.net%2F>
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 30 Oct 2021 11:39:01 +1100

> On 29 Oct 2021, at 3:37 am, Michael Douglass <[email-masked]> wrote:
> 
> A third path might be to specify how it differs while trying to come closer to 1.
> 
> I think having 2 registries defining essentially the same concept would be more confusing and lead to more misalignments. At least this way we only define it once.
> 
> I accept the point on context and attributes. I think we can deal with that - e.g. context is the referencing entity and define a mapping of existing parameters to the 8288 defined attributes (e.g. "title"->"label")

That sounds like you're defining a serialisation of 8288 links.

> RFC 8288 in Appendix A specifies how it differs from 2 other linking methods.

That's noting how different _serialisations_ work -- they are different ways to express the same data model.

Another question to ask is whether it makes sense for the link types currently registered to show up here, and vice versa (whether the ones you propose to register make sense in HTML, Atom, Link headers, etc.). That might help guide the answer.

Cheers,