[ticker-dev] ticker-3.0 & presence spec

[Wanicki, Martin]

I like this as a concept, *but* I dont want to have to emit multiple
scope-based notifications.

as an example - in eTiks when you use the optional extra attribute  (I use
for domain scoping), it gets 
appended to EVERY emitted notification INCLUDING presence,
so I can set my presence info to "unavailable" for the world to receive,
then turn on the domain restriction attribute and send an 
"available"

the net result being the world thinks I'm unavailable and until I turn of
the domain restriction attribute, will continue to do so.

Course I realise this is NOT the best way to do this, but it IS a way to get
a square peg in a round hole :-/


some random thoughts....

changing a setting for a single status change to reflect all the different
ways I want this status change to be seen by different people
in different domains seems to be a little broken to me, perhaps I'm
misunderstanding.

The answer here seems to indicate a personal presence bot, that see's only
my presence info's and based on rules
emits the appropriate presence notification, properly scoped.
I certainly dont have the time or inclination to build this into etiks,
although this functionality *may* be desirable.

One could, of course, run multiple clients, each configured differently, but
i dont think thats the answer either.

Hmmm,

Distribution for presence doesnt really seem do-able,
I think we have a case for domain policy here in defining the status
descriptions that are allowable within a domain
something along the lines of the following .

	the status description "Meeting" is allowed beyond the domain
perimiter, but the 
	the status description "(Meeting)" is NOT allowed beyond the domain
perimiter.

I dunno what the answer is, it'd be really good if we could keep it simple
and elegant :-)

martin
> ----------
> From: 	Ian Lister[SMTP:ilister at dstc.edu.au]
> Sent: 	Thursday, April 11, 2002 2:27 PM
> To: 	ticker-dev at dstc.edu.au
> Subject: 	Re: [ticker-dev] ticker-3.0 spec
> 
> On Sat, 6 Apr 2002, David Arnold wrote:
> >2. Distribution
> >
> >   Matthew and Martin are keen to have this feature, possibly with
> >   standardised semantics for its values.
> 
> I have come to the conclusion that I would quite like this in the presence
> protocol too. I would like my co-workers to know that I am in some
> confidential meeting (hypothetically speaking) but I don't particularly
> want to tell the world (I just want them to know I'm in `a' meeting), or
> maybe I may not want other organisations to know that I'm off drinking
> beer at 10am on Monday (hypothetically speaking).
> 
> Thus, I would be able to specify one lot of status information and
> restrict it to be organisation local, and another lot for global
> distribution. I would send both these notifications in response to
> requests and administrative filters would cut out anything org local at my
> organisational boundaries (similarly for site boundaries, etc). Nearby
> clients would receive both lots of information and take the most local
> information as the most useful and display it, while people in other
> organisations would receive only the global information.
> 
> This would be another example of an attribute that can have a consistent
> meaning across several application domains, in this case allowing much
> easy federation config (this could even be put in the default config
> files).
> 
> Sorry if this mail is a bit scattered (it would just be reflecting me atm)
> but hopefully I've got my point across. Comments welcome :-)
> 
> Ian
>