Re: [calsify] WG Review: Calendaring Extensions (calext)

I strongly support this move but see below for a couple of comments...

On 2/4/22 14:18, The IESG wrote:
> The Calendaring Extensions (calext) WG in the Applications and Real-Time Area
> of the IETF is undergoing rechartering. The IESG has not made any
> determination yet. The following draft charter was submitted, and is provided
> for informational purposes only. Please send your comments to the IESG
> mailing list (iesg@ietf.org) by 2022-02-14.
>
> Calendaring Extensions (calext)
> -----------------------------------------------------------------------
> Current status: Active WG
>
> Chairs:
>    Daniel Migault <daniel.migault@ericsson.com>
>    Bron Gondwana <brong@fastmailteam.com>
>
> Assigned Area Director:
>    Francesca Palombini <francesca.palombini@ericsson.com>
>
> Applications and Real-Time Area Directors:
>    Murray Kucherawy <superuser@gmail.com>
>    Francesca Palombini <francesca.palombini@ericsson.com>
>
> Mailing list:
>    Address: calsify@ietf.org
>    To subscribe: http://www.ietf.org/mailman/listinfo/calsify
>    Archive: https://mailarchive.ietf.org/arch/browse/calsify/
>
> Group page: https://datatracker.ietf.org/group/calext/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-calext/
>
> 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)
> - iMIP (RFC 6047)
> - 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.
Do we need "slow"? "a steady flow" seems better - it might pick up...
>
> 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 - generate
> documents describing existing vendor extensions which are in common usage,
> and likely to be encountered in the wild.
>
> 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 2 sentences

The extensions developed are expected to be backwards-compatible with the
existing standards. Incompatibilities must be identified, minimized, and
justified.

are incompatible.

"are expected to be backwards-compatible with the existing standards"

maybe should be something like

"should be, where possible, backwards-compatible with the existing 
standards"

>
> 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. - TZDIST
> and SEDATE for date, time, and timezone related issues. - Other IETF working
> groups as appropriate, when their work interacts with ours. - Other standards
> organisations like CalConnect and M3AAWG that are doing work in the same
> fields.
>
> 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.
>
> Milestones:
>
>    Jan 2022 - Submit Subscription Upgrade document to IESG for publication
>
>    Jan 2022 - Submit task draft to IESG
>
>    Apr 2022 - Submit JSCalendar mapping document to IESG for publication
>
>    Apr 2022 - Submit JSON Contact document to IESG
>
>    Jun 2022 - Submit vpoll document to IESG for publication
>
>    Jun 2022 - Submit Serverside Subscription draft to IESG for publication
>
>    Jul 2022 - Submit calendar series document to IESG for publication
>
>
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify