Last Call Review of draft-ietf-calext-jscontact-vcard-06
review-ietf-calext-jscontact-vcard-06-genart-lc-housley-2023-03-22-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-calext-jscontact-vcard-06
Reviewer: Russ Housley
Review Date: 2023-03-22
IETF LC End Date: 2023-04-07
IESG Telechat date: unknown


Summary: Almost Ready


Major Concerns:

Section 2.3.10: I do not understand what an implementation is intended
to do with a MAY followed by a SHOULD:

   ...  In this
   case, implementations MAY choose to add the localized vCard
   properties only to the localizations object.  Implementations SHOULD
   avoid this scenario as much as possible.

Sections 2.12.2 and 2.12.10: What is an implementation to do?

Sections 2.26.1 and 2.16.2: I do not understand what an implementation
is intended to do with a MAY followed by a MUST:

      ...  It MAY
      contain vCard IANA-registered properties which also got converted
      to an IANA-registered property in the same JSContact object.  In
      case of conflict, the values of the JSContact property MUST be
      used.

Section 3.1: I do not understand what an implementation is intended to
do with a MAY followed by a MUST:

      ...  If the fullName is not set but the name
      property is, then implementations MAY derive the value of the FN
      property from it.  In this case, they MUST set the DERIVED
      parameter on the FN property.  Otherwise, they MUST set the FN
      property with an empty value.

Section 3.2.1: I do not understand what an implementation is intended
to do with a MAY followed by a MUST:

   ...  The VALUE parameter MAY be set once, in which
   case its value MUST be URI.


Minor Concerns:

Section 2.2.2 says: "vCard properties or parameters having such values
MAY convert as defined in Section 2.16."  I expected SHOULD here.  If
MAY is correct, then this section needs explain how interoperability
is achieved.

Section 2.2.3 says: "To preserve the verbatim value of the ALTID
parameter, set the JSContact extension properties props or params
defined in Section 2.16."  I cannot understand this sentence.  I
think this is talking about "extended properties and parameters".


Nits:

It would be helpful if there is a way to come up with examples that do
not exceed 73 characters on a line.

Section 2 says: "Its follows the same structure as the vCard v4 RFC
document [RFC6350]."  I suggest dropping "RFC document". Likewise,
in the following sentence, I suggest dropping "RFC".

Section 2.1.1 says: "Consequently, a vCard without UID property
MAY not convert to one exact instance of a JSContact card."  This
use of MAY seems out of place.  I suggest: "Consequently, a vCard
without UID property could result in one or more instance of a
JSContact card."

Section 2.3.10: s/property.Figure 4 /property.  Figure 4 /

Section 2.3.15: s/vCard property converts to./vCard property converts./

Section 2.10.4: s/OrgUnit object/OrgUnit object./

Section 2.12.4: s/(Figure 33)/(Figure 33)./

Section 2.16: s/unknown Section/unknown; see Section/

Section 3.1: s/section Section 3.2/Section 3.2/


Note: I did not review Section 6.