Subject: [Simple] Moving the presence data model work forward

From: Robert Sparks <[email-masked]>
Date: Thu, 6 Jan 2005 22:49:16 -0600

We seem to have ground to a halt again on finishing
the Presence Data Model. This is blocking a very large
portion of the rest of our work.

The current sticking point is, at its core, about where
we are drawing the line for a baseline composition
algorithm.

We've looked several times at whether we would
try to provide a complete standardized composition
system, and have consistently come to the conclusion
that the task is vastly difficult. We've agreed to build
a minimal system that would not preclude work on
more complex standardized composition in the future.

We've achieved consensus around a using  simple
union as the baseline mechanism. Anything more
would be something done outside a standard. We
recognize that this means that different services may
do different things with the same inputs, but until we
have more deployment experience, doing much more
is a "boiling the ocean" class problem.

To hopefully avoid some of the problems that might arise
with that compromise, the Presence Data Model work
tried to add two important things:

  - It introduced a structure that made it more likely
    that elements creating presence documents would
    put information in consistent places. This reduces
    ambiguity and makes it more likely that the intent
    of the document will be rendered accurately across
    different implementations.
- It tried to take one more step towards a more complex
   composition policy by defining what identifies a service
   tuple, so that compositors would have a standard
   algorithm for choosing to combine information about
   the "same service" from different sources.

The effort was very successful on the first point. We have
not yet achieved consensus around the second. To reach
agreement, we will need either to back up to something
closer to our previous consensus point, or go further towards
a complete standard composition system.

In order to allow the document suite that is blocked
on this conversation to go forward, so that we can get
implementation and deployment experience, I believe
it will be necessary to step back:

  - We keep the representation model in the PDM work - <person/>
    and <device/> have been accepted as useful.

  - We maintain the notion that tuples with contacts are "services",
    but don't try to standardize what "same service" means at this
    time beyond the basic tools that PIDF gives us.

  - We break out discussion of a more complete standard composition
    system into a separate document -> AND TABLE IT <- until the
    current document suite is done.

This is a clearly a compromise position - it would be better
if we _could_ specify a more fleshed out composition mechanism,
but history indicates that this is not likely to happen. Lets get
this base mechanism out there so we can get some more
real-world data to help guide the later debate.

RjS

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jan 2005 08:49:09 -0500

Robert - thanks! I am in agreement that this is the way forward.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Jan 2005 17:02:33 -0600

> portion of the rest of our work.
[...]
> real-world data to help guide the later debate.

Robert:

Sounds reasonable.

Thanks,

- 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: Cullen Jennings <[email-masked]>
Date: Fri, 07 Jan 2005 13:53:19 -0800

I think this sounds like the a good path for us to pursue.

This would allow a very large percentage of applications people are taking
about today to be build in a standardized way without complex composition. I
don't think it makes it any harder to bring in the complex composition later
if we do this now. 

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Jan 2005 00:26:10 -0500

Robert,

Thanks for trying to forge some consensus here.

I think you are on the right path, but I don't think its as simple as 
just saying that we don't try to say in what way two services are the 
same or not.

Let me try to explain better the root cause of my concern. The issue for 
me is that the meaning of the service tuple is that its a loose contract 
of sorts; it means that if you *select* this service, where selection 
involves invoking that URI, then the nature of the service you will 
receive is defined by the characteristics and status associated with 
that tuple. If you select a different tuple, you click on its URI, and 
you get something different.

Furthermore, a service tuple is actually something concrete - its a 
software or hardware agent that is listening for requests at that URI, 
and the characteristics and status within the tuple represent the whole 
of its characteristics and status. Its OK if that agent is distributed 
across several components (i.e, a forking proxy and several UAs) - the 
service represents the union of the service they provide.

Thus, my beef with having two services with the same URI is that it 
means this contract is no longer meaningful. Indeed, the watcher can no 
longer select a service tuple at all; to reach the service indicated in 
a tuple they'll have to not only invoke the URI, they'll need to somehow 
construct a request which they hope is routed to that service, possibly 
based on creating one matching the capabilities listed by this service.

