-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/31/09 9:56 AM, Simon McVittie wrote: > While implementing XEP-0055 Jabber Search in Telepathy, we've hit an ambiguity > in the spec between first/last names, and given/family names.
XEP-0055 documents historical usage of a protocol that was designed in the bad old days before anyone in the Jabber community was aware of the issues surrounding non-Western usage. Therefore it uses terms that to me are unhelpful (first and last) instead of terms that are truly accurate (given and family). My interpretation is this: 1. By <first/> XEP-0055 means Given Name. 2. By <last/> XEP-0055 means Family Name. > It's clear that to find a person with a Western name in a Jabber directory, > you would use something like this: > > <first>Gordon</first> > <last>Brown</last> > > or this: > > <field var='first'><value>Gordon</value></field> > <field var='last'><value>Brown</value></field> Correct. > However, names in many Asian cultures (e.g. Chinese names) don't work like > Western names: for example, in the name "Hu Jintao", Jintao is the given name > and Hu is the family. To search for the Chinese leader, should one use > > <field var='first'><value>Hu</value></field> > <field var='last'><value>Jintao</value></field> > > (i.e. the field semantics are as suggested by the markup, and are really > first name and last name), or > > <field var='first'><value>Jintao</value></field> > <field var='last'><value>Hu</value></field> > > (i.e. the markup is by historical accident, and what was really meant is > "family name" and "given name")? The latter. > Similarly, in the historical version, the fields are called <first/> and > <last/>, although I realise this doesn't necessarily mean anything about > their semantics. Right. > vCard explicitly specifies that the first component of the "N" > (structured name) type-name (field) contains the family name, and the > second contains the given name, like so: > > FN:Hu Jintao > N:Hu;Jintao > > FN:Gordon Brown > N:Brown;Gordon > > In Telepathy, we want to propagate correct information through the framework > to UIs: this means that in protocols that use given name/family name, we want > to use fields x-n-given and x-n-family (in our notation), and for > protocols that use first/last name, we want to use x-first and x-last. > Which of these categories does XMPP fall into, in practice? I think the intent in XEP-0055 was as I described above. What it means in practice is another story, because I don't know how various clients and servers have implemented the spec. > Unhelpfully, the spec and examples in XEP-0055 v1.2 seem to be evenly > distributed between the two models: > > * XMPP Registrar Considerations: <field var='first' label='First Name'/> > * XMPP Registrar Considerations: <field var='last' label='Family Name'/> > * Example 7: <field var='first' label='Given Name'/> > * Example 7: <field var='last' label='Family Name'/> > * Example 9: <field var='first' label='First Name'/> > * Example 9: <field var='last' label='Last Name'/> I shall fix those so that <first/> always maps to Given Name and <last/> always maps to Family Name. > In particular, the XMPP Registrar registration is not even internally > consistent! Good point. :) > It would be helpful if one of these could be chosen: > > * Accept Example 7 (family/given) as the canonical interpretation: > - change Example 9 and the Registrar registration for 'first' to match it > - explain that the "first" and "last" naming is a historical accident, and > that's not really what the fields mean > > * Accept Example 9 (first/last) as the canonical interpretation: > - change Example 7 and the Registrar registration for 'last' to match it > > It would also be very useful to include a family-name-first (e.g. Chinese) > name in at least one example to illustrate how that works, although > unfortunately that breaks the convention of using examples from Shakespeare > :-) I'll add a Chinese example. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqS3/EACgkQNL8k5A2w/vzgRgCfcP7k8Nx66PaIN9NJi/of5ECi bNMAniBZ9Zk16lyGgsAebEcpc4zV8JI0 =8J7O -----END PGP SIGNATURE-----
