Subject: [art] Artart last call review of draft-ietf-calext-ical-relations-09

From: Spencer Dawkins via Datatracker <[email-masked]>
Date: Sun, 06 Feb 2022 13:54:47 -0800

Reviewer: Spencer Dawkins
Review result: Ready with Nits

Thank you for doing these new relation types. I can see how they would be very
helpful.

I also looked at the -09 diffs - thank you for making those changes. They do
improve the document.

I do have some nits and questions, but none rises to the level of an issue.
Please do the right thing.

In section 2 and in section 7, "it's" should be "its".

In section 6.1, I see

      In addition to the values defined here any value defined in
      [RFC8288] may be used.  However these uses SHOULD be documented in
      an RFC updating both [RFC5545] and [RFC8288]

I have two questions - why normative language at all for this? it's a
requirement for what people should do, not what the protocol should do.

and why SHOULD? It seems that if this is something that ought to happen, I
don't understand why allowing the possibility that it won't happen makes sense.

In section 8.2, I see

         linkparam      = ; the elements herein may appear in any order,
                          ; and the order is not significant.

                          (";" "VALUE" "=" ("REFERENCE" /
                                            "URI" /
                                            "TEXT"))
                          1*(";" linkrelparam)
                          (";" fmttypeparam)
                          (";" labelparam)
                          (";" langparam)
                          *(";" other-param)

I'm asking this out of ignorance - is it obvious what happens if one or more of
these elements appears twice? I'm guessing that it's not obvious, because the
order is not significant, so one can't know a priori what an implementation
would do. If that's the case, you might want to say MUST NOT appear more than
once, to avoid indeterminate behavior.  But if this would already be invalid,
that's fine.

---

From: Michael Douglass <[email-masked]>
Date: Sun, 6 Feb 2022 22:31:52 -0500

> In section 2 and in section 7, "it's" should be "its".
Will fix
> don't understand why allowing the possibility that it won't happen makes sense.

I was supposed to change this but managed to miss it. I believe the 
language should be something like:

--------- New ----------------

       In addition to the value defined here any link relation in the link
       registry defined in [RFC8288], or new link relations may be used.
       However these uses MUST be documented in an RFC updating [RFC5545].

------------------------------

I think this ensures:

a. We have the appropriate documentation specifying what it means in the 
calendaring context and

b. There's a link from 5545

> once, to avoid indeterminate behavior.  But if this would already be invalid,

I think this is damaged ABNF - we had a period of trying to produce 
better ABNF but it was inconsistent with the way it's defined in 5545.

I think there should be a 1* in front of the others

                           1*(";" linkrelparam)
                           1*(";" fmttypeparam)
                           1*(";" labelparam)
                           1*(";" langparam)

The 5545 way is just to add comments
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Keith Drage <[email-masked]>
Date: Mon, 7 Feb 2022 10:24:06 +0000

On 07/02/2022 03:31, Michael Douglass wrote:
> a. We have the appropriate documentation specifying what it means in 
> the calendaring context and
>
I have to agree with Spencer's original comment here. You should use the 
normative language for the protocol.

You define what you require here merely by having the IANA registry and 
making it Standards Action or Specification Required.

I'd also suggest that if a specification addition to the IANA registry 
is required to update this specification, then your forward 
compatibility rules are broken. Probably they are not, therefore the 
addition to the registry does not need to update this document when it 
becomes an RFC.

Keith

---

From: Michael Douglass <[email-masked]>
Date: Mon, 14 Feb 2022 17:02:04 -0500

On 2/7/22 05:24, Keith Drage wrote:
> I have to agree with Spencer's original comment here. You should use 
> the normative language for the protocol.
>
> You define what you require here merely by having the IANA registry 
> and making it Standards Action or Specification Required.
>

Are you saying that last sentence should be removed altogether?

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

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 17 Feb 2022 15:40:02 +0000

Spencer: thank you very much for this review! Good catches. Mike, I would agree that removing that sentence “MUST be documented in an RFC updating  [RFC5545].” makes sense. Note that the Update can still be added, if the wg considers it necessary, but maybe it does not need to be spelled out in this document. Would that answer your comment, Spencer?

Mike, Ben also pointed out that the ABNF is broken here – let’s get that fixed on the next version of the document. Other ballots can be found: https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ballot/

Thanks,
Francesca

From: art <[email-masked]> on behalf of Michael Douglass <[email-masked]>
Date: Monday, 14 February 2022 at 23:02
To: Keith Drage <drageke=[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [art] [calsify] Artart last call review of draft-ietf-calext-ical-relations-09