Subject: RE: [Simple] presence-rules: Selecting on class

From: [email-masked]
Date: Mon, 17 Jan 2005 23:39:49 +0200

Hi,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Robert Sparks
> Sent: 15 January, 2005 16:18
> To: Simple WG
> Subject: [Simple] presence-rules: Selecting on class
> 
> 
> There is a piece of functionality missing from presence-rules that
> (I think) we were expecting to have.
> 
> A presentity needs to be able to expose tuples based on the class
> the presentity assigned to it (this was a primary motivator 
> of the class
> element if I understand it correctly, allowing me to group elements to
> expose to my family vs those I expose to my co-workers). Currently,
> there's no way to make that kind of transformation with a 
> presence-rule.
> 

Yes, I am expecting to be able to use class for that, although it might have other usages too. 

> Jonathan and I discussed this briefly - the idea that came out was to
> add one or more <class> elements  to <provide-services> that would
> only provide those services matching one of the stated classes.
> 

Yes, this is a good idea. 

> Thoughts?
> 
> I suspect we need this for <person> and <device> too?
> 

Yes, I support this too. In this case RPID needs to say that class applies to <tuple>, <person> and <device> (if the latest version already does not).

A follow-up question obviously is that how is the rule-maker able to know which class values a PUA is going to use. If they are co-located, it's easy, but if the user has e.g. multiple devices, this gets more difficult. But that is a separated problem from the presence-rules. 

> RjS

Markus

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jan 2005 18:44:00 -0500

> Yes, I support this too. In this case RPID needs to say that class
> applies to <tuple>, <person> and <device> (if the latest version
> already does not).

The current draft does.

> 
> A follow-up question obviously is that how is the rule-maker able to
> know which class values a PUA is going to use. If they are
> co-located, it's easy, but if the user has e.g. multiple devices,
> this gets more difficult. But that is a separated problem from the
> presence-rules.

The idea for <class> was to have some notion of higher-level 
coordination, possibly at the service (not in the SIMPLE sense) or human 
level.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jan 2005 18:45:48 -0500

>>there's no way to make that kind of transformation with a 

Be sure not to confuse <class> with <sphere>. Class might be used for 
something like labeling "sensitive information"  vs. "public 
information" or "primary information" vs. "secondary information".

Generally, the same tuple would keep the same class, while my sphere 
changes throughout the day.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Jan 2005 18:07:24 -0600

I had no confusion. <sphere> is definitely a different beast,
and -rules- deals with the presentity's current <sphere> just fine.

I may have raised a flag for you when I used family and co-workers as
examples. I can have a set of tuples that I provide to my family only 
if I
happen to be at work. The rule will match I'm at work based on sphere,
that set of tuples will be added by transformations based on class.

RjS

On Jan 17, 2005, at 5:45 PM, Henning Schulzrinne wrote:

>>> the presentity assigned to it (this was a primary motivator of the 
>>> class

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Jan 2005 21:18:47 -0500

[email-masked] wrote:

>> class element if I understand it correctly, allowing me to group
>> elements to expose to my family vs those I expose to my
>> co-workers). Currently, there's no way to make that kind of
>> transformation with a presence-rule.
>> 
> 
> 
>> Jonathan and I discussed this briefly - the idea that came out was
>> to add one or more <class> elements  to <provide-services> that
>> would only provide those services matching one of the stated
>> classes.
>> 
> 
> 

I am fine with this, and will add class-based selectors to the 
provide-service, provide-device and provide-person elements.

I'll note that we never really concluded on the issue of multiple person 
elements in a document. There did appear consensus (though I personally 
still disagree) to support multiple person elements in a document in 
order to represent conflicting data about a person. This raised several 
questions we need to answer:

1. how to distinctly identify each one of them?

I'd propose that we keep this really simple for now and just use an "id" 
attribute of the <person> element.

2. what kind of meta-data do we need to provide the watcher the tools 
they need to pick a particular source of data?

