OPIMD: List of available attributes documented?

Al Johnson openmoko at mazikeen.demon.co.uk
Thu Aug 6 18:42:48 CEST 2009

On Thursday 06 August 2009, Sebastian Krzyszkowiak wrote:
> On 8/6/09, Al Johnson <openmoko at mazikeen.demon.co.uk> wrote:
> > On Thursday 06 August 2009, Michal Brzozowski wrote:
> >> 2009/8/5 Sebastian Krzyszkowiak <seba.dos1 at gmail.com>
> >>
> >> > This way you
> >> > could have for instance voip:dos at shr.com <voip%3Ados at 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:aaa at bbb'.
> >>
> >> How about putting the prefix in the attribute name. 'Peer_tel:' : '+xxx'
> >> or
> >> 'Peer_voip' : 'aaa at 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:username at example.com
X-FSO-TEXT;TYPE=home,cell:sip:username at example.com
X-FSO-VIDEO:TYPE=home:sip:username at 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.

More information about the community mailing list