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

[Francesca Palombini <[e-mail]>]

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 <[e-mail]> on behalf of Bron Gondwana <[e-mail]>
Date: Friday, 21 January 2022 at 00:35
To: Alvaro Retana <[e-mail]>om>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>rg>, [e-mail] <[e-mail]>
Subject: Re: Alvaro Retana's Block on charter-ietf-calext-01-00: (with BLOCK and COMMENT)


On Wed, Jan 19, 2022, at 00:32, Alvaro Retana via Datatracker wrote:
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.

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

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.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]