[ticker-dev] Elvin presence specification extension ?

[Wanicki, Martin]

Dear All


I had some ideas about an autoresponder providing information about the
human operating the client as an extension of the presence protocol.

The basics are that rather that having to maintain a central database of,
say phone numbers, if a client is configured
with details about the person, and is set to respond to "finger" type
queries than it should. But we need a spec and protocol to ratify this so
that all clients exporting this functionality have the same interface.

I'm imagining getting a message dialog saying something like "foo" has
requested personal information - do you wish to provide it"

The way this could work with the presence protocol is that a client could be
configured to automatically respond to people in your group but to prompt
you if a request comes from outside the group or completely ignore requests
not from your group or from anywhere.

There should always be a reply, even if it's just to say the request was
denied.

I'm suggesting the contents of the provision of information be completely at
the users discretion.
but the notification format of the response be defined

There's some issues that I'm not too clear on...

Do we closely couple this with the presence protocol or do we allow ticker
queries like

	Info bill at hq? 

and if we allow this type of query do we also map the responses into an
overloaded ticker notification spec??

so the coupling to spec needs some discussion.

Assuming a close coupling with the presence spec.

The notification format for a response begins with the all the fields of a
presence Info notification with the exception of status change,text and
duration.

First we add the type "Info" to the contents of Presence-Info attribute...
if we are replying with Info and
the type 'Info-denied' if we are not replying with Info.   The subscriptions
are obvious.
If the type is "info" then..
	User becomes whatever name the user want to provide
	Next we add "User-Phone" for ....(bet you cant guess :-) Populated &
mandatory 
	Then we add "User-Email" for (once again...)	Populated &
mandatory 

the rest of the data is entirely optional, maybe we can use some sort of
e-card in a mime field or we just define optional attribute names..
here's some ideas and a start - but this is not a definitive list ..

Then we add "User-Address" 		optional !	
Then we add "User-Sex" ..  		optional !
Then we add "User-Age" ..  		optional !
Then we add "User-Age" ..  		optional !


This idea really just came out of the phone bot that bill wrote for dstc.
I wrote an ldap lookup bot that handles a variety of lookups (phone, email,
..etc) 
Then I thought about a group of people not members of the same organization,
that interact 
regularly & freely share their location, email and phone number information.

I also thought about the notion that people within an organization can be
responsible for maintaining the availability of "current"
information about them. 

Over to the tickerdev crew ... your thoughts ?? 


Cheers

Martin 








Retain