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

[Robert Stepanek <[e-mail]>]

Hi Paul,

thanks for your review. We updated the documents and will publish them soon. Please see details below.

Regards,
Robert

On Tue, Apr 11, 2023, at 10:06 PM, Paul Wouters via Datatracker wrote:
> Paul Wouters 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:
> ----------------------------------------------------------------------
> 
> I agree with Roman on the IANA Registry policy issues. Additionally, I have a
> few minor DISCUSSes and COMMENTS.
> 
> Section 1.7.2:
> 
>         [...] a new standard RFC document MUST be published.
> 
> RFCs target implementers, who on their own cannot comply with this MUST :P
> Using RFC 2119 language to force someone to write an RFC is .... interesting :)
> I would remove the sentence.

Fixed. We removed that sentence and updated the IANA registry policy to require RFC 8126 Standards Action for changing the JSContact major version number.

> 
> Similarly,
> 
>         Every new JSContact version MUST be registered at IANA in the JSContact
>         Enum Value registry Table 6.
> 
> is pretty meaningless within this RFC. I would also remove this sentence

Fixed.

> 
> IDN related:
> 
>      The following all are valid examples of vendor-specific properties.
> 
>         "example.com:foo": "bar",
>         "example.com:foo2": {
>           "bar": "baz"
>         }
> 
> What about:
> 
>         "xn--exmple-xta.com:foo": "bar",
> 
> Could this cause confusion or security issues ?
> (this is the A-label version of "exâmple.com")

We see no source of confusion or security issues. Section 1.9.1 defines the ABNF for such property names, where care has been taken to only allow encoded internationalized domain names using hyphens and ASCII alphanumerics.

> 
>         As of this writing, a revision of [RFC4122] is being worked on
> 
> Please add an informative reference to draft-ietf-uuidrev-rfc4122bis, so
> future implementers might stumble upon the bis document or RFC

Done.

> 
> Section 2.3.2
> 
>         service: String (optional). The name of the online service or
>         protocol. This SHOULD be the canonical service name including
>         capitalization. Typically the service name is the one which the
>         providers of that service use on their web sites, in their apps or
>         other publishing material. Examples are GitHub, kakao, Mastodon.
> 
> This seems a bit dangerous from a security point of view, eg "GitHub" vs
> "Github" and might be misleadiing. Would it be safer to match a string without
> case, and allow a presentation format with case?

Fixed. We rephrased to "SHOULD include capitalization but MUST be considered equal if they match case-insensitively".

> 
> Section 2.6.1
> 
> Why is there no  cryptoKeys option that embeds the public key. Only indirect URI
> syle options are available.

It already allows to embed keys using a data: URI, but we now emphasize this by an example.

> Two phones using "airdrop" could benefit from being
> able to exchange the actual public key blobs directly.
> 
> Also perhaps using "kind" could be RECOMMENDED ? Otherwise there will be some
> guessing needed for the crypto protocol/application kind which could be
> dangerous.

We only defined cryptoKeys as much as we need to be compatible with the existing vCard KEY property definition. We are no security experts and would welcome additions the cryptoKeys properties in a separate document.

> 
> Section 2.8.1. anniversaries
> 
> Since "kind" is mandatory, there should be a value "other", or else it can only
> contain birthday, deathday and wedding day.

The "other" enumeration value for anniversaries actually was dropped during working group discussion. We only require Expert Review for registering additional enum values, so we rather want people to register specific new anniversary types.

> 
> Section 2.8.4. personalInfo
> 
> Similarly, needs an "other" option as "kind" is mandatory.

Same argument as for anniversaries applies.

> 
> Section 5.
> 
> The Security Considerations start of with stating the importance of privacy,
> but in Section 5.2 still allows (almost recommends) HTTP along with HTTPS. Why
> not remove HTTP there?

We replaced all uses of "http/ftp" with "https".

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 1.6.3. The pref property
> 
> why not start from 0 ? What to do when the value is set to 0, same as unset ?

RFC 6350 defines the minimum value of PREF to be 1, so we stay in line with that.

> 
> 
>         Implementors are RECOMMENDED to always support the latest version.
> 
> I would remove this (obvious) advise

Done.

> 
>         Such extensions are not meant for interoperation and vendors
>         MUST NOT expect other implementations to process their contents.
> 
> The "MUST NOT expect" reads a little strange, as if we are dictating a mind set
> instead of a technical process. Maybe say "other implementations MUST NOT process" ?

Fixed, we replaced this with just "Such extensions are not meant for interoperation."

> 
> Setion 1.9.1:
> 
>         followed by a name consisting of any other non-control ASCII or non-ASCII characters.
> 
> I can't parse this constraint. Perhaps "consisting of only non-control ASCII characters" ?

Fixed, we removed the specific character restrictions in that paragraph and refer to the ABNF which clearly defines this.

> 
> Section 2.2.1 lists limitations on "fullName" with respect to "name", but
> section 2.2.2 for "name" does not list its limitations to "fullName".
> A similar case is true for StreetComponents and fullAddress.

Done, we added backlinks in "name" and "street" to their "fullName" and "fullAddress" counterparts.

> 
> Also, why is StreetComponent not lowerCamelCase like the other options?
> It seems only the values of 4.4.2 using capitals instead of starting with
> lowercase. Is there a convention or reason for this that I am not aware of?
> 
> Section  2.4.1
> 
> Can the ftp examples be replaced by non-ftp examples? The IETF as a whole is trying
> to move away from the ftp protocol.

We replaced "ftp" with "https".