Human Names

(Slightly edited copy of https://mailarchive.ietf.org/arch/msg/rfc-markdown/G94QEYPZuCXPKdUb7LQGV1pFTaQ for now, which was a release note to kramdown-rfc version 1.5.26.)

Names in kramdown-rfc

Release 1.5.26 mainly focuses on author information (both for the document itself and in references), and in particular provides access to the asciiXXX attributes that RFCXMLv3 provides to be able to render Latin (not necessarily ASCII) variants of non-Latin names used in author info, contributor info, and in references. This support is unfortunately hobbled by a few xml2rfc bugs; I’ll announce the feature more properly when we have progress on these.

The change that was long overdue and was forced due to the above changes is better support for generating initials.

As discussed in various fora, we really should get rid of the habit of shortening names into initials. But it is what we have in RFCXML, the references database, as well as in the most recent style guide RFC 7322, so we need to work with them.

Today, many people provide both the initials and the fullname in a construct like:

authors:
 - ins: C. Bormann
   name: Carsten Bormann

kramdown-rfc2629 now takes care to generate the “ins” from the “name”, so it is no longer necessary to put in the ins:

authors:
 - name: Carsten Bormann

The heuristics can handle hyphenated names:

 - name: Jean-Pierre Paul

The heuristics need help with complex last names: Just separate the first names from the last name with a pipe:

 - name: Jean-Pierre | Paul de Vera

(Note that “Paul de Vera” is the last name; multi-word support like this is needed often for Spanish last names, but also for “van der Stok” and “von Schneider” etc. The pipe of course doesn’t make it through to the fullname attribute.)

As far as I can see, the heuristics now work very well.

However, there is one snag:

 - name: Richard L. Barnes

Leads to a full set of initials on the front page:

                      R. L. Barnes

(And “Richard L. Barnes” in the authors’ addresses section, as it should.)

This initialization is as it should be, but not the current practice (*). So in this case, if you really want/need to emulate current practice, you have to play the “ins” game or explicitly give the “initials” attribute to override the heuristic for the frontpage.

 - ins: R. Barnes
   name: Richard L. Barnes

 - name: Richard L. Barnes
   initials: R.

PostScript on dots in initials

(*) RFC 7322 says:

4.1.1:
  The author's name (initial followed by family name) appears on the
  first line of the heading.  Some variation, such as additional
  initials or capitalization of family name, is acceptable.  Once the
  author has selected how their name should appear, they should use
  that display consistently in all of their documents.

4.8.6.2:
     [RFCXXXX] Last name, First initial., Ed. (if applicable),
               "RFC Title", Sub-series number (if applicable),
               RFC number, Date of publication,
               <http://www.rfc-editor.org/info/rfc#>.

There are enough cases that look somewhat different, so I was not able to really derive a rule here:

RFC 7693:
  Markku-Juhani O. Saarinen (editor)
  Jean-Philippe Aumasson
➔
7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC).
    M-J. Saarinen, Ed., J-P. Aumasson. November 2015. (Format: TXT,
    HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7693) 

RFC 8585:
  Jordi Palet Martinez     [a Spanish name]
  Hans M.-H. Liu           [Chinese name with “English” given name added?]
➔
8585 Requirements for IPv6 Customer Edge Routers to Support
    IPv4-as-a-Service. J. Palet Martinez, H. M.-H. Liu, M. Kawashima.
    May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI:
    10.17487/RFC8585)

Further reading

Please read Falsehoods Programmers Believe About Names if you need more input about the difficulties in handling human names in programs.