[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Name relationships in vCard 3.0
It is my understanding that, as Roland wrote, processing should happen on N, while display should use FN. I'm not sure, though, how informal versions of Given names should be represented in N. [I no longer have a copy of X.520; does anyone on this list?] For example, my birth certificate and passport show Michael Joseph Wolf. I never use the Joseph and I almost invariably use Misha instead of Michael. This has got more difficult in the past year, due to the increased security precautions. For example, I now have to book airline tickets as Michael, so they match my passport, though my credit cards say Misha. Anyhow ... I'm not sure whether my N should include Misha as well as Michael and Joseph. It it does, then it implies I have three Given names. If it does not, and processing uses N, then a search wouldn't find me (unless it looked at FN as well).
Misha Wolf
Standards Manager
Product and Platform Architecture Group
Reuters
-----Original Message-----
From: Jeff Parrish [mailto:Jeff.Parrish@xxxxxxxxxxxxxx]
Sent: 09 September 2004 16:48
To: Misha Wolf; imc-vcard@xxxxxxx
Subject: RE: Name relationships in vCard 3.0
I understand the "50,000 ft" description of N and FN; that N is structured and FN is just a text string, but I'm still trying to better understand the intent, so that I can write software that will be compatible with the software you write.
If FN can not be derived from N, then there are a host of issues that need to be addressed, and as far as I can tell, have not been addressed in the RFC. For example, how do I display and sort by name in such a way that users won't be totally confused? For example, if FN:Dubya and N:Bush;George, I either need to display "George Bush" and sort by "George" and/or "Bush", or display (and sort by) "Dubya", but it makes no sense to display "Dubya" and sort based on "Bush;George". The first two cases make the secondary type (i.e. N or FN) irrelevant, and the last case seems pathalogical. So, which approach do you choose? If, on the other hand, FN can be derived from N, it seems to me that it would be perfectly appropriate to display FN and sort by the components of N.
There is a related issue you brought up with the N type: if there are multiple components to an item in the structured type (e.g. Given Name), which one is used for display and sorting?
~jeff
-----Original Message-----
From: Misha Wolf [mailto:Misha.Wolf@xxxxxxxxxxx]
Sent: Thursday, September 09, 2004 8:19 AM
To: Jeff Parrish; imc-vcard@xxxxxxx
Subject: RE: Name relationships in vCard 3.0
As Roland wrote, FN is supposed to hold the usual formatted name.
So, for example, N might contain multiple Given names, in some
particular order, while FN contained just one of those, which might
not be the first one. Similarly, N could contain "Robert", while
FN contained "Bob".
The bottom line is that they are not (necessarily) identical. OK?
Misha
-----Original Message-----
From: Jeff Parrish [mailto:Jeff.Parrish@xxxxxxxxxxxxxx]
Sent: 09 September 2004 16:13
To: Misha Wolf; Germán M. Rivera; imc-vcard@xxxxxxx
Subject: RE: Name relationships in vCard 3.0
2 points:
1) Isn't the "Nickname" type intended for the "Dubya" case described below, or any other
similar case where there is a deviation from the N type.
I think the existance of this type gives further weight to the assumption that the
FN type is intended to be derived from the N type.
2) A previous posting by Ronald Alden suggested that it may not be possible to map the structured
type N to the FN type, and I would like to know if he could provide an example. It is clear
that the FN type would need to be locale specific (Chinese vs English, for example), but I
can't think of a case where no mapping exists.
Thank you for your prompt, cogent comments.
~jeff
-----Original Message-----
From: Misha Wolf [mailto:Misha.Wolf@xxxxxxxxxxx]
Sent: Thursday, September 09, 2004 3:19 AM
To: Germán M. Rivera; Jeff Parrish; imc-vcard@xxxxxxx
Subject: RE: Name relationships in vCard 3.0
No, it is not "assumed that the name of the object (a person) is
unique". This would clearly be a wrong assumption. Has Michael
Jackson made any hit singles recently? He has not. I'm referring
to the originator of Jackson Structured Programming. Whom did you
think I meant?
FN and N should describe the same person, but I don't believe there
is anything in vCard that forces a textual equivalence between them.
If I wanted to, I could put "Dubya" in my FN type and something
completely different in the individual fields of my N type (eg "Bush"
and "George" and "W").
Misha Wolf
Standards Manager
Product and Platform Architecture Group
Reuters
-----Original Message-----
From: owner-imc-vcard@xxxxxxxxxxxx [mailto:owner-imc-vcard@xxxxxxxxxxxx] On Behalf Of Germán M. Rivera
Sent: 09 September 2004 09:01
To: 'Jeff Parrish'; imc-vcard@xxxxxxx
Subject: RE: Name relationships in vCard 3.0
Hi Jeff,
As you can see in the RFC, this is the FN type purpose:
"To specify the formatted text corresponding to the name of the object
the vCard represents"
and this is the N type purpose:
"To specify the components of the name of the object the vCard
represents"
Of course, it is assumed that the name of the object (a person) is
unique, so these two types should describe the same content.
Hope this helps,
Germán
> -----Mensaje original-----
> De: owner-imc-vcard@xxxxxxxxxxxx [mailto:owner-imc-vcard@xxxxxxxxxxxx]
En
> nombre de Jeff Parrish
> Enviado el: jueves, 09 de septiembre de 2004 2:36
> Para: imc-vcard@xxxxxxx
> Asunto: Name relationships in vCard 3.0
>
>
> What is the relationship between the N: and FN: types. In particular,
> there is nothing I can find in the RFC that explicitly requires the
> contents of these types to match, and both fields are mandatory. Is
> there a reason to allow them to mismatch? If not, the contents of FN:
> need to be generated from the contents of N:, or else the contents of
> the two types may not match (see below)
>
> FN:Mr. John Q. Public\, Esq.
> N:Putenesca;Fanny;Mae;Mrs
>
>
>
> Jeff Parrish
--------------------------------------------------------------- -
Visit our Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.
-----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.
-------------------------------------------------------------- --
Visit our Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.