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

[Alvaro Retana <[e-mail]>]

Perfect!

I cleared.

Alvaro.

On January 21, 2022 at 5:08:44 AM, Francesca Palombini (
[e-mail]) 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 <[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]