This introduces a lot of ambiguity, and in particular, it really wrecks 
the ability of the watcher to ->choose<-. The PDM spends some time 
talking about why watcher choice is one of the key reasons why there are 
multiple services to begin with. If there are multiple service tuples 
but there isn't choice, then it becomes entirely unclear why you have 
multiple tuples - is it a way to express complicated capabilities? 
Should a watcher render a union of the capabilities as one choice to 
select to call? Is this about conflicting information? In other words, a 
service tuple is no longer anything concrete at all; its just a bit of 
information about the service and thus unclear how it relates to other 
bits about the same service.

In my mind, the whole semantic that the PDM is advocating falls apart. 
That is why I find it is anathema to what the PDM is trying to do.

I am fine if we don't try to support override initially. I am fine if we 
  have a really simple composition policy documented initially. I am 
even fine to use an opaque token as a tuple ID. I am not fine if we 
return to what I view as the root problem we had all along - the lack of 
a clear meaning to multiple tuples in a document, and I believe using 
the same URI for multiple tuples has that effect.

As such, I find nothing to disagree with in your proposal but I don't 
see how it addresses what appears to be the primary source of 
disagreement at this point.

It does, however, address other points of dispute and confusion, for 
example how to handle authorization policies which are based on presence 
data itself. In particular, I think it is possible to split out sections 
6 and 7 of the current PDM. The rest of the document describes merely 
the document and its meaning, 6 and 7 describe the processing done by 
presence servers and UAs using that data.

That split would allow us, once we address this issue of unique URI, to 
move forward with RPID and the various presence document extensions. 
However, I believe that the authorization policy work depends on the 
modeling in section 7, and would still be blocked on us at least 
understanding the specific way in which authorization policy takes place 
within the context of presence server processing.

-Jonathan R.

HTH,
Jonathan R.

-- 
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: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Jan 2005 17:06:45 -0500

> you get something different.

This isn't quite true. Even if the URIs in services tuples are 
different, you may well get exactly the same service, just reached by a 
different identifier. Thus, there is no way that a watcher can rely on 
the URI identity to know whether it will reach a different service.

Also, as we discussed in DC and on the list, a basic union composer will 
have no way to ascertain, in general, whether two URIs might be the same 
unless it is familiar with the URI scheme. I thought there was agreement 
that we did not want to require the composer or PA to know the details 
of the URI scheme.

Furthermore, we discussed that there are URI schemes which have, today, 
well-defined mechanisms to select content based on pieces of the request 
beyond the URI. The HTTP content selection mechanism, widely available 
in Apache, is one prominent example.

http://embassy.fr (French version)
   note: this is the french version
   content-language: fr
http://embassy.fr (English version)
   note: this is the english version
   content-language: en

>  have a really simple composition policy documented initially. I am even 
> fine to use an opaque token as a tuple ID. I am not fine if we return to 
> what I view as the root problem we had all along - the lack of a clear 
> meaning to multiple tuples in a document, and I believe using the same 
> URI for multiple tuples has that effect.

I don't see that forcing the PA to merge or reject or override same-URI 
tuples either increases the descriptiveness or, conversely, that not 
enforcing this in any way decreases it. You keep asserting that this 
would get us back into the wild woods of anything goes, but provide no 
evidence for this.

In general, there are two cases from a watcher perspective:

- The service description is meaningful beyond the URI.

- There is no meaningful service description (since, for example, the 
service description contains information not understood by the watcher).

A URI scheme itself provides almost no service information beyond the 
mechanics of contacting it, so an enumeration of different URIs without 
description isn't any more meaningful than a list of the same URIs.

URI1
   (some service description 1, D1)

URI2
   (some service description 2, D2)

There are the following possible cases, all with well-defined behavior 
for the watcher:

URI1 == URI2, D1 == D2
   presumably a mistake, but harmless duplication; watcher drops duplicate

URI1 == URI2, D1 != D2
   if the watcher knows how to use D1 and D2 to qualify the request to 
