Hi,
InfCloud 0.13.2.rc1
When a contact is synced in that has an FN field but no N field, the entry in InfCloud becomes nameless. The contents of the FN seems to be ignored completely.
Would it be possible (feasible, acceptable, allowed) to infer name fields from FN?
-- Johan
Hi Johan,
according to vCard 3.0 RFC at https://tools.ietf.org/html/rfc2426#section-3.1.2 https://tools.ietf.org/html/rfc2426#section-3.1.2
Type name: N Type special note: ... The property MUST be present in the vCard object.
The problem with the FN attribute is that you usually have an interface where you can choose the order of columns (e.g. First, Last) and also the sorting of columns (e.g. Last, First). In this case the information in FN is completely useless because you don't know which part of FN is the last and which is the first name.
So InfCloud completely ignores the content of FN, but when you create a new (or edit an old) contact if fills the FN according to settings in config.js for older clients ... there is clearly no "good" solution if someone ignores the RFC.
JM
On 20 Dec 2019, at 09:50, Johan Vromans jvromans@squirrel.nl wrote:
Hi,
InfCloud 0.13.2.rc1
When a contact is synced in that has an FN field but no N field, the entry in InfCloud becomes nameless. The contents of the FN seems to be ignored completely.
Would it be possible (feasible, acceptable, allowed) to infer name fields from FN?
-- Johan
On Fri, 20 Dec 2019 12:26:39 +0100, Ján Máté jan.mate@inf-it.com wrote:
according to vCard 3.0 RFC at https://tools.ietf.org/html/rfc2426#section-3.1.2 https://tools.ietf.org/html/rfc2426#section-3.1.2
Type name: N Type special note: ... The property MUST be present in the vCard object.
According to vCard RC at https://tools.ietf.org/html/rfc6350#section-6.2.2 (which explicitly obsoletes RFC 2426):
6.2.2. N
Cardinality: *1
(Cardinality *1 means: zero or one)
This makes it a bit harder to point to the other party as ignoring the RFC -- there seems to be no consensus about 'the RFC'.
... In this case the information in FN is completely useless because you don't know which part of FN is the last and which is the first name.
True. But it could be better to put the complete FN content into the surname part so it is at least visible and retained, than to ignore it.
-- Johan
Hi Johan,
thats RFC for vCard 4.0 not 3.0 ...
JM
On 20 Dec 2019, at 2:24 PM, Johan Vromans jvromans@squirrel.nl wrote:
On Fri, 20 Dec 2019 12:26:39 +0100, Ján Máté jan.mate@inf-it.com wrote:
according to vCard 3.0 RFC at https://tools.ietf.org/html/rfc2426#section-3.1.2 https://tools.ietf.org/html/rfc2426#section-3.1.2
Type name: N Type special note: ... The property MUST be present in the vCard object.
According to vCard RC at https://tools.ietf.org/html/rfc6350#section-6.2.2 (which explicitly obsoletes RFC 2426):
6.2.2. N
Cardinality: *1
(Cardinality *1 means: zero or one)
This makes it a bit harder to point to the other party as ignoring the RFC -- there seems to be no consensus about 'the RFC'.
... In this case the information in FN is completely useless because you don't know which part of FN is the last and which is the first name.
True. But it could be better to put the complete FN content into the surname part so it is at least visible and retained, than to ignore it.
-- Johan