OPIMD: List of available attributes documented?
Michael Pilgermann
kichkasch at gmx.de
Sun Aug 9 12:54:06 CEST 2009
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-directory at 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 at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
More information about the community
mailing list