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

[Bron Gondwana <[e-mail]>]

Sorry for the delay on this message, I was in transit to M3AAWG and didn't hit approve for a while.  Mike posted this days ago, but from an address which isn't on the list.

On Thu, Feb 17, 2022, at 08:30, Michael Douglass wrote:
> 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
>> 
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]