Re: [calsify] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter

[Michael Douglass <[e-mail]>]

I agree with this proposal - and the mailing list approach suggested by 
Alexey

On 11/17/21 05:13, Bron Gondwana wrote:
> Hi - both JMAP and CALEXT working groups,
>
> I'm emailing both groups, because this proposal includes taking the 
> current jscontact work and moving it from JMAP to CALEXT where it will 
> be maintained on an ongoing basis - along with the icalendar, vcard 
> and jscalendar specs as well as the caldav and carddav protocols.  
> This new charter anticipates a long lived maintenance working group 
> for all the contacts, calendars, and related data formats.  The 
> reasons for taking on the VCARD and CardDAV work are pretty obvious:
>
>   * Both have *DAV protocols.
>   * Both have similar syntax model (VOBJECT)
>   * Could move maintenance of JSContact over from JMAP where it
>     doesn’t really fit either.
>   * Frequently implemented together.
>   * Both handled by CalConnect as well, maintain the relationship.
>   * Better than starting another group for contacts! We already have
>     enough groups.
>
> We also propose to close the 'calsify' mailing list and move all the 
> subscribers to a list called '[e-mail]' so that the mailing 
> list name matches the working group name, because this is an ongoing 
> source of confusion to new people.
>
> We have deliberately left the "out of scope" a little loose so that 
> things like tasks or even file synchronization (which is needed for 
> managed attachments in calendars among other things) might come into 
> scope - so long as it's related to the documents that this group 
> currently maintains and isn't better suited to another existing group, 
> then it's a candidate to be worked on in CALEXT.  That's hopefully a 
> good balance between too much charter lawyering for things we should 
> be working on, while not opening the door to do arbitrary stuff here.
>
> The CALEXT chairs and our two ADs (Francesca and Murray) would love 
> any feedback you have on this charter text over the next couple of 
> weeks before we formally propose this charter to the IESG. *Please 
> send feedback by December 1st (earlier is better so we can iterate)*
>
> Thanks,
>
> Bron.
>
> https://notes.ietf.org/calext-proposed-charter-2021 - pasted below
>
>
>     Charter Text:
>
> The CALEXT working group is chartered to maintain and extend the 
> specifications for formats and protocols related to calendaring and 
> contacts within the IETF, starting from the basis of:
>
>   * CalDAV (RFC 4791)
>   * iCalendar (RFC 5545)
>   * iTIP (RFC 5546)
>   * VCARD (RFC 6350)
>   * CardDAV (RFC 6352)
>   * JSCalendar (RFC 8984)
>   * JSContact (draft-ietf-jmap-jscontact)
>
> and the many existing extensions and companion documents to these.
>
> This working group is envisaged to be long-running, and deal with a 
> steady slow flow of changes. Experience has shown that these 
> specifications are still seeing significant need for updates, as new 
> use-cases are identified and user requirements change.
>
>
>       This working group will do the following:
>
>   * maintain existing standards and proposed standards, processing
>     errata and refreshing them as required
>   * evaluate and develop extensions to the existing standards to
>     provide for new use-cases where there is demand
>   * publish informative documents describing existing implementations
>     of non-standard extensions, where vendors have already shipped an
>     implementation and with which our protocols will need to interoperate
>
>
>       The working group will work under the following parameters:
>
>   * The extensions developed are expected to be backwards-compatible
>     with the existing standards. Incompatibilities must be identified,
>     minimized, and justified.
>   * Any extensions to icalendar or jscalendar must include a
>     representation in both formats, and define a robust mapping
>     between them.
>   * Any extensions to vcard or jscontact must include a representation
>     in both formats, and define a robust mapping between them.
>   * All calendar extensions must examine their impact on the iTIP
>     protocol (RFC 5546), and define any necessary extensions to iTIP
>     to accommodate such impact.
>
>
>       The working group will maintain relationships with other working
>       groups:
>
>   * HTTPBIS and HTTPAPI: when extending the CalDAV or CardDAV
>     protocols to ensure that changes are consistent with good http
>     practices.
>   * JMAP: when making updates to JSCalendar and JSContact to ensure
>     that the changes are compatible with the JMAP methods for managing
>     data in these formats.
>   * EXTRA, DMARC and EMAILCORE: for changes related to iTIP delivery
>     via email.
>   * Other working groups as appropriate, when their work interacts
>     with ours.
>
>
>       The following are out of scope for the working group:
>
>   * Any attempt to develop non-Gregorian calendar systems/calculations.
>   * Work which is in scope for any other ART area working group, and
>     better suited to that group.
>   * Work which is unrelated to anything that this group is currently
>     maintaining.
>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
> [e-mail]
>
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify