Well, for now I simly used the ones that were documented already and added fields I use for PISI - the outcome:
Name Middlename Surname Email Phone / CellPhone HomePhone WorkPhone HomeStreet HomePostalCode HomeCity HomeCountry HomeState Organisation BusinessPostalCode BusinessStreet BusinessCity BusinessCountry BusinessState FaxPhone Title Departement However, this is subject to change as soon as somehow a decision regarding the fields has been achieved. Enjoy your weekends Michael Michael Pilgermann wrote: >> I would vote for syncML structure, even opimd can hold a more flexible >> structure. But syncML is used in a lot of phones and this way i can be >> easier >> to integradte opimd in exisiting sync programms, perhaps on windows too. >> >> So syncML: +1 >> >> Thomas >> > which would mean, that we are looking into VCard - here table of contents for > the fields taken from the RFC2426 (VCard 3.0, > http://www.ietf.org/rfc/rfc2426.txt): > > 3. VCARD PROFILE FEATURES........................................8 > 3.1 IDENTIFICATION TYPES .......................................8 > 3.1.1 FN Type Definition ......................................8 > 3.1.2 N Type Definition .......................................9 > 3.1.3 NICKNAME Type Definition ................................9 > 3.1.4 PHOTO Type Definition ..................................10 > 3.1.5 BDAY Type Definition ...................................11 > 3.2 DELIVERY ADDRESSING TYPES .................................11 > 3.2.1 ADR Type Definition ....................................11 > 3.2.2 LABEL Type Definition ..................................13 > 3.3 TELECOMMUNICATIONS ADDRESSING TYPES .......................13 > 3.3.1 TEL Type Definition ....................................14 > 3.3.2 EMAIL Type Definition ..................................15 > 3.3.3 MAILER Type Definition .................................15 > 3.4 GEOGRAPHICAL TYPES ........................................16 > 3.4.1 TZ Type Definition .....................................16 > 3.4.2 GEO Type Definition ....................................16 > 3.5 ORGANIZATIONAL TYPES ......................................17 > 3.5.1 TITLE Type Definition ..................................17 > 3.5.2 ROLE Type Definition ...................................18 > 3.5.3 LOGO Type Definition ...................................18 > 3.5.4 AGENT Type Definition ..................................19 > 3.5.5 ORG Type Definition ....................................20 > 3.6 EXPLANATORY TYPES .........................................20 > 3.6.1 CATEGORIES Type Definition .............................20 > 3.6.2 NOTE Type Definition ...................................21 > 3.6.3 PRODID Type Definition .................................21 > 3.6.4 REV Type Definition ....................................22 > 3.6.5 SORT-STRING Type Definition ............................22 > > There would be another advantage - in field parsing (e.g. for addresses) > couuld be done by already available libraries for VCard processing. > However, it would not solve the problem with the phone communication medium: > > The RFC says: > > 3.3.1 TEL Type Definition > > To: ietf-mime-direct...@imc.org > > Subject: Registration of text/directory MIME type TEL > > Type name: TEL > > Type purpose: To specify the telephone number for telephony > communication with the object the vCard represents. > > Type encoding: 8bit > > Type value: A single phone-number value. > > Type special notes: The value of this type is specified in a > canonical form in order to specify an unambiguous representation of > the globally unique telephone endpoint. This type is based on the > X.500 Telephone Number attribute. > > The type can include the type parameter "TYPE" to specify intended > use for the telephone number. The TYPE parameter values can include: > "home" to indicate a telephone number associated with a residence, > "msg" to indicate the telephone number has voice messaging support, > "work" to indicate a telephone number associated with a place of > work, "pref" to indicate a preferred-use telephone number, "voice" to > indicate a voice telephone number, "fax" to indicate a facsimile > telephone number, "cell" to indicate a cellular telephone number, > "video" to indicate a video conferencing telephone number, "pager" to > indicate a paging device telephone number, "bbs" to indicate a > bulletin board system telephone number, "modem" to indicate a MODEM > connected telephone number, "car" to indicate a car-phone telephone > number, "isdn" to indicate an ISDN service telephone number, "pcs" to > indicate a personal communication services telephone number. The > default type is "voice". These type parameter values can be specified > as a parameter list (i.e., "TYPE=work;TYPE=voice") or as a value list > (i.e., "TYPE=work,voice"). The default can be overridden to another > set of values by specifying one or more alternate values. For > example, the default TYPE of "voice" can be reset to a WORK and HOME, > VOICE and FAX telephone number by the value list > "TYPE=work,home,voice,fax". > > Type example: > > TEL;TYPE=work,voice,pref,msg:+1-213-555-1234 > > So, we could / should combine several type-values for one entry (list). Any > way to put this into the implementation? > > Mike > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community