URI1/2, it does so; otherwise, the two tuples are the same as far as the 
watcher is concerned and the watcher drops one or the other (or 
indicates that the watcher might get D1 or D2, based on the luck of the 
draw and the mood of the proxy). This is logically no different than 
saying "This URI might give you either A or B, but I can't tell you 
ahead of time what you'll get", i.e., common behavior for any proxied 
SIP URI today.

URI1 != URI2, D1 == D2
   somewhat confusing to the watcher, but no worse than the common habit 
of having a list of phone numbers on a business card, with no 
differentiation by function. Not a problem affected by this discussion.

URI1 != URI2, D1 != D2
   common case; no problem

It is then up to the elements contributing to the presence information 
to choose the URIs and descriptions that are most likely to work. That's 
an operational decision and allows service upgrades without upgrading 
the composer or PA, over which I have no control.

Thus, the meaning and algorithm are well defined *for the watcher*. We 
should probably describe this in a bit more detail.

My concern is that once we "outlaw" equality in URIs, that we lose the 
ability to describe and handle such scenarios and require composers that 
need to deal with such cases, without having the means to do so in a 
predictable and information-conserving manner, given the simple-union 
requirement.

Unless we describe a composer in detail, I don't see how we can rule out 
duplicate URIs. We would have to describe:
   - whether URI equality is syntactic or semantic
   - whether "latest wins"
   - whether such 'latest wins' would lead to Kerry-style flip-flop 
behavior, i.e., if URI1(D1) and URI2(D2) have URI1=URI2, the watcher 
would see D1 or D2, depending on whether the publisher representing D1 
or D2 has last published information.

In summary, I believe that we gain no semantic clarity by ruling out the 
existence of duplicate elements at the composer and that the watcher is 
the only entity qualified to make appropriate equality judgements.

Henning

---

From: Hisham Khartabil <[email-masked]>
Date: Sun, 9 Jan 2005 15:48:17 +0100

> just saying that we don't try to say in what way two services are the 

Robert is not saying that we don't try. Robert is saying that we need 
implementation, deployment and user experience before you, Henning, Aki 
or whoever can justify his own view point. Clearly we are not reaching 
consensus on anything at this point and only time will tell. We are 
trying to model and standardise something that we don't have full and 
common understanding of. We will be much more successful in 
standardising this when we get feedback from the community. Until then, 
the debate is an academic one. Lets just give implementers the building 
blocks and let them decide, along with their customers, how composition 
policy can be made to work.

>
> Let me try to explain better the root cause of my concern. The issue 
> for me is that the meaning of the service tuple is that its a loose 
> contract of sorts; it means that if you *select* this service, where 
> selection involves invoking that URI, then the nature of the service 
> you will receive is defined by the characteristics and status 
> associated with that tuple. If you select a different tuple, you click 
> on its URI, and you get something different.

That's because you are hung up on the idea that the URI that is 
represented in the tuple is the only way to reach that service. Others 
have other ideas. Again, we need to allow for deployments to happen 
before someone can say "see, I told you so".

> and the characteristics and status within the tuple represent the 
> whole of its characteristics and status. Its OK if that agent is 
> distributed across several components (i.e, a forking proxy and 
> several UAs) - the service represents the union of the service they 
> provide.
>
> means this contract is no longer meaningful. Indeed, the watcher can 
> no longer select a service tuple at all; to reach the service 
> indicated in a tuple they'll have to not only invoke the URI, they'll 
> need to somehow construct a request which they hope is routed to that 
> service, possibly based on creating one matching the capabilities 
> listed by this service.
>
> This introduces a lot of ambiguity, and in particular, it really 
> wrecks the ability of the watcher to ->choose<-. The PDM spends some 
> time talking about why watcher choice is one of the key reasons why 
> there are multiple services to begin with. If there are multiple 
> service tuples but there isn't choice, then it becomes entirely 
> unclear why you have multiple tuples - is it a way to express 
> complicated capabilities? Should a watcher render a union of the 
> capabilities as one choice to select to call? Is this about 
> conflicting information? In other words, a service tuple is no longer 
> anything concrete at all; its just a bit of information about the 
> service and thus unclear how it relates to other bits about the same 
> service.

