Subject: [calsify] Alvaro Retana's Block on charter-ietf-calext-01-00: (with BLOCK and COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 18 Jan 2022 05:32:04 -0800

Alvaro Retana has entered the following ballot position for
charter-ietf-calext-01-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-calext/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

   - publish informative documents describing existing vendor extensions
     which did not come through the IETF consensus process, but are
     nonetheless in common usage and likely to be encountered in the wild.

I understand the intent, but all IETF documents require consensus (rfc8789).
Publishing a vendor extension without consensus should be done through the ISE.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please help me understand how JSContact fits into this charter.  It confuses me
because it is a draft that belongs to a different WG, which also contradicts
the statement that "work which is in scope for any other ART area working
group" is out of scope.  It may be premature to list draft-ietf-jmap-jscontact
as part of the base documents.

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 19 Jan 2022 11:01:14 +1100

> https://datatracker.ietf.org/doc/charter-ietf-calext/

The idea is to publish as informative - with consensus that this matches what IETF members have seen in the wild.  Even if they wound up published via ISE, the working group would work with them, since we have to work around them because that's what's actually out there.

This is based on taking on VCARD into this group, which brings jscontact into scope as well.  We decided to put jscontact in JMAP despite having done jscalendar (which is the related format for calendar events) here in CALEXT.  I'm a co-chair on both working groups, and have discussed this move with the chairs of both working groups as well as the authors - and it was discussed at last IETF in both groups as well.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 19 Jan 2022 08:38:34 -0800

On January 18, 2022 at 7:01:39 PM, Bron Gondwana wrote:

Bron:

Hi!

...
> > I understand the intent, but all IETF documents require consensus
> > (rfc8789).  Publishing a vendor extension without consensus should be
> > done through the ISE.
>
> The idea is to publish as informative - with consensus that this matches
> what IETF members have seen in the wild. Even if they wound up published
> via ISE, the working group would work with them, since we have to work
> around them because that's what's actually out there.

I understand.

I don't think is correct to hint at publishing IETF stream documents
without consensus -- even if that is not the intent.  Perhaps the
bullet could be updated to something like this:

   - publish documents describing existing vendor extensions that are
     in common usage...

Does that work?

Thanks!

Alvaro.

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 21 Jan 2022 10:27:26 +1100

>    - publish documents describing existing vendor extensions that are

Yes, I'm happy with that.  I'll update the text at https://notes.ietf.org/calext-proposed-charter-2021

Cheers,

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 21 Jan 2022 10:34:53 +1100

> https://datatracker.ietf.org/doc/charter-ietf-calext/

I believe the following change satisfies your block.  A replacement of that point with:

*- generate documents describing existing vendor extensions which are in common usage, and likely to be encountered in the wild.*

Francesca: are you able to update the proposed charter text and re-ballot it with this fix?  Thanks.

I believe this explanation for the history answers your comment:

*Originally there wasn't a good home for JSContact and so we originally placed it in JMAP rather than CALEXT because VCARD and related contacts specs were not in scope for CALEXT.**
*
*
*
*With this charter update bringing VCARD into scope for CALEXT, it seems more natural for JSContact to come to CALEXT as well, where ongoing maintenance on the contacts data model can be performed in conjunction with VCARD (for example: adding a pronouns property).*

Regards,

Bron.

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 21 Jan 2022 10:08:41 +0000

Done: v-01-01 is up. (Note that this was moved to the next telechat so it is on the agenda for the 2022-02-03 telechat).

Francesca

From: iesg <[email-masked]> on behalf of Bron Gondwana <[email-masked]>
Date: Friday, 21 January 2022 at 00:35
To: Alvaro Retana <[email-masked]>, The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: Alvaro Retana's Block on charter-ietf-calext-01-00: (with BLOCK and COMMENT)

- generate documents describing existing vendor extensions which are in common usage, and likely to be encountered in the wild.

Originally there wasn't a good home for JSContact and so we originally placed it in JMAP rather than CALEXT because VCARD and related contacts specs were not in scope for CALEXT.

With this charter update bringing VCARD into scope for CALEXT, it seems more natural for JSContact to come to CALEXT as well, where ongoing maintenance on the contacts data model can be performed in conjunction with VCARD (for example: adding a pronouns property).

Regards,

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 21 Jan 2022 21:09:22 +1100

Excellent, thanks for that.

Bron

On Fri, Jan 21, 2022, at 21:08, Francesca Palombini wrote:
> *From: *iesg <[email-masked]> on behalf of Bron Gondwana <[email-masked]>
> *Date: *Friday, 21 January 2022 at 00:35
> *To: *Alvaro Retana <[email-masked]>, The IESG <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
> *Subject: *Re: Alvaro Retana's Block on charter-ietf-calext-01-00: (with BLOCK and COMMENT)
>  
>  
> *Originally there wasn't a good home for JSContact and so we originally placed it in JMAP rather than CALEXT because VCARD and related contacts specs were not in scope for CALEXT.*
>

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 21 Jan 2022 21:37:29 +0000

Perfect!

I cleared.

Alvaro.

On January 21, 2022 at 5:08:44 AM, Francesca Palombini (
[email-masked]) wrote:

Done: v-01-01 is up. (Note that this was moved to the next telechat so it
is on the agenda for the 2022-02-03 telechat).

Francesca

*From: *iesg <[email-masked]> on behalf of Bron Gondwana <
[email-masked]>
*Date: *Friday, 21 January 2022 at 00:35
*To: *Alvaro Retana <[email-masked]>, The IESG <[email-masked]>
*Cc: [email-masked] <[email-masked]>, [email-masked] <
[email-masked]>
*Subject: *Re: Alvaro Retana's Block on charter-ietf-calext-01-00: (with
BLOCK and COMMENT)

BLOCK:

Publishing a vendor extension without consensus should be done through the
ISE.

I believe the following change satisfies your block.  A replacement of that
point with:

*- generate documents describing existing vendor extensions which are in
common usage, and likely to be encountered in the wild.*

Francesca: are you able to update the proposed charter text and re-ballot
it with this fix?  Thanks.

COMMENT:

Please help me understand how JSContact fits into this charter.  It
confuses me

group" is out of scope.  It may be premature to list
draft-ietf-jmap-jscontact

*Originally there wasn't a good home for JSContact and so we originally
placed it in JMAP rather than CALEXT because VCARD and related contacts
specs were not in scope for CALEXT.*

*With this charter update bringing VCARD into scope for CALEXT, it seems
more natural for JSContact to come to CALEXT as well, where ongoing
maintenance on the contacts data model can be performed in conjunction with
VCARD (for example: adding a pronouns property).*

Regards,

Bron.

--

  [email-masked]