I'd propose that, for now - nothing.

3. impact on the data model

I'd actually like to keep the underlying model in the document, which 
says that there is one person; this is still true - we are still talking 
about ONE person, its just that we have multiple conflicting pieces of 
information about that person, and so have chosen the syntactic approach 
of using multiple <person> elements to convey this.

Thanks,
Jonathan R.

> _______________________________________________ Simple mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Jan 2005 09:28:04 -0600

Jonathan Rosenberg wrote:
> order to represent conflicting data about a person. 

Jonathan:

Let me back up one step.  Multiple person elements can appear
where -- in the raw presence document or the final presence
document?  I think in the final presence document, there should
be only one person element.  My preference would be to have a
single person element even in the raw presence document,

 > they need to pick a particular source of data?

If we go through the trouble of providing meta-data, might as
well resolve the ambiguity and present one person element to
the watcher.

Conflicting data about a person, even if it appears in the
system, should be for a short time (my computer at work reports me
as being "Away" while my computer at home reports me as being
"Available").  The frequency of presence state updates coming from
my work computer would be far less than the frequency of state
updates coming from devices that I am interacting with in my home.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jan 2005 11:52:43 -0500

Vijay K. Gurbani wrote:
>> I'll note that we never really concluded on the issue of multiple 
>> person elements in a document. There did appear consensus (though I 
>> personally still disagree) to support multiple person elements in a 
>> document in order to represent conflicting data about a person. 

You are heading down the slippery slope.

We wanted to allow this because we want to allow use of a simple 
composition policy that doesn't know how to resolve the ambiguity, and 
so wants to leave it to watchers to resolve.

That doesn't mean that smarter composition policies aren't desired. I 
think that is a slope we want to start down at some point. Just not yet.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Jan 2005 11:09:11 -0600

> so wants to leave it to watchers to resolve.

Paul:

A composition policy, as its name suggests, should compose; i.e.
take something abstract and make it more concrete.  If it does
not do so, then ambiguous data is propagated further into the
system, gumming up even more machinery it touches.

IMHO, a watcher would be content to do as less as possible;
operational experience in SIP appears to suggest this.  Forking,
response aggregation and transport conversion are not the domain
of proxies alone; SIP endpoints themselves can perform these.
However, of all the many endpoints that I have used, not one
of them did these things.

Personally, I think the presence problem is complex enough without
adding another layer (my head hurts as I try to make sense of
all of this; but maybe it is just me).  As Jonathan said, even
if we did allow for multiple person elements, the model itself
still revolves around one person.  If so, why not just enforce
that in the representation of the model?

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jan 2005 13:19:29 -0500

Vijay K. Gurbani wrote:
> take something abstract and make it more concrete. 

I disagree with you about what compose means. Its not about going from 
abstract to concrete. Going from

{W,X} + {Y,Z} to {W,X,Y,Z}

is a perfectly valid kind of compostion that has no change in 
abstractness. And going from:

{W=A, X=B} + {W=C, Z=D} to {X=B, Z=D}

is another valid kind of composition that becomes more abstract (or at 
least less specific.)

> If it does

Some of us believe that ambiguous data is preferable to wrong data or no 
data.

> IMHO, a watcher would be content to do as less as possible;

In some cases. And one solution to that would be for a watcher UA to 
simply not display ambiguous data. Then at least it is the watcher 
making that decision for its user.

I think what you may really mean is that accurate data is better than a 
bunch of ambiguous data that might contain accurate data. To the extent 
that somebody knows how to draw the distinction, I agree.

But if my boss' status says both "Out to Lunch" and "In a Meeting", then 
I think I may well have a better chance of deciding which is right than 
some stupid composer that hasn't been customized for his ideosyncracies.

> that in the representation of the model?

