Reviewer: Reese Enghardt Review result: Almost Ready 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. 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: https://www.britannica.com/dictionary/neuter). 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? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
