On 8/6/09, Al Johnson <openm...@mazikeen.demon.co.uk> wrote:
> On Thursday 06 August 2009, Michal Brzozowski wrote:
>> 2009/8/5 Sebastian Krzyszkowiak <seba.d...@gmail.com>
>>
>> > This way you
>> > could have for instance voip:d...@shr.com <voip%3a...@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

Reply via email to