Reese, thanks for the review. I entered a No Objection ballot. Lars > On 15. Mar 2023, at 18:59, Reese Enghardt via Datatracker <noreply@xxxxxxxx> wrote: > > 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
