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

[Bron Gondwana <[e-mail]>]

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]