Skip to main content

Last Call Review of draft-ietf-calext-jscontact-vcard-06

Request Review of draft-ietf-calext-jscontact-vcard
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2023-04-07
Requested 2023-03-17
Authors Mario Loffredo , Robert Stepanek
I-D last updated 2023-03-22
Completed reviews Genart Last Call review of -06 by Russ Housley (diff)
Artart Last Call review of -06 by Paul Kyzivat (diff)
Secdir Last Call review of -06 by Phillip Hallam-Baker (diff)
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-calext-jscontact-vcard by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 06 (document currently at 15)
Result Almost ready
Completed 2023-03-22
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

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

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


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.