[calsify] Éric Vyncke's Discuss on draft-ietf-calext-jscontact-09: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-calext-jscontact-09: Discuss

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


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address: do not panic),
some non-blocking COMMENT points (but replies would be appreciated even if only
for my own education), and some nits.

Special thanks to Daniel Migault for the shepherd's detailed write-up including
the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Charter compliance

The CALEXT charter contains `Any extensions to vcard or jscontact must include
a representation in both formats, and define a robust mapping between them`. It
is unclear to me what is the actual meaning:

1) the mapping is required between vcard and jscontact (as JScontact is
presented in this I-D as an alternative to vCARD) or

2) the mapping is required only between jscontact versions/extensions ?
(respectively for vCARD)

If this is the former, then I was unable to find any "robust mapping" between
vCARD and JSContact in this document, or is it in another document?

If this is the latter, then I am removing this DISCUSS point.

Happy to discuss this with the CALEXT chairs and responsible AD.

## Sections 2.4.1, 2.6.1, 2.6.2, ...

Please do not use URL with ftp: or http: (I appreciate that this is not a
DISCUSS criteria, but I want to be sure that this issue is addressed as it is
trivial to fix).


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


# COMMENTS (non blocking)

## Why not YANG ?

Is there a reason why YANG was not used as the data model language ? AFAIK,
YANG data models can easily be serialised in JSON.

## Section 1.4

`A[B] - A JSON object where the keys are all of type A, and the values are all
of type B.` isn't there a swap between A and B in the explanation ?

## Section 1.7

`Implementors are RECOMMENDED to always support the latest version` but what
about backward compatibility ? Any guidance to be offered ?

## Section 1.9.1

I share Roman's issue about the use of a FQDN as a vendor prefix, there should
be some text enforcing the uniqueness of the property name (some vendor
organisations are so broad that one part is unaware of extension done by
another part). Even if this is kind of obvious, it is worth writing.

Sorry, cannot parse `The following all are valid examples of vendor-specific
properties`

## Section 2.2.1

Is the extra white space are meaningful in the example, then please provide
some text whether those whitespace can be removed.

## Section 2.3.3

Unsure whether "tel:[phone]" is a typical example phone number (even if
the numerical progression is a big hint).

# NITS (non blocking / cosmetic)

## Section 2.1.3 and 2.1.10

Perhaps using a date in this millennium ? ;-)