Re: [calsify] Feedback on draft-ietf-calext-ical-relations

On 10/28/21 08:40, Francesca Palombini wrote:
>
> Thanks Mark for this feedback! I am cc’ing the calext working group 
> for visibility.
>
> Francesca
>
> *From: *iesg <iesg-bounces@ietf.org> on behalf of Mark Nottingham 
> <mnot@mnot.net>
> *Date: *Wednesday, 27 October 2021 at 04:18
> *To: *last-call@ietf.org <last-call@ietf.org>, The IESG 
> <iesg@ietf.org>, draft-ietf-calext-ical-relations@ietf.org 
> <draft-ietf-calext-ical-relations@ietf.org>
> *Cc: *calext-chairs@ietf.org <calext-chairs@ietf.org>
> *Subject: *Feedback on draft-ietf-calext-ical-relations
>
> 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://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>).
>
> Two alternative paths forward would address this concern:
>
> 1) Define this as a serialisation of 8288 links
> 2) Use a separate registry
>
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
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify