RE: Name relationships in vCard 3.0

I understand the "50,000 ft" description of N and FN; that N is structure=
d 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 th=
e software you write.=20

If FN can not be derived from N, then there are a host of issues that nee=
d to be addressed, and as far as I can tell, have not been addressed in t=
he 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;Geo=
rge, 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 se=
condary type (i.e. N or FN) irrelevant, and the last case seems pathalogi=
cal. So, which approach do you choose? If, on the other hand, FN can be d=
erived from N, it seems to me that it would be perfectly appropriate to d=
isplay FN and sort by the components of N.

There is a related issue you brought up with the N type: if there are mul=
tiple components to an item in the structured type (e.g. Given Name), whi=
ch one is used for display and sorting?

	~jeff



-----Original Message-----
From: Misha Wolf [mailto:[email protected]]
Sent: Thursday, September 09, 2004 8:19 AM
To: Jeff Parrish; [email protected]
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=20
particular order, while FN contained just one of those, which might=20
not be the first one.  Similarly, N could contain "Robert", while=20
FN contained "Bob".

The bottom line is that they are not (necessarily) identical.  OK?

Misha


-----Original Message-----
From: Jeff Parrish [mailto:[email protected]]=20
Sent: 09 September 2004 16:13
To: Misha Wolf; Germ=E1n M. Rivera; [email protected]
Subject: RE: Name relationships in vCard 3.0


2 points:

1) Isn't the "Nickname" type intended for the "Dubya" case described belo=
w, 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 assumpt=
ion 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 possib=
le 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:[email protected]]
Sent: Thursday, September 09, 2004 3:19 AM
To: Germ=E1n M. Rivera; Jeff Parrish; [email protected]
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=20
Jackson made any hit singles recently?  He has not.  I'm referring=20
to the originator of Jackson Structured Programming.  Whom did you=20
think I meant?

FN and N should describe the same person, but I don't believe there=20
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=20
completely different in the individual fields of my N type (eg "Bush"=20
and "George" and "W").

Misha Wolf
Standards Manager
Product and Platform Architecture Group
Reuters


-----Original Message-----
From: [email protected] [mailto:[email protected]] =
On Behalf Of Germ=E1n M. Rivera
Sent: 09 September 2004 09:01
To: 'Jeff Parrish'; [email protected]
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=E1n
=20

> -----Mensaje original-----
> De: [email protected] [mailto:[email protected]]
En
> nombre de Jeff Parrish
> Enviado el: jueves, 09 de septiembre de 2004 2:36
> Para: [email protected]
> Asunto: Name relationships in vCard 3.0
>=20
>=20
> 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)
>=20
> 	FN:Mr. John Q. Public\, Esq.
> 	N:Putenesca;Fanny;Mae;Mrs
>=20
>=20
>=20
> 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.