CardBook alters underlying vCard fields

Cardbook for Thunderbird Forums Main Forum CardBook alters underlying vCard fields

Viewing 15 reply threads
  • Author
    • #3015

      Thunderbird 78.3.2 (32-bit)
      CardBook 52.4

      CardBook, after syncing a contact from NextCloud Contacts, appears to convert the vCard entries as shown below, subsequently syncing those changes back to NextCloud, screwing up the contacts in the process. (ignore line wrap in this post, vCard has 75 octet line length limit and wrapping rules which are not followed when displayed in this forum)

      ADR;PREF=10;TYPE=OTHER:;;Unit 2\, 83 Bream Street;Coogee;New South Wales;20

      converts to

      ITEM1.ADR;TYPE=PREF:;;Unit 2\, 83 Bream Street;Coogee;New South Wales;2034;


      TEL;PREF=1;TYPE=CELL;VALUE=UNKNOWN:+61 xxx xxx xxx

      converts to

      TEL;TYPE=PREF;TYPE=CELL:+61 xxx xxx xxx

      The end result being a loss of preferred order, as indicated by the PREF entry whose value defaults to 1 or may be 1..100

      Technically conversion of ADR to ITEM1 should result in the same UI experience but IMHO, the conversion should not happen.

      • This topic was modified 3 months ago by lyallplyallp. Reason: Reemove spans
    • #3019

      long time ago, Cardbook supported these pref values, but as strictly nobody uses this, and thus most of servers do not support this, I’ve removed it…

      same for the types, I now support without ITEM* only the types provided by Google, Apple and NextCloud…

      supporting strictly the vCard norm implies not to be supported by most of servers…

      I’d like to provide the support for the RELATED field, but this seems almost impossible to achieve as servers do not support this field with the urn:uuid values…

    • #3020

      I am confused now, CardBook Thunderbird UI provides little + and - buttons to alter the order of multiple entries, such as emails.

      Surely the order is lost if the PREF=1..100 other than physical order of the VCard?

      It is understandable that TYPE=PREF would identify the preferred entry, as opposed to PREF=1;TYPE=home

      I also just found out that I am looking at vCard 4.0 RFC, PREF is vCard 4.0, not 3.0, so examining a contact vCard which contains PREF is technically vCard 4.0.

      I suspect that CardBook is receiving a vCard which is labelled as Version 3.0 yet contains some 4.0 fields and an underlying library is converting from vCard 4.0 to vCard 3.0, losing PREF in the process, regardless of the VERSION field of the vCard.

    • #3021

      the + and – signs are just for the order of the emails, nothing to do with the PREF=82 property

      the PREF difference between 3.0 and 4.0 version should be correctly handled. The conversion should also be OK for this point…

      for the fields like GENDER which are 4.0 only, thes are converted to custom fields when they are converted to 3.0

    • #3022

      the + and – signs are just for the order of the emails, nothing to do with the PREF=82 property

      I understand that the + and – signs probably re-order the emails (for example) within the vCard, but according to the vCard 4.0, PREF defines the logical order of emails (for example) which may be different to the physical order of the vCard.

      So, given PREF by itself defaults to 1, entries would be displayed in PREF order, TYPE=PREF would equate to a PREF=0 internally, for the sake of simplicity. Physical order if no PREF or TYPE=PREF.

      In effect, the + and – buttons will swap the PREF value of the entry above/below and then swap the two entries visually, not necessarily altering the order of the vCard.

      vCard 3.0 has no PREF, so TYPE=PREF and physical order are all you have.

      At least, that is how I understand it. Correct me if I am wrong, which is quite possible!

    • #3025

      in CardBook, entries (3.0 and 4.0) are not displayed in PREF order. I disagree that in 4.0 , PREF defines the logical order. In 4.0 PREF=1 is equal to TYPE=PREF in 3.0


    • #3026

      in CardBook, entries (3.0 and 4.0) are not displayed in PREF order. I disagree that in 4.0 , PREF defines the logical order. In 4.0 PREF=1 is equal to TYPE=PREF in 3.0

      Excuse my verbosity.

      My discussion is about vCard Version 4.0, given 3.0 does not have PREF. Although, NextCloud can generate PREF in VERSION=3.0 vCards.

      I agree that entries are not displayed in PREF order but the order they appear in the vCard and that TYPE=PREF have the yellow star.

      I argue that, as a minimum, the entry with the lowest PREF value has its star yellow, even if the order of display is not affected.

      TYPE=PREF would be used to identify preferred entry if no PREF entries.

      You confirmed my understanding, PREF=1 == TYPE=PREF, so, PREF=2..100 on another entry of the same type indicates no yellow star. There may be additional entries of the same type but not having a PREF value would not have a yellow star.

      If no entries of the same type have a PREF entry, yellow star would be shown for TYPE=PREF entries, there may be multiple entries with TYPE=PREF in which case, they would each have yellow stars.

      If no entries have a PREF or a TYPE=PREF, then, technically, the first physical entry for that type, would have yellow star.

      <h3><span style=”font-size: 10px;”>5.3. PREF</span></h3>

      <span style="font-size: 10px;">   The PREF parameter is OPTIONAL and is used to indicate that the
         corresponding instance of a property is preferred by the vCard
         author.  Its value MUST be an integer between 1 and 100 that
         quantifies the level of preference.  Lower values correspond to a
         higher level of preference, with 1 being most preferred.
         When the parameter is absent, the default MUST be to interpret the
         property instance as being least preferred.
         Note that the value of this parameter is to be interpreted only in
         relation to values assigned to other instances of the same property
         in the same vCard.  A given value, or the absence of a value, MUST
         NOT be interpreted on its own.
         This parameter MAY be applied to any property that allows multiple
    • #3027

      Oh, by the way, NextCloud Contacts, with which I sync CardBook, inform me that should a vCard v4.0 be loaded in contacts, a vCard v4.0 is synced out to clients.

      Does CardBook convert synced vCards from v4.0 to v3.0?

      It certainly converts to v3.0 if I export a newly loaded vCard v4.0 synced from NextCloud, CardBook creates v3.0 for download.

    • #3028

      if a vCard has  TYPE=PREF or PREF or  PREF=2..100 ,Cardbook will display a blue star in CardBook tab… these all are PREF email (the yellow star in Thunderbird email is a different thing : it is based on the presence of an email).

      if I understand correctly, you argue that for PREF=2..100 only the highest preference should be considered as the PREF email ? I disagree with that, following the bold text above, the less preferred email is nevertheless a preferred email…

      and when no PREF is set, the rfc does not say that the first one should be the PREF one

      sorry if I have trouble in understanding as I’m doing multiple things at the time, and I’m definitely not done for that :O)

    • #3029

      when you create your CardBook address book, you choose the version that should be used (3.0 or 4.0) and yes CardBook convert vCards…

    • #3030

      This is all very complicated.

      My CardBook Address book is vCard 3.0.

      I have re-created my CardBook AddressBook as v4.0

      Sync from NextCloud seems mostly ok, except all PREF fields are set to 1.

      Once iPhone gets hold of the contact, via NextCloud sync, all things go to hell in a hand basket with emails and addresses converted to ITEM# entries, which royally screws the display of the contact in NextCloud Contacts.

      I recreated the AddressBook as v3.0, iPhone still screws the vCard, but still, CardBook deals with the altered vCard better than NextCloud Contacts, which does not display the ITEM# fields 🙁

      I will continue to fiddle, and report back.

    • #3033

      just one question : why don’t you sync your iphone with iCloud ?

    • #3034

      I prefer to host my own, having been burnt by things such as Google Reader, which was closed down.

      Hosting my own, I know where the data is and it will stay around as long as I host the data, I am not dependant on a company or service which may disappear in the future.

      I am starting to regret diving down this rabbit hole 🙂 I am looking at NextCloud database and seeing data I expect.

      Where does CardBook store it’s data, a SQLLite DB? If so, I could validate the sync data between NextCloud and CardBook.

      I have not yet given up on what I see as iPhone corrupting the vCard but I need to eliminate 2 of 3 things. NextCloud, CardBook or iPhone.

      I am starting to feel like a Gooney bird, flying in smaller and smaller circles until it disappears up it’s own a***ole. 🙁


    • #3035

      CardBook data are stored in a indexedDB stored under your Thunderbird profile (in storage subfolder)

      I don’t if that may help but iCloud deals only with 3.0 vCards (and deals very well)

    • #3039

      I use NextCloud, Contacts App, synced to both iPhone and email client Thunderbird CardBook addon.

      They all fight each other during sync.

      Ok, NextCloud Contacts will load and store vCard 4.0.

      CardBook add-on syncs, throws away stuff like PREF=<anything other than 1>

      iPhone converts many fields to ITEM#

      CardBook does a reasoable job of displaying all the fields resulting from the iPhone mash up, except RELATED

      NextCloud Contacts, whilst having all the info in the knackered vCard from the iPhone,
      does not display any ITEM# fields.
      Things like a second ADR whilst converted to an ITEM#, by the iPhone sync,
      are no longer displayed, same with RELATED and ALL Email entries.

      The iPhone seems to do a good job after it has knackered the vCard.
      Next comes CardBook addon, does a reasonable job of dealing with the iPhone generated vCard.
      Last is NextCloud Contacts, which successfully stores the vCard, is the worst
      at coping with the fields and displaying them.

      It appears I must choose a platform as my ‘reference’ and ignore the other two.

      I dont use any web based services because I cannot guarantee they will be there
      tomorrow or that they wont charge for service, take Google Reader as an example.

      sigh… this issue is a combination of 3.

    • #3040

      the RELATED field is good example : NextCloud and Apple use texts to add relationships and do not use UID which has much more sense…

Viewing 15 reply threads
  • You must be logged in to reply to this topic.