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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

** Section 1.9.1.
   The vendor-specific prefix SHOULD be a domain name under control of
   the service or application that sets the property, but it need not
   resolve in the Domain Name System [RFC1034] and [RFC1035].

How are vendor-specific prefixes intended to avoid collision if there is no
mandatory, collision free algorithm to avoid it?

** Thank you for the thoughtful and detailed guidance to the designated expert
with an eye towards long term flexible and extensibility in the ecosystem.

I see two inconsistencies in the registration guidance.

-- “Intended usage” field changes the registration behavior:

(a) Section 4.3 says:
   This registry follows the Expert Review process ([RFC8126],
   Section 4.5).

(b) Section 4.3 says:
   If the "Intended Usage" field is common, sufficient
   documentation is required to enable interoperability.  Preliminary
   community review for this registry is optional but strongly
   encouraged.

(c) Section 4.3.3 says:
   For a common-use registration, the DE is
   expected to confirm that suitable documentation, as described in
   Section 4.6 of [RFC8126], is available to ensure interoperability.

Text-(a) establishes a DE registration policy.  However, the subsequent text in
(b) and (c) is effectively saying that the registry has different registration
practices depending on the value of the “intended usage” field.  If “intended
usage” = “common”, then the registration policy is “Specification Required”
(where a DE review is required, and a stable reference is needed).  It isn’t
uncommon for a collection of code points in a single registry to have different
registration practices (e.g.,
https://www.iana.org/assignments/cose/cose.xhtml#key-common-parameters).  Why
not be explicit here?

-- @version/Table 6.

Section 1.7.2. says:
  If Expert Review or the IETF working group decides that a new major JSContact
  version is required, a new standard RFC document MUST be published. Such an
  RFC document MUST specify all changes to the former JSContact version. An RFC
  document is not required to change the minor JSContact version.

Doesn’t this imply that registration policy of this subregistry is:
Specification Required for new minor versions; and major versions are Standards
Action (per Section 4.9 of RFC8126) + Expert Review?


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

Thank you to Derek Atkins for the SECDIR review.

** Section 1.7.2
   If Expert Review or the IETF working group decides that a new major
   JSContact version is required, a new standard RFC document MUST be
   published.  Such an RFC document MUST specify all changes to the
   former JSContact version.  An RFC document is not required to change
   the minor JSContact version.

-- Is “new standard RFC document” the same as “new standards-track or BCP RFC
document” (i.e., per Section 4.9 of RFC8126)?

-- Is this decision of the Expert Reviewer envisioned after CALEXT closes? 
Could there be a situation where the Expert Reviewer and the WG disagree?

** Section 1.8
   If a JSContact object is valid,
   implementations MUST preserve all its properties.

What does “preserve all … properties” mean in this context?  This section seems
to be about validating of the document.  Is this the same as the text is
Section 1.8.2?

** Section 1.8.2.

(a)

   Implementations may encounter JSContact data where a property name is
   unknown to that implementation, but the name adheres to the
   restrictions of an IANA-registered property.

(b)
   Implementations
   that create or update JSContact data MUST only set IANA-registered
   properties or vendor-specific properties,

(c) ... but MUST preserve any
     already existing unknown properties.

Per (c), what are these properties are being noted that aren’t those defined in
(a), which is covered with the behavior described in (b).

** Section 1.9.  Editorial.
   Typically, sending a short description to the IETF working
   group mailing list is enough for Expert Review to make a decision.

Recommend dropping this sentence.  There appears to be significant nuance in
Section 4’s registration practices.  Instead of re-stating, the reference here
works.

** Section 1.9.1
   They MUST NOT reject the
   property value as invalid, unless they are in control of the vendor-
   specific property.

What does it mean to “control” the vendor-specific property?

** Section 2.2.2.
      This
      specification does not mandate how to do this but recommends the
      following: If at least one of two adjacent name components is of
      type separator then implementations SHOULD join their values
      without any additional character.

This mixing of lower-case RFC2119 words which claims that there is no normative
guidance, followed by a (lower-case) recommendation that has normative guidance
requires refinement.

** Section 2.3.2. Editorial.
     This SHOULD be the canonical service name including
      capitalization.

I don’t have better language.  However, I’m unsure what makes something
“canonical” in naming the service.  Consider if that particular word is needed.

** Section 23.  Figure 23.  The examples here are clear.  Is serving .ics or
.ifb over FTP common?  Consider replacing this with a protocol which provides
confidentiality and integrity.

** Section 2.5.1.  Editorial. Per timeZone, consider if the IANA Time Zone
Database should be made a normative reference.

** Section 2.6.1.  Additional flexibility in cryptoKeys seems like it would
helpful.  For consideration:

-- Supporting a “kind” property to allow specific typing of a public key vs.
certificate, or even supporting a shared symmetric secret?

-- Supporting @context here?

-- Is it possible associate a given cryptoKey with a particular email address?

-- Inline support for a certificate or symmetric key.  It could be as simple as
reminding the readers of the data:// scheme (RFC3986) with text or an example;
or a native property.

** Section 2.6.1.  Figure 26.  The example proposes to retrieve a certificate
(judging from the .cer file extensions) over HTTP.  In the general case, this
doesn’t seem like a good idea.  Please use the https:// scheme.