Again, we are not saying we will never make this more concrete in an 
RFC, but please lets get implementation and deployment experience first 
and lets stop speculating.

> I am fine if we don't try to support override initially. I am fine if 
> we  have a really simple composition policy documented initially. I am 
> return to what I view as the root problem we had all along - the lack 
> of a clear meaning to multiple tuples in a document, and I believe 
> using the same URI for multiple tuples has that effect.

Robert's suggestion was to rip out the composition policy stuff 
completely from the draft.

> disagreement at this point.

Its addressing it by allowing real user experience to dictate how 
things should be viewed.

> example how to handle authorization policies which are based on 
> presence data itself. In particular, I think it is possible to split 
> out sections 6 and 7 of the current PDM. The rest of the document 
> describes merely the document and its meaning, 6 and 7 describe the 
> processing done by presence servers and UAs using that data.

That is the idea.

>
> That split would allow us, once we address this issue of unique URI, 
> to move forward with RPID and the various presence document 
> extensions. However, I believe that the authorization policy work 
> depends on the modeling in section 7, and would still be blocked on us 
> at least understanding the specific way in which authorization policy 
> takes place within the context of presence server processing.

We don't want to block RPID and the various document extensions. If 
that is true, then this whole conversation is mute. Can you elaborate 
on why this unique URI issue is blocking this work and the 
authorisation policy work?

Regards,
Hisham

---

From: Aki Niemi <[email-masked]>
Date: Tue, 11 Jan 2005 11:32:08 +0200

I agree with this approach.

Cheers,
Aki

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Jan 2005 14:06:12 -0600

I'd like to add my voice to the several other messages posted here: I 
think this is a reasonable way to proceed.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jan 2005 01:17:13 -0500

Before you read this reply, please read my post just now proposing 
another potential point of compromise.

More inline.

> the URI identity to know whether it will reach a different service.

Fair enough. At least the watcher gets to make a choice. With multiple 
tuples with the same URI, it can't know what that means or determine 
what it needs to do to reach one or the other.

> that we did not want to require the composer or PA to know the details 

Yes, as such I do agree we cannot prevent two services from having the 
same URI.

>   note: this is the english version

Here is a great example of the dispatch idea I am talking about. In this 
particular instance, you REALLY want to explicitly tell the watcher what 
they need to do in order to reach the french as opposed to the english 
version. I do not think that prescaps is the right way to do that. 
Prescaps indicates capabilities of the UA that is reached through the 
<contact> URI. That is NOT the same as saying, "if you formulate your 
request in this way, it will be dispatched to this service". I would 
much rather model this explicitly with some kind of information that 
tells the watcher exactly what it needs to do. That is what you are, in 
fact, doing above: you're telling the watcher to use content-language of 
english vs. french to reach the two different services.

> would get us back into the wild woods of anything goes, but provide no 

I hope I've given a concrete example in my other note. Without 
additional information to provide guidance on what this means (which of 
the four cases applies, and if its a dispatch case, how the dispatch 
works), things are ambiguous.

> - The service description is meaningful beyond the URI.

Well, thats the rub.

We have no way at this time of expressing clear ways to make this 
meaningful.

> There are the following possible cases, all with well-defined behavior 

Per my other note, I don't think there is such a thing as "well-defined 
behavior for the watcher". Watcher behavior should never be specified. 
Rather, we need to have well specified meaning of the presence data.

> URI1/2, it does so;

This is the "and magic happens" bit that I am nervous about. I think 
that the meaning of the above two cases cannot be described in the data 
model in any way but "ambiguous", and it is a mistake to recommend any 
kind of watcher behavior. We can leave the door open to make this less 
magical and more explicit, but with everything on the table today (RPID, 
prescaps, cipid, etc.) it remains ambiguous.

> otherwise, the two tuples are the same as far as the 

I still believe URI remains the best way to dispatch, but per my other 
note, I concede this point that there may be other ways to dispatch 
downstream, and if people agree to my proposal, I will allow this in the 
data model.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jan 2005 01:30:18 -0500

I'm not going to bother responding to most of the responses in here; 
hopefully they are addressed by my note this evening with another 
compromise proposal. I did want to address one other point that is quite 
important (and thus the change in subject lines):

Hisham Khartabil wrote:

> We don't want to block RPID and the various document extensions. If that 
> is true, then this whole conversation is mute. Can you elaborate on why 
> this unique URI issue is blocking this work and the authorisation policy 
> work?

One of the concerns is that unless we more clearly define the logical 
sequence of operations executed by a presence server (figure 4 in the 
data model), different servers will execute the authorization policy in 
different places and in different ways, leading to inconsistent 
behaviors and thus interop problems.

For example, I recall that, during the November meeting, someone said 
they thought that privacy policy would get applied prior to composition, 
not after. The order in which these are done will greatly impact the 
final presence document.

One way out of this conundrum might be to specify just a piece of this 
processing logic in the authorization policy spec itself. A few things 
we could possibly say:

1. A presence server MUST apply the privacy filtering operation as the 
final step in its processing. Whatever document it would otherwise send 
in the absence of privacy policy, it must take that document as input, 
apply privacy processing, and then the resulting document is what gets 
sent. The subscription processing aspects of the document get applied by 
the server when it decides to accept or reject the subscription.

2. This specification does not mandate at what point in the processing 
of presence data the privacy filtering aspects of the authorization 
policy are applied. However, they must be applied such that the final 
presence document sent to the watcher is compliant to the privacy policy 
described in the document. More concretely, if the document sent to a 
watcher is D, and the privacy filtering operation applied do a presence 
document is F(x), then D MUST have the property that D = F(D). The 
subscription processing aspects of the document get applied by the 
server when it decides to accept or reject the subscription.

I tend to favor something like (2) since it leaves the door most open 
for a more specific set of definitions on presence server processing for 
downstream. We could do any kind of alternate flowchart (figure 4 in the 
model) so long as it results in the property described.

Does that work for folks?

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Jan 2005 12:33:15 -0500

> Does that work for folks?

Works for me.

There is an implication here around privacy filtering in general - of 
idempotence:

	F(F(X)) = F(X), for all X

This isn't especially remarkable, but something to keep in mind.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Jan 2005 16:21:54 -0500

> model) so long as it results in the property described.

I think this works as long as the composition policy does not add any 
information, e.g., from non-presence sources. One could argue that even 
the ideas of likelihood filtering discussed for smart composers, i.e., 
ditching contradictory elements and retaining the most likely one, add 
information, at least in an information-theoretic sense.

Otherwise,

[privacy] | [composition]

and

[composition] | [privacy]

might not be equivalent.

I think your D = F(D) is similar (it essentially says that applying F() 
again wouldn't change the result).

My concern is that we have a trade-off, namely that by not specifying 
the order, we constrain what composition policies can do. Given that we 
haven't really agreed, even at a fairly high level, what composition can 
do, it seems less harmful to constrain the ordering of operations to be 
safe. I see very little additional implementation benefit in leaving the 
order open. Clearly

publish - privacy - compose - privacy

is also ok and maybe we can simply also allow the double application of 
privacy policies. The advantage of the latter model is that the composer 
doesn't get burdened trying to reconcile information that the privacy 
policy would have ditched in any event.

Note, however, that the latter model makes the composing operation 
inherently be watcher-specific, which is a large change.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Jan 2005 16:32:21 -0500

> english vs. french to reach the two different services.

General agreement. Since this is fairly abstract, I'm not, in general, 
convinced that there needs to be more mark-up than, say, Content-* or 
prescaps, as the information in the presence element translates exactly 
into request modification instructions (Accept-* and caller prefs). 
Whether there is a duplicate URI or not, the watcher can, if capable, 
include these in the request and the right thing will happen.

If the watcher doesn't understand the transformation from description 
into request, the difference essentially becomes unavailable to the 
watcher for selection.

> works), things are ambiguous.

See above. However, I think we can easily disagree on this particular 
item and move ahead as you proposed in your other note.

Henning