The layer is there already. It got there when we acknowledged there 
could be multiple sources of presence information. It is designing a 
composition algorithm that does the "right" thing with this information 
that makes my head hurt. This is one of those cases where something easy 
for people is really hard for a computer.

I am pretty sure that it will be impossible to devise a compostion 
algorithm that does the "right" thing without a bunch of 
presentity-specific heuristics. I think such a thing can be designed and 
built. And probably used to great success by geeks like us. I have much 
less confidence that it can be built in such a way that those heuristics 
can be entered for all of the unwashed masses that use communications 
devices.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Jan 2005 12:59:58 -0600

> {W=A, X=B} + {W=C, Z=D} to {X=B, Z=D}

I actually see this as good composition; in both your examples,
we took _two_ sets and composed them into _one_ set -- a good start.
We went from abstract to concrete.  By allowing multiple person
elements, we are essentially doing this to your example:

    {W, X} + {Y, Z} => {W, X} + {Y, Z}

basically, nothing.

> could be multiple sources of presence information. 

In my email, the use of the word "layer" was not right; I intended
to say that "the presence problem is complex enought without
adding another potential source of ambiguity in the form of
multiple person elements."

> can be entered for all of the unwashed masses that use communications 

I am not sure what the right answer is, if there is one.  Unlike
you, though, I am not convinced that having the person element
recur is advantageous.

 > Some of us believe that ambiguous data is preferable to wrong
 > data or no data.

Ambiguous data is definitely preferable to no data; I am not sure
about its preference over with "wrong" data.  Both ambiguous and
wrong data tend to condition the watcher into _not_ believing in
the presence system.

Thanks,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Jan 2005 21:05:44 -0500

Vijay:

we had this discussion, at length, in DC. The problem is that the 
composer is a program, with at best limited rule-based intelligence, 
while the watcher is often staffed with a real human being that can, in 
many cases, make sense of conflicting information based on external 
knowledge ("I know that Alice is on vacation right now, so the location 
information placing her at home in this person entry must be from the 
cell phone she left at home.")

I'm afraid I don't trust AI enough to force the composer throw away 
useful information.

There's also the issue that composition may be "staged", i.e., my 
provider has a dumb union-of-inputs composer provided by my cellphone 
carrier, which feeds a much smarter composer. Forcing the first composer 
to ditch information is a bad idea then as well.

Meta-information is helpful, but not necessary, to make such decisions.

The basic rule should be, I believe, "composers are allowed to be smart, 
but we can't force them to be".

Henning

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 23 Jan 2005 01:58:37 -0600

> while the watcher is often staffed with a real human being that can, in 

Prof. Schulzrinne:

Thanks.  I was just seeing if there is any wiggle room left, but
since this is a closed issue, I will shut up now.

I will like to request though, if possible, that the reason why
we are allowing multiple person elements be explained in the
draft.  Often times, it helps if the reader (or developer)
of a protocol knows why decisions were made in a certain manner.

Sincerely,

- vijay

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 24 Jan 2005 17:05:05 +0100

Keep in mind that we are not disallowing composition of <person> 
elements to happen at the compositor. What we are doing is allowing 
composition to take place at the UA or even at the user level, if the 
compositor is not intelligent enough to do so.

Regards,
Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jan 2005 18:36:53 -0500

> I actually see this as good composition; in both your examples,

Well, sure it is. The prior one is composition, while this one is an 
example of the kind of composition Henning was talking about long ago.

It takes the position that the two documents have two equally valid 
conflicting values of reality, and that conflict should be resolved by 
deciding we know nothing useful.

This is a good thing to do in some cases, and a really bad thing to do 
in other cases. The trick is knowing when it is a good thing. IMO it is 
not a good thing to do by default.

> We went from abstract to concrete. 

Your concept of abstraction must be different from mine. The two input 
sets are both concrete. The result also seems concrete. Maybe it is a 
bit more abstract because it has removed the specification of an attribute.

> By allowing multiple person

No. originally there were two published presence documents, but neither 
was available to the watcher. The compostion makes the contents of both 
into a single document that can be provided to a watcher. So it has 
definitely done something. If you like, write it as:

     {W, X} + {Y, Z} => ({W, X}, {Y, Z})

> multiple person elements."

That only changes the words, not the point. The ambiguity is already 
there as two input presence documents with conflicting information. The 
composition is not making anything worse. It is simply failing to make 
it better - not because it doesn't want to, but because it doesn't know how.

>> presentity-specific heuristics. I think such a thing can be designed 
>> and built. And probably used to great success by geeks like us. I have 
>> much less confidence that it can be built in such a way that those 
>> heuristics can be entered for all of the unwashed masses that use 
>> communications devices.
> 

Nobody disagrees that smart, correct, composition is better than 
composition by union. We just don't know how to do it yet.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Wed, 26 Jan 2005 13:44:08 +0200

Paul, I agree with you 100%.

Cheers,
Aki

ext Paul Kyzivat wrote:
>>> composition policy that doesn't know how to resolve the ambiguity, 
>>> and so wants to leave it to watchers to resolve.
>>
>>
>>
>> Paul:
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jan 2005 07:01:21 -0500

inline.

> of a protocol knows why decisions were made in a certain manner.

I think the discussion is similar to the one that needs to be there for 
services. Why would you have multiple service elements? Why multiple 
person elements? Well, the answer in both cases is that the meaning is 
"ambiguous" and there are at least several known reasons why this might 
occur:

1. conflicting data provided by multiple sources
2. failed override attempt
3. some kind of capability expression

the way to disambiguate is through meta-data that needs to be defined in 
extensions to Pidf, of which we have none at the moment.

Thanks,
Jonathan R.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 28 Jan 2005 12:59:48 -0600

Jonathan Rosenberg wrote:
vkg> I will like to request though, if possible, that the reason why
vkg> we are allowing multiple person elements be explained in the
vkg> draft.  Often times, it helps if the reader (or developer)
vkg> of a protocol knows why decisions were made in a certain manner.
jdr>
jdr>
jdr> I think the discussion is similar to the one that needs to be
jdr> there for services. Why would you have multiple service elements?
jdr> Why multiple person elements?

Jonathan:

Logically, having multiple instances of the service tuple
makes sense.  After all, a person _can_ have multiple services.
Sure, some of the service tuples may be a result of ambiguity,
but others will not, and will represent discrete services available
to the person.

Whereas, all our lives we are taught that each person is unique ;-)

Think of a developer making sense of the PDM and the XML that
has to be generated for it; multiple person elements may only
serve to confuse the poor developer who may not be fully
aware of the implications on why this is so.

jdr> Well, the answer in both cases is that the meaning is
jdr> "ambiguous" and there are at least several known reasons why
jdr> this might occur:
jdr>
jdr> 1. conflicting data provided by multiple sources
jdr> 2. failed override attempt
jdr> 3. some kind of capability expression
jdr>
jdr> the way to disambiguate is through meta-data that needs to be
jdr> defined in extensions to Pidf, of which we have none at the moment.

I believe that we have some meta-data in the form of
prescaps; we probably need to scratch the surface to figure
out what other meta-data makes sense.

Thanks,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 Jan 2005 14:48:13 -0500

> extensions to Pidf, of which we have none at the moment.

I'm not sure I completely agree. I would consider notes and timestamps 
to be 'meta data' in this context which, in some cases, will allow the 
recipient to make reasonable judgements if presented with conflicting 
information. I wish we had more such data, but there's a limited supply 
of "hard" metadata. The only major item we're missing is probably a 
better description of the source of the data (calendar vs. manual entry 
vs. a device vs. compositor). Other meta data is likely to be "soft", 
e.g., indications of likelihood of correctness. Given that people still 
play PowerBall, I wouldn't put too much stock in people getting 
probabilities right.