Re: [calsify] [Gen-art] Genart last call review of draft-ietf-calext-jscontact-08

Reese, thanks for the review. I entered a No Objection ballot.

Lars

> On 15. Mar 2023, at 18:59, Reese Enghardt via Datatracker <noreply@ietf.org> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call