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

[Robert Stepanek <[e-mail]>]

Hi Roman,

thanks for your feedback. We have updated the document accordingly and will publish the new version soon. Please see below for details.

Regards,
Robert

On Tue, Apr 11, 2023, at 5:10 AM, Roman Danyliw via Datatracker wrote:
> ----------------------------------------------------------------------
> 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?

We changed SHOULD to MUST. This now also aligns with the definitions of RFC 8984.

> 
> ** 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?
and
> 
> -- @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?

Fixed, we updated this to say: major version changes requires Expert Review + Standards Action. Other changes require Expert Review, optionally amended by Specification Request at the discretion of the Designated Expert.

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

Fixed. We require Standards Action.

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

The Designated Expert is expected to be a member of CALEXT, which maintains this and other contact related RFCs. The Expert has the final say to say which registry policy applies, but if a new standard RFC is required then the regular IETF processes apply. Otherwise the Expert has the final say.

> 
> ** 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?

Fixed - removed from that section.

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

The properties of (a) were meant in (c). We rephrased the text to make that clear.

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

Fixed.

> 
> ** 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?

"Control" means to control the domain name that is part of the vendor-specific property name (where it being a domain name now is a mandatory requirement). We clarified this section.

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

Fixed. We removed the first sentence up to the colon.

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

Fixed. We removed "canonical".

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

Fixed. This was just copied over from RFC 6350. We now chose "webcal" and "https".

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

Fixed.

> 
> ** 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?

The CryptoResource already includes all properties the Resource object (section 1.5.4). This includes the "kind" and "contexts" properties. We refrained from enumerating any "kind" values, though. This would require us to also define new vCard parameters for the vCard KEY property definition (RFC 6350, section 6.8.1). We think that this requires more expertise and work from security experts and should not be part of our RFC.

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

No. We only added cryptographic support to JSContact to allow preserving existing vCard elements. This is because we think that any additions in that area should be worked out by security experts.

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

We added an example for the "data:" scheme.

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

Fixed. We updated all examples to use https rather than http.