Re: OPIMD: List of available attributes documented?
Hi, thx for the feedback. Keep it your way - I am going to change PISI ... Michael Sebastian Krzyszkowiak wrote: > > All of that field names are compatible with opimd client apps I > already wrote, except two little things: I have "E-mail", and "Home > phone", "Work phone" etc. (with space and with "p" instead of "P"). > Are you fine with it or I should change it in opimd-utils? > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
On 8/9/09, Michael Pilgermann wrote: > 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 All of that field names are compatible with opimd client apps I already wrote, except two little things: I have "E-mail", and "Home phone", "Work phone" etc. (with space and with "p" instead of "P"). Are you fine with it or I should change it in opimd-utils? -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
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 FEATURES8 > 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 >
Re: OPIMD: List of available attributes documented?
On Thursday 06 August 2009, Sebastian Krzyszkowiak wrote:
> On 8/6/09, Al Johnson wrote:
> > On Thursday 06 August 2009, Michal Brzozowski wrote:
> >> 2009/8/5 Sebastian Krzyszkowiak
> >>
> >> > This way you
> >> > could have for instance voip:d...@shr.com ,
> >> > skype:dos or something else.
> >> > But of course it would be nice to discuss it with FSO guys.
> >>
> >> You suggest 'Peer' : 'tel:+xxx' or 'Peer' : 'voip:a...@bbb'.
> >>
> >> How about putting the prefix in the attribute name. 'Peer_tel:' : '+xxx'
> >> or
> >> 'Peer_voip' : 'a...@bbb'.
> >>
> >> Now it's like nesting attributes in attributes. Why force people to
> >> additionally parse the data.
> >
> > If the content is a proper URI then we shouldn't have any trouble parsing
> > it.
> > tel: is the right way to start a phone number URI. See RFC3966. voip: is
> > probably wrong, but sip: or h323: are well defined.
> >
> > The problem here is having two fields but at least three independent
> > properties. We have at least:
> > * Communication medium (voice, text, video, etc.)
> > * The URI which gives protocol and address
> > * Disambiguation of more than one of the above, possibly indicating
> > association (Home, Office1, Office2, Mobile etc.)
>
> That's what we need :) Home, Mobile, Office etc. is done by prefixing
> field name ("Home phone", "Mobile phone"). URI is also there, but I
> don't have idea how to indicate and use communication medium. Does
> someone have any idea?
The medium and disambiguation parts are properties of the URI, and could have
multiple entries which may be interdependent. A SIP address is a fine example
of how it could get tricky since it could be used for voice, video or text,
but you may not have video capability on your phone SIP client like you do on
the PC at home. There may be other properties you want to associate too.
vCard partially expresses this with its TYPE= entry, and we could express it
something like:
X-FSO-VOICE;TYPE=home,cell:sip:usern...@example.com
X-FSO-TEXT;TYPE=home,cell:sip:usern...@example.com
X-FSO-VIDEO:TYPE=home:sip:usern...@example.com
It's a pain for interoperability though, like all vCard extensions.
Trying to squeeze this sort of data into two fields sounds like a bad idea to
me, but I'm not familiar enough with what's allowable in dbus to suggest
anything better.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
> 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 FEATURES8 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:/
Re: OPIMD: List of available attributes documented?
Am Donnerstag 06 August 2009 09:09:58 schrieb Michael Pilgermann: > Many thanks for all your input ... > I had noticed already by going through the opimd code / db scheme that the > selection of fields is dynamic. > > However, I think there is really a need to agree upon a common set of > attributes (maybe "core" attributes), which are supported. > > With the contacts-shr support for opimd (some additional phone-gui > packacke, I recently installed - which, by the way, is not working for me > yet due to some import error), it could be interesting, which fields are > used in there (well, that will be from my point of view the most frequently > used contacts app in the end) ... > > From my experiences with developing PISI as a contact sync engine, I > realized that fields "out there" are really different - e.g.: - LDAP (with > different schemes; for Contacts use additional mozilla scheme) - VCF-Files > (vcard) > - DB-Structures (e.g. QTopia) > > There is a "standard" available for PIM synchronization by OMA called SynML > (http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html) >. If you look at it, they use vcard (vcf) as well for carrying the content. > VCard is a standard - so it might be worthwile to take a deeper look in > which fields they are using and how they structure the content. > (http://www.imc.org/pdi/) > > Mike 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
On 8/6/09, Al Johnson wrote:
> On Thursday 06 August 2009, Michal Brzozowski wrote:
>> 2009/8/5 Sebastian Krzyszkowiak
>>
>> > This way you
>> > could have for instance voip:d...@shr.com , skype:dos
>> > or something else.
>> > But of course it would be nice to discuss it with FSO guys.
>>
>> You suggest 'Peer' : 'tel:+xxx' or 'Peer' : 'voip:a...@bbb'.
>>
>> How about putting the prefix in the attribute name. 'Peer_tel:' : '+xxx'
>> or
>> 'Peer_voip' : 'a...@bbb'.
>>
>> Now it's like nesting attributes in attributes. Why force people to
>> additionally parse the data.
>
> If the content is a proper URI then we shouldn't have any trouble parsing
> it.
> tel: is the right way to start a phone number URI. See RFC3966. voip: is
> probably wrong, but sip: or h323: are well defined.
>
> The problem here is having two fields but at least three independent
> properties. We have at least:
> * Communication medium (voice, text, video, etc.)
> * The URI which gives protocol and address
> * Disambiguation of more than one of the above, possibly indicating
> association (Home, Office1, Office2, Mobile etc.)
That's what we need :) Home, Mobile, Office etc. is done by prefixing
field name ("Home phone", "Mobile phone"). URI is also there, but I
don't have idea how to indicate and use communication medium. Does
someone have any idea?
--
Sebastian Krzyszkowiak
dos
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
On Thursday 06 August 2009, Michal Brzozowski wrote: > 2009/8/5 Sebastian Krzyszkowiak > > > This way you > > could have for instance voip:d...@shr.com , skype:dos > > or something else. > > But of course it would be nice to discuss it with FSO guys. > > You suggest 'Peer' : 'tel:+xxx' or 'Peer' : 'voip:a...@bbb'. > > How about putting the prefix in the attribute name. 'Peer_tel:' : '+xxx' or > 'Peer_voip' : 'a...@bbb'. > > Now it's like nesting attributes in attributes. Why force people to > additionally parse the data. If the content is a proper URI then we shouldn't have any trouble parsing it. tel: is the right way to start a phone number URI. See RFC3966. voip: is probably wrong, but sip: or h323: are well defined. The problem here is having two fields but at least three independent properties. We have at least: * Communication medium (voice, text, video, etc.) * The URI which gives protocol and address * Disambiguation of more than one of the above, possibly indicating association (Home, Office1, Office2, Mobile etc.) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
2009/8/5 Sebastian Krzyszkowiak > This way you > could have for instance voip:d...@shr.com , skype:dos > or something else. > But of course it would be nice to discuss it with FSO guys. > You suggest 'Peer' : 'tel:+xxx' or 'Peer' : 'voip:a...@bbb'. How about putting the prefix in the attribute name. 'Peer_tel:' : '+xxx' or 'Peer_voip' : 'a...@bbb'. Now it's like nesting attributes in attributes. Why force people to additionally parse the data. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
Many thanks for all your input ... I had noticed already by going through the opimd code / db scheme that the selection of fields is dynamic. However, I think there is really a need to agree upon a common set of attributes (maybe "core" attributes), which are supported. With the contacts-shr support for opimd (some additional phone-gui packacke, I recently installed - which, by the way, is not working for me yet due to some import error), it could be interesting, which fields are used in there (well, that will be from my point of view the most frequently used contacts app in the end) ... >From my experiences with developing PISI as a contact sync engine, I realized >that fields "out there" are really different - e.g.: - LDAP (with different schemes; for Contacts use additional mozilla scheme) - VCF-Files (vcard) - DB-Structures (e.g. QTopia) There is a "standard" available for PIM synchronization by OMA called SynML (http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html). If you look at it, they use vcard (vcf) as well for carrying the content. VCard is a standard - so it might be worthwile to take a deeper look in which fields they are using and how they structure the content. (http://www.imc.org/pdi/) Mike Original-Nachricht > Datum: Wed, 5 Aug 2009 23:57:13 +0200 > Von: Sebastian Krzyszkowiak > An: List for Openmoko community discussion > Betreff: Re: OPIMD: List of available attributes documented? > On 8/5/09, Michal Brzozowski wrote: > > 2009/8/5 Sebastian Krzyszkowiak > > > >> > >> opimd supports every field - you can add to contact whatever you want. > >> > > > > Isn't the data supposed to be shared across different clients? If yes, > then > > this should be part of the standard. Of course if I want to add dog-name > and > > cat-name then why not, but fields like Phone, Name, Sender, etc. should > be > > specified at docs.freesmartphone.org. > > I agree. So someone should do it :P > > > And the 'Phone' : 'tel: +xxx' thing doesn't make sense, I understand > it's a > > temporary situation. > > "tel:" was before I started to work on opimd, i think it's good idea > (but maybe it shouldn't be "tel:", but something else). This way you > could have for instance voip:d...@shr.com, skype:dos or something else. > But of course it would be nice to discuss it with FSO guys. > > -- > Sebastian Krzyszkowiak > dos > > ___ > 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
Re: OPIMD: List of available attributes documented?
On 8/5/09, Michal Brzozowski wrote: > 2009/8/5 Sebastian Krzyszkowiak > >> >> opimd supports every field - you can add to contact whatever you want. >> > > Isn't the data supposed to be shared across different clients? If yes, then > this should be part of the standard. Of course if I want to add dog-name and > cat-name then why not, but fields like Phone, Name, Sender, etc. should be > specified at docs.freesmartphone.org. I agree. So someone should do it :P > And the 'Phone' : 'tel: +xxx' thing doesn't make sense, I understand it's a > temporary situation. "tel:" was before I started to work on opimd, i think it's good idea (but maybe it shouldn't be "tel:", but something else). This way you could have for instance voip:d...@shr.com, skype:dos or something else. But of course it would be nice to discuss it with FSO guys. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
2009/8/5 Sebastian Krzyszkowiak > > opimd supports every field - you can add to contact whatever you want. > Isn't the data supposed to be shared across different clients? If yes, then this should be part of the standard. Of course if I want to add dog-name and cat-name then why not, but fields like Phone, Name, Sender, etc. should be specified at docs.freesmartphone.org. And the 'Phone' : 'tel: +xxx' thing doesn't make sense, I understand it's a temporary situation. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
On 8/5/09, Michael Pilgermann wrote:
> Hi,
> I am currently on the way of implementing OPIMD Contacts Domain
> integration in our PIM synchronization tool PISI.
> After having all the connectivity bits and pieces in place, it would be
> helpful to have an
>
> ** up-to-date list of attributes / fields **
>
> , which are supported in OPIMD (especially in SHR-Contacts). All I could
> find is this out-dated list:
> http://git.freesmartphone.org/?p=framework.git;a=blob_plain;f=framework/subsystems/opimd/docs/contact_fields.txt;hb=master
>
> Any idea, where I can get more recent information from?
>
> thx in advance,
> Mike
opimd supports every field - you can add to contact whatever you want.
SHR doesn't use opimd interface yet, but that's how I implemented some
"standard" fields in my opimd-contacts (and as i'm opimd developer, I
think it's safe to say they are prefered names for every opimd based
app):
Name, Surname, Phone, Whatever* phone, E-mail, Work e-mail, Home
e-mail, Whatever* e-mail
* - Replace "whatever" with phone/mail type (Work, Home etc.)
Every field can have multiple values, except Name field. If you want
to add two phones without type, just use array {'Name' : 'Someone',
'Phone' : ['tel:+4864324', 'tel:+3475345'], 'E-mail' : 'd...@shr.com'}
Also when adding phone number that's good to prefix it with 'tel:',
and 'mail:' with e-mails.
Could someone add what I wrote here to wiki somewhere? :)
--
Sebastian Krzyszkowiak
dos
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
>Also when adding phone number that's good to prefix it with 'tel:', >and 'mail:' with e-mails. > >Could someone add what I wrote here to wiki somewhere? :) i added it into http://wiki.openmoko.org/wiki/Opimd why would one want to prefix numbers and emails in fields and then parse it away again? besides that tel: means nothing in english really... Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OPIMD: List of available attributes documented?
Hi, I am currently on the way of implementing OPIMD Contacts Domain integration in our PIM synchronization tool PISI. After having all the connectivity bits and pieces in place, it would be helpful to have an ** up-to-date list of attributes / fields ** , which are supported in OPIMD (especially in SHR-Contacts). All I could find is this out-dated list: http://git.freesmartphone.org/?p=framework.git;a=blob_plain;f=framework/subsystems/opimd/docs/contact_fields.txt;hb=master Any idea, where I can get more recent information from? thx in advance, Mike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
