Stop trying to dissect names [Sparks]

[rjsparks]

We have a pervasive western-expecting set of behaviors that extend throughout the lifecycle of development of an RFC. We expect there to be a "Last Name" and "First Initials".

These concepts don't make sense for all cultures.

The code we have that attempts to extract these things heuristically frequently produces wrong results, requiring manual fixup (and the datastore to capture the manual fixup).

I propose what we should do instead is stop trying, and ask people to provide their name as they want it displayed (anywhere, but particularly on the first and final pages of an RFC) as a blob and we just use that.

We could also ask for a Latinized blob and use it in the places that it made sense to use it.

[reschke]

Actually, we have that, no? "fullname" is the full name. It appears in the back matter. "last name" and "initials" is what we use on the front page and in references. It's both under the author's control.

(we can argue whether these attribute names are optimal, but that's really different from "we need to change the whole approach to it")

[reschke]

The code we have that attempts to extract these things heuristically frequently produces wrong results, requiring manual fixup (and the datastore to capture the manual fixup).

So the problem is that code, not our doucment format. Or am I missing something here?

[klensin]

AFAICT, Julian is correct as far as RFCs and RFC publication formats are concerned. It is also not an accident that the XML attributes, going back to v.1, have been "initials", "surname", and "fullname" and not "lastname" and "initial".

I can easily think of cases in which I'd want more detail, including knowing how to address someone, cultures in which listing degrees and/or titles is considered important, and maybe some indexing purposes, but those are different sorts of issues. So, Robert, can you provide a bit more information about what problem you are trying to solve and why it is important.?

[klensin]

Which "code" are we talking about that has to use heuristics? One of the things that takes an non-EFCXML document and tries to make RFCXML? Or something that works on an RFCXML document? If the former, I'm not sure it is even in scope for this WG, much less something that should hold up,, e.g., a v3.1 effort.

[rjsparks]

The issue is in how <reference> are currently built. When the meeting allows I'll point to detail.

[reschke]

Understood. But that's an issue for generators, not with the vocabular itself, or the tools processing rfcxml as input.