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

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 17 Nov 2021 21:13:48 +1100

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 [email-masked]' 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
  [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Nov 2021 10:28:52 +0000

Hi Bron,

> On 17 Nov 2021, at 10:15, Bron Gondwana <[email-masked]> wrote:
> 

May I suggest that instead of the above you keep [email-masked] as an alias for [email-masked], as it existed for quite a long time. The rest of the mailing list change proposal makes sense.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Nov 2021 10:33:48 +0000

Hi all,

The charter looks fine to me. It is a bit broad in scope, but if IESG is fine with it, than that is fine with me :-).

Best Regards,
Alexey

---

From: Ken Murchison <[email-masked]>
Date: Wed, 17 Nov 2021 07:15:38 -0500

The charter text looks sensible and clear to me.  Do we want to add iMIP 
(RFC 6047) to the list of basis specs?

On 11/17/21 5:13 AM, Bron Gondwana wrote:
> 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:
>
> We also propose to close the 'calsify' mailing list and move all the 
> subscribers to a list called [email-masked]' 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.
>
> 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)
> 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.
>
>
>   * 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 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.
>
>
>   * 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.
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Nov 2021 15:11:16 +0000

I think the broad scope actually fits the current state of the WG as it is now. More specifically, the working group is very consensual in picking its topics and we need such flexibility to synch with Calconnect. I believe that raising charter discussions for any topic will result in a less active WG. 
Of course the scope might be revisited in the future when calext will have too many paralleled discussions. I guess we still need a few months to get there 😉. But yes that is something we have in mind, that we may need to revisit the charter at some points.

Yours, 
Daniel

-----Original Message-----
From: calsify <[email-masked]> On Behalf Of Alexey Melnikov
Sent: Wednesday, November 17, 2021 5:34 AM
To: Bron Gondwana <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [calsify] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter

Hi all,

Best Regards,
Alexey

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 18 Nov 2021 07:10:09 +1100

Thanks Ken - added to the copy in HedgeDoc.

Bron.

On Wed, Nov 17, 2021, at 23:15, Ken Murchison wrote:
> The charter text looks sensible and clear to me.  Do we want to add iMIP (RFC 6047) to the list of basis specs?
> 
> 
>

---

From: Michael Douglass <[email-masked]>
Date: Thu, 18 Nov 2021 01:08:40 -0500

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

---

From: Ronald Tse <[email-masked]>
Date: Thu, 18 Nov 2021 08:53:56 +0000

I agree with the proposal as well. This gives a natural home to drafts like vobject which binds the calendars and contacts to a single data model, also led by CalConnect.

Preferably the constraints under "The working group will work under the following parameters” can be relaxed as they seem rather restrictive. They are good guidance notes but I don’t see why those constraints are normatively "necessary”.

Under "The working group will maintain relationships with other working groups” I would propose adding “CalConnect” as a place to collaborate with, too.

_____________________________________

Ronald Tse
Ribose Inc.

+=========================================================+
This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein.  If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.
+=========================================================+

On 18 Nov 2021, at 2:08 PM, Michael Douglass <[email-masked]<mailto:[email-masked]>> wrote:

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

We also propose to close the 'calsify' mailing list and move all the subscribers to a list called [email-masked]<mailto:[email-masked]>' so that the mailing list name matches the working group name, because this is an ongoing source of confusion to new people.

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.

  *   CalDAV (RFC 4791)
  *   iCalendar (RFC 5545)
  *   iTIP (RFC 5546)
  *   VCARD (RFC 6350)
  *   CardDAV (RFC 6352)
  *   JSCalendar (RFC 8984)

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]<mailto:[email-masked]>

_______________________________________________
calsify mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/calsify

_______________________________________________
calsify mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/calsify

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Nov 2021 15:52:45 +1100

> Preferably the constraints under "The working group will work under the following parameters” can be relaxed as they seem rather restrictive. They are good guidance notes but I don’t see why those…

I would be happy to trim it back.  The IETF doesn't like charters which grant too much leeway to willy-nilly avoid backwards compatibility.  Not that we would, since all the people currently writing drafts run products that need to interoperate with the existing world - but it helps turn away proposed new work that wants to break everything if you can point to the charter and say "we promised not to do that".

> Under "The working group will maintain relationships with other working groups” I would propose adding “CalConnect” as a place to collaborate with, too.

Yep - for sure.  I thought about that - just wanted to avoid the complexity of setting up a formal liaison, so I'm not sure how the IESG will feel about listing a collaborator for which there's no formal arrangement.  Happy to put CalConnect in there and run it up the flagpole and see.

Bron.