Subject: [Simple] FW: What is a Tuple -- categorizing rows

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 30 Jun 2003 11:16:58 -0400

Sorry, I addressed this message to the wrong list :(

-----Original Message-----
From: Rosen, Brian 
Sent: Monday, June 30, 2003 11:14 AM
To: [email-masked]'
Subject: What is a Tuple -- categorizing rows

One of the issues that was not resolved in the "what is a tuple"
design team was a problem that Robert characterizes as:
"whether a PA needs to expose the policy it used to create tuples
 to the watcher and whether a watcher needs to be able to request 
 a certain policy"

I am the main protagonist on this issue.  I hope we can have a good
discussion on the problem in Vienna, but for those of you not coming,
I think it would be a good idea to at least alert you to the problem.

First of all, I don't like characterizing the problem as "exposing
a policy".  I want the rows labeled with what they represent.  We
have at least three possible things a row can represent:
	a device
	a "service"
	a presentity

There might be more.  We agree that we don't have a good definition
of "service", but we can come up with examples.  One example is an
IM service that seamlessly migrates from one physical device to
another without the buddy's knowledge.  Another is a "find me
follow me" telephony service.  Services follow the definition of
a tuple given = a contact and a set of characteristics about that
contact.

The current proposal on the table is to represent the data the
PA has as a kind of table in a database.  The columns represent
characteristics (RPIDS items, for example).  The rows represent
a "pivot" of the table, using the kinds of operations a
database SQL SELECT statement might be able to accomplish.  In
particular, it would be some kind of rule based on columns.
The result of this would be a "view" of the data.  In this
design, if the raw data was something akin to a device, in theory,
you could define a pivot that made a "service" view, and
another that made a presentity view.

The majority of people on the design team believe that it is not
important for the watcher to know what the rows represent.
They can be anything (devices, services, presentities, or something
else), and the watcher doesn't care, or more precisely, can't
really do anything with any additional information about what
the rows represent.  

My opinion is that what the rows represent is essential information
for the watcher, so that it knows how to render the data, and so that
for watcher that are automatons, so that the automaton can correctly
process the information it is given.

In response to a request for an example, I offered the following:
> View presented from PA implementation 1
> 
> AOR             contact           media     status geoloc
> [email-masked]  [email-masked]  aud,vid,im open  x1,y1
> [email-masked]  [email-masked]  aud        open  x1,y1
> [email-masked]  [email-masked]  aud,vid,im open  x1,y1
> [email-masked]  [email-masked]  aud,im     open  x2,y2
> [email-masked]  [email-masked]     im         open  x3,y3
> 
> View presented from PA implementation 2
> 
> AOR             contact           media     status geoloc
> [email-masked]  [email-masked]  aud        open  x1,y1:x2,y2
> [email-masked]  [email-masked]  aud,vid    open  x1,y1
> [email-masked]  [email-masked]  im         open  x1,y1:x3,y3
> 
> View presented from PA implementation 3
> 
> AOR             contact           media     status geoloc
> [email-masked]  [email-masked]  aud,vid,im open  x1,y1:x2,y2:x3,y3
> 
> View presented from PA implementation 4
> 
> AOR             contact           media     status geoloc
> [email-masked]  [email-masked]  aud,im     open  x2,y2
> 
> All of these represent the same person, who happens to be in
> an associate's office a building away.
> 
> I claim that unless I very explicitly explain what each of these
> PA implementations represent, a watcher can't do anything intelligent
> with the data except print it out.  The last two are interesting.
> Implementation 3 does what I think a "pivot on AOR" means.  Implementation
> 4 is using information it has to make an intelligent guess as to 
> what is happening, to present the most likely state of the presentity.
> The PA, because it knows the presentity, can decide whether to offer
> IM or not.  Since the presentity is in the building, IM likely will work.
> If the presentity is, say, driving a car, it likely won't.  It's the
> PA that knows the limits of the campus to make the guess.  It is a guess.

I believe that while many systems will have device level data at
the PA, they will not offer that information to a watcher.  For
privacy and called party preference reasons, they will never
give you a device view.  They will only give you a presentity
view.  Normally, this would be one row in the proposed model.
It's possible that some systems will only give you a service view.

This mail is getting long, so I am going to stop here, but
my proposal is to have a characteristic for a view that presents
what the rows represent, which is a choice from an IANA registered
list, of which we will have three initial entries ('device', 'service',
'presentity') and an extension mechanism.  

Brian

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 30 Jun 2003 11:16:58 -0400

-----Original Message-----
From: Rosen, Brian 
Sent: Monday, June 30, 2003 11:14 AM
To: [email-masked]'
Subject: What is a Tuple -- categorizing rows

Brian