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

[Michael Douglass <[e-mail]>]

I'm just headed out for a long weekend at my daughter's. I'll try to get 
something out this weekend.

Thanks - Mike

On 2/17/22 10:40, Francesca Palombini wrote:
>
> 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 <[e-mail]> on behalf of Michael Douglass 
> <[e-mail]>
> *Date: *Monday, 14 February 2022 at 23:02
> *To: *Keith Drage <drageke=[e-mail]>, 
> [e-mail] <[e-mail]>
> *Subject: *Re: [art] [calsify] Artart last call review of 
> draft-ietf-calext-ical-relations-09
>
>
> On 2/7/22 05:24, Keith Drage wrote:
> >
> > On 07/02/2022 03:31, Michael Douglass wrote:
> >>
> >> On 2/6/22 16:54, Spencer Dawkins via Datatracker wrote:
> >>> Reviewer: Spencer Dawkins
> >>> Review result: Ready with Nits
> >>>
> >>>
> >>> 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
> >>
> >>
> > 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.
>
>
> Are you saying that last sentence should be removed altogether?
>
>
> >
> > Keith
> >
> > _______________________________________________
> > art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/art
>
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art
>