Subject: Re: [Simple] Tuple design team discussion summary

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Jul 2003 08:00:25 -0400

I agree with all of this. However, I think the cost of the flexibility 
in this model is that we need some additional features from RPIDS to 
help the watcher determine what is meant by a tuple.

The essence of the problem is that, for small displays (and maybe even 
for more capable ones), you want to be able to present the user with a 
single icon, or a label, that says something about each tuple. The 
important characteristic of this icon is that the icons for each tuple 
are sufficiently different from each other to convey what the 
differences in the tuples are. THat allows the user to quickly and 
easily make a choice.

As an example - if I have a presence document with two tuples, one of 
which is a wireless phone, and one of which is a landline phone, the 
display might have icons representing the two different phone types.

Now, the big question is: can a watcher agent look at the tuples, and 
based on their attributes, come up with an iconic representation of 
them? Or, does the PA need to provide the watcher with some kind of 
categorization which can be directly mapped to an icon?

Its not obvious to me that an algorithm can be written to look at the 
tuples and come up with a meaningful classification for each. In some 
cases, its definitely easy. When you have a bunch of tuples, each of 
which differ in a single attribute, then the value of that attribute 
becomes the primary categorization. So, in this case

  <?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:im="urn:ietf:params:xml:ns:pidf:im"
         xmlns:myex="http://id.example.com/presence/"
         entity="pres:[email-masked]">
      <tuple id="bs35r9">
        <status>
          <basic>open</basic>
          <mobility>fixed</mobility>
          <privacy>quite</privacy>
        </status>
        <contact priority="0.8">sip:[email-masked]</contact>
      </tuple>
      <tuple id="aff443">
        <status>
          <basic>open</basic>
          <mobility>mobile</mobility>
          <privacy>quite</privacy>
        </status>
        <contact priority="0.9">sip:[email-masked]</contact>
      </tuple>

A piece of software can easily know that the only difference between 
these two is the mobility attribute, and so it can have a set of icons 
representing different values of mobility.

Things are more complex when each tuple has multiple attributes, each 
of which differs. In that case, its not clear how to come up with a 
meaningful icon to represent the tuple without assistance from the PA. 
Using one of Brian's examples:

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

What icon would a watcher agent use to represent each of these? Hard 
to say.

So, I think there is value in having an RPIDS attribute which conveys 
some kind of information about what the tuple represents. We can start 
with a basic set of types:

"cell phone"
"PDA"
"wireline phone"
"IM service"

etc., and support extensibility down the road.

-Jonathan R.

Robert Sparks wrote:
> Folks -
> 
> The tuple design team has been working since the interim meeting
> to build a clearer picture of how we can make the best use of tuples.
> 
> This team was able to reach consensus on the following points:
> 
> - A tuple with contact advertises a handle that can be used for    
>   communication with the presentity. This is the foundation of 
>   what a tuple "means".
> 
> - Tuples may expose supplemental status information that
>   a watcher can use to distinguish between them.
> 
> - Presence agents can generate documents with many different
>   policies for constructing tuples and we don't want to prevent that.
> 
>       Some example policies discussed include:
>       o always building a document with a single tuple 
>         representing a unified view of the presentity determined
>         by the presence agent.
>       o building documents where each tuple represents a unified
>         view of communicating with the presentity using a particular
>         type of media
>       o building documents where each available communication endpoint
>         is advertised as a separate tuple.
> 
> - We do not want to grant preferential status to any particular policy
>   for constructing tuples.
> 
>       This point was intensely debated. The central point was 
>       whether or not generic clients would be able to sensibly
>       render (or make automated decisions using) documents 
>       constructed with different policies. We achieved rough
>       consensus that this was possible.
>       
> 
> At the interim, we agreed that PUBLISH should identify the tuple
> it is operating on using the id parameter. That approach is
> consistent with the above conclusions, and Aki is proceeding with
> the PUBLISH draft using it. (This has some ramifications which will be
> discussed in a separate message.)
> 
> This is good progress - enough, I believe, that we can move forward
> with it and finish the fundamental versions of many of our deliverables.
> 
> There are still questions around the use of tuples to be discussed.
> The one this design team was circling around 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. This discussion
> will move back to the SIMPLE list.
> 
> There are other positive by-products of this teams efforts, including
> a model that Henning has started developing for describing operations
> over a set of tuples that will be helpful as we address composition.
> 
> The tuple design team consisted of:
> 
> Adam Roach
> Aki Niemi
> Aziz Mohammed
> Ben Campbell
> Brian Rosen
> Henning Schulzrinne
> Jon Peterson
> Jonathan Rosenberg
> Keith Drage
> Paul Kyzivat
> Robert Sparks
> Thanos Diacakis
> 
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Jul 2003 08:00:25 -0400

"cell phone"
"PDA"
"wireline phone"
"IM service"

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 09:50:36 -0400

> etc., and support extensibility down the road.

I generally agree; to further divvy up the problem, there are really 
four ways to do this:

(1) the presentity (or composer) suggests an icon that it believes 
represents the tuple; the latest RPIDS drafts has a facility for that 
(<icon>)

(2) the presentity (or composer) suggests a general classifying label, 
but without pre-defined or standardized meanings. This doesn't allow 
general iconization without some out-of-band cooperation, but does allow 
the watcher to group similar tuples. The RPIDS 'class' attribute offers 
this facility.

(3) a cross-product of two common attributes, such as media and 
mobility, is sufficient to characterize most devices and services. This 
does not allow to distinguish a cell phone from a PDA, but devices like 
a Treo or Blackberry-with-cellphone may make that rather tricky in any 
event. (It is not clear to me that a PDA is a useful distinction, beyond 
the notion of mobility.) This seems to cover the examples you offered in 
the snippet above.

(4) we define a new attribute or element that represents a standardized 
description of the elements that represents common devices.

I think before we go down that path it might be helpful to see if such a 
list can be defined and whether this is substantially different from (3).

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 09:50:36 -0400

Henning