RE: Name relationships in vCard 3.0

 
> 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. 

Perhaps. But if FN could be derived from N then there would be no need
for FN :)

I don't think there would be any particular problem if an application
ignored FN and just used, from N, pieces of "name" stuff that it felt
best able to process.

> 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". 

In your example it might "make no sense" but there might be other
examples, from Japan perhaps, where what is sorted on and what is
displayed are quite unrelated.

> The first two cases make the secondary type (i.e. N or FN) 
> irrelevant, 

Yes indeed. They are "redundant" in that they encode the "same
information" in two different ways for which there is no well-defined
"mapping".