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

Michael Douglass <mikeadouglass@xxxxxxxxx> · Thu, 28 Oct 2021 12:37:50 -0400



    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@xxxxxxxx> on behalf of Mark Nottingham
              <mnot@xxxxxxxx>

              Date: Wednesday, 27 October 2021 at 04:18

              To: last-call@xxxxxxxx <last-call@xxxxxxxx>,
              The IESG <iesg@xxxxxxxx>,
              draft-ietf-calext-ical-relations@xxxxxxxx
              <draft-ietf-calext-ical-relations@xxxxxxxx>

              Cc: calext-chairs@xxxxxxxx
              <calext-chairs@xxxxxxxx>

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

            
            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
        
      
      _______________________________________________
calsify mailing list
calsify@xxxxxxxx
https://www.ietf.org/mailman/listinfo/calsify

    
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call