Skip to main content

Last Call Review of draft-ietf-calext-jscontact-08

Request Review of draft-ietf-calext-jscontact
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2023-03-17
Requested 2023-03-03
Authors Robert Stepanek , Mario Loffredo
I-D last updated 2023-03-15
Completed reviews Genart Last Call review of -08 by Reese Enghardt (diff)
Secdir Last Call review of -08 by Derek Atkins (diff)
Artart Last Call review of -07 by Martin J. Dürst (diff)
Assignment Reviewer Reese Enghardt
State Completed
Request Last Call review on draft-ietf-calext-jscontact by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 08 (document currently at 17)
Result Almost ready
Completed 2023-03-15
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-08
Reviewer: Reese Enghardt
Review Date: 2023-03-15
IETF LC End Date: 2023-03-17
IESG Telechat date: Not scheduled for a telechat

Summary: The document is clear and well written. However, I do have two major
comments about naming and grammatic gender, which I ask the authors to consider
before moving forward with publication.

Major issues:

Sections 2.2.1 and 2.2.2

These sections consider "the [full] name of the entity represented by the
card". As I'm sure you're aware, names can be complex and contextual, and which
name to use for a person is not always obvious. I'm not clear on how the scheme
in this document would allow for a Card to contain both a legal name and a
(different) preferred name, or marking a name as legal or preferred. This is an
important distinction for many transgender people, such as myself, and I
frequently run into problems with systems that lack such a distinction.
Whenever a system only provides a single "name" field, this name may or may not
be assumed to be my legal name by any particular entity, and the outcome is
either I enter my preferred name and then risk running into problems because it
does not match my documents, or I enter my legal name and then get addressed
with the wrong name. The "nick name" field in Section 2.2.3 does not address my
concern, as my legal name is not a nickname, and my preferred name is certainly
not a nickname either, and I would find it disrespectful if it were to be
treated as such. In my ideal world, "the [full] name" field in Sections 2.2.1
and 2.2.2 is unambigously defined as the preferred name, which most people and
systems should use, with a note to not assume that "the [full] name" is in fact
a legal name that matches a person's documents or such. In addition, it might
make sense to add a "legal name" property, to be filled out if different from
"the [full] name" in 2.2.1 and 2.2.2, if the context absolutely requires to use
legal names, e.g., for booking flights or anything that requires legal
documents. Or, if card data is unlikely to be used in such contexts, perhaps
the "legal name" field can be a vendor-specific extension or such.

Section 2.2.5

For the grammaticalGender property, it seems that the values should be
"feminine" (rather than "female"), "masculine" (rather than "male"), and
"neuter", if the value labels are indeed intended to represent grammatical
gender (see, for example, the Britannica
Dictionary: As an alternative, I
suggest changing these labels to more closely represent how one would
respectfully talk about individuals, by changing "neuter" to "gender-neutral"
while keeping "female" and "male". It is not clear to me why the
"animate" value exists in addition to the above grammatical genders, as this
value does not convey information about how to address the entity, but if you
are sure that there's a use case for this value, I'll defer to your expertise.

Minor issues:

Section 1.5.4

The descriptions for @type and type sound very similar. Is it possible to state
more clearly what the difference between the two is? Is it worth
mentioning/explaining the @ in an earlier notation section?

Nits/editorial comments:

The word "card" is capitalized in some sections and not others (e.g.,
capitalized in 2.2.2 but not in 2.2.1) without an obvious difference in
semantics. Please consider making the capitalization consistent in such cases.

Section 1.5.2

"-253+1 <= value <= 2^53-1"
Can the ^ be removed to make the notation consistent?