Re: [calsify] Artart last call review of draft-ietf-calext-ical-relations-09

[Michael Douglass <[e-mail]>]

On 2/6/22 16:54, Spencer Dawkins via Datatracker wrote:
> 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".
Will fix
>
> 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.

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

>
> 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.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify