[VCARDDAV]Re: [Errata Rejected] RFC6350 (7856)

[Orie Steele <[e-mail]>]

I changed the status to editorial when rejecting this errata.

Editorial errata are normally processed by the RFC Editor.

As a result of the discussion here, I also filed:

https://github.com/ietf/terminology/issues/34

If the RFC Editor agrees this is editorial, and disagrees with the
rejection, the errata should be reopened, and processed by them.

I would not object to this errata being marked as verified, I don't think
hold for document update makes sense in this case.

Thanks for your reply.

OS, ART AD












On Sat, May 11, 2024, 3:49 AM <[e-mail]> wrote:

> Orie,
>
> Thanks for your reply. See below for my more detailed justification that
> the errata should be Verified.
>
> The status message says it was reported as "editorial". I could see
> arguments either way for technical vs editorial.
>
> Guidelines:
>
> "Only errors that could cause implementation or deployment problems or
> significant confusion should be Verified."
>
> I have reviewed the original email discussion regarding this RFC and found
> that inclusion of the word "biological" was likely an oversight. The author
> was in agreement when I got in touch. I believe that discussion was CC'd to
> an IETF list and is public, and I've also CC'd Simon's current email
> address here (nice domain hack).
>
> Taking that context into consideration, my interpretation of the intended
> meaning is that the sex portion of the GENDER field was intended to be a
> machine parsable version of the gender identity portion. The examples
> reflect this, especially "it's complicated".
>
> The key point here is "cause [...] significant confusion".
>
> Even setting aside intent, "biological" does not have a clear meaning in
> this context. You might take "biological" to mean chromosomal karyotype. In
> that case, a literal interpretation would require many people to indicate
> "U". More often than might be expected things aren't what they seem.
>
> "Things that are clearly wrong but could not cause an implementation or
> deployment problem should be Hold for Document Update."
>
> Subjective. I believe it could cause implementation/deployment problems. I
> note that the reason I decided to file the issue is that the definition for
> h-card was taken from RFC6350, and I consider this to be an
> implementation/deployment problem.
>
> https://microformats.org/wiki/h-card
>
> It also may not be clear to a reader of the RFC that the information is
> wrong.
>
> "Errata on obsolete RFCs should be treated the same as errata on RFCs that
> are not obsolete where there is strong evidence that some people are still
> making use of the related technology."
>
> The relevant part of the RFC is not obsolete.
>
> The GRAMGENDER and PRONOUNS fields in the RFC recently published to update
> RFC6350 supercede some, but not all, of the uses of the GENDER field.
>
> "Trivial grammar corrections should be Hold for Document Update."
>
> Not a trivial grammar correction.
>
> "Typographical errors which would not cause any confusions to
> implementation or deployments should be Hold for Document Update."
>
> Not a typographical error.
>
> "Changes which are simply stylistic issues or simply make things read
> better should be Hold for Document Update."
>
> Not simply a stylistic issue.
>
> "Changes that modify the working of a protocol to something that might be
> different from the intended consensus when the document was approved should
> be either Hold for Document Update or Rejected. Deciding between these two
> depends on judgment. Changes that are clearly modifications to the intended
> consensus, or involve large textual changes, should be Rejected. In unclear
> situations, small changes can be Hold for Document Update."
>
> Does not change the working of the protocol to something different from
> consensus when document was approved.
>
> This change aligns the wording with the intended consensus from when the
> document was approved.
>
> "Changes that modify the working of a process, such as changing an IANA
> registration procedure, to something that might be different from the
> intended consensus when the document was approved should be Rejected."
>
> Not applicable.
>
> No single guideline clearly indicates Rejected or even Hold for Document
> Update would be appropriate.
>
> Overall, I feel that the guidelines taken as a whole favor **Verified**,
> in order to align the wording with the consensus intended when the document
> was approved.
>
> On May 11, 2024 7:12:55 AM GMT+05:30, Orie Steele
> <[e-mail]> wrote:
> >I agree that the original text is unfortunate.
> >
> >I searched the updates for this text, and it does not appear in them.
> >
> >I'm following the process described here:
> >
> >
> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20080730/
> >
> >Can you propose a status and justify it based on this guidance?
> >
> >This errata was initially reported as technical, but I believe it is
> >editorial, so I would also like to hear from the RFC Editor, do you
> believe
> >this should have been processed differently?
> >
> >Regards,
> >
> >OS, ART AD
> >
> >On Fri, May 10, 2024, 8:19 PM <[e-mail]> wrote:
> >
> >> I disagree with the reason given for rejection.
> >>
> >> RFC9554 neither deprecates nor changes the original GENDER field in any
> >> way.
> >>
> >> Adding a new GRAMGENDER field does not address the issue I raised. Nor
> >> does the new PRONOUNS field. They both serve distinct purposes from the
> >> GENDER field.
> >>
> >> I also note that a previous errata was accepted to the same section to
> >> make the examples less irreverent.
> >>
> >> I've had some discussion via email with the author of RFC6350, who was
> >> seemingly in agreement that "(biological)" should not have been
> included in
> >> the first place.
> >>
> >> On May 11, 2024 2:20:34 AM GMT+05:30, RFC Errata System <
> >> [e-mail]> wrote:
> >> >The following errata report has been rejected for RFC6350,
> >> >"vCard Format Specification".
> >> >
> >> >--------------------------------------
> >> >You may review the report below and at:
> >> >https://www.rfc-editor.org/errata/eid7856
> >> >
> >> >--------------------------------------
> >> >Status: Rejected
> >> >Type: Editorial
> >> >
> >> >Reported by: Ryan Castellucci <[e-mail]>
> >> >Date Reported: 2024-03-18
> >> >Rejected by: Orie Steele (IESG)
> >> >
> >> >Section: 6.2.7
> >> >
> >> >Original Text
> >> >-------------
> >> >   Special notes:  The components correspond, in sequence, to the sex
> >> >      (biological), and gender identity.  Each component is optional.
> >> >
> >> >Corrected Text
> >> >--------------
> >> >   Special notes:  The components correspond, in sequence, to the sex
> >> >      and gender identity.  Each component is optional.
> >> >
> >> >Notes
> >> >-----
> >> >The term "biological" in regards to sex does not have a widely agreed
> >> upon meaning, and is primarily used to discriminate against transgender
> >> people.
> >> >
> >> >Including the "biological" qualifier serves no purpose.
> >> > --VERIFIER NOTES--
> >> >Rejected per:
> >>
> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
> >> >
> >> >Note this topic has been better addressed in recent revisions:
> >> >
> >> >https://datatracker.ietf.org/doc/html/rfc9554#section-3.2
> >> >
> >> >--------------------------------------
> >> >RFC6350 (draft-ietf-vcarddav-vcardrev-22)
> >> >--------------------------------------
> >> >Title               : vCard Format Specification
> >> >Publication Date    : August 2011
> >> >Author(s)           : S. Perreault
> >> >Category            : PROPOSED STANDARD
> >> >Source              : vCard and CardDAV
> >> >Stream              : IETF
> >> >Verifying Party     : IESG
> >>
>