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