Subject: Re: [Simple] Update to xcap authorization rules - rpid type

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 01 May 2004 13:51:21 -0400

I'm not sure I completely understand the item below, but one potential 
concern is that this may mix conditions and actions in one element, with 
less-than-clear expressions. It is probably less efficient, but clearer, 
in my opinion, to keep the two separate, even if it means expressing 
them as two or more separate rules.

We don't necessarily want to design to a user interface, but the more 
sub-clauses and conditions something has, the more difficult it becomes 
to write simple GUIs for it. (This also greatly complicates translation 
into other rule mechanisms.)

Thus, I'd prefer an explicit equality condition on (say) class and 
placetype, with an associated list of included objects.

Doing the same thing in two ways, just because they are two different 
attributes, doesn't strike me as a minimalist design.

> * Formerly, each of the permissions granted access to an rpid type,
> and allowed you to indicate which tuple, identified by class, it was
> included in. There were several problems here. One, identified by
> Markus, is the lack of a short-hand for saying "tuples of all
> classes". Another problem is that it only allowed usage of the "class"
> attribute as a means for selecting which tuples to include it in. I
> have figured out how to extend this to a bunch of different selectors,
> and have included ones for class, placetype, privacy, relationship,
> sphere and contact-type. This is done by defining all of the
> provide-foo elements as sets, rather than boolean, and the set members
> identify the tuple-selector criteria by RIPD element name/value. So,
> for example, to include the placetype attribute in all tuples where
> placetype has a value of home OR the class is friend:
> 
> <provide-placetype>
>   <tuples-whose>
>     <placetype>home</placetype>
>     <class>friend</class>
>   </tuples-whose>
> </provide-placetype>
> 
> Since, according to the common-policy rules, composition of sets is
> done by union, the above is identical to:
> 
> <provide-placetype>
>   <tuples-whose>
>     <class>friend</class>
>   </tuples-whose>
> </provide-placetype>
> 
> <provide-placetype>
>   <tuples-whose>
>     <placetype>home</placetype>
>   </tuples-whose>
> </provide-placetype>
> 
> which could appear in the same or separate permission documents.
> 
> Its also possible to explicitly say "all-tuples". I don't have
> qualifiers for things like "all tuples that include any class", but
> these can easily be added under the set definition. If folks want to
> explicitly see something added, please comment.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 01 May 2004 13:51:21 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 May 2004 08:13:00 -0400

inline.

> them as two or more separate rules.

I'm not sure how to do that. You are correct that the permissions do 
define conditions, and in particular, they specify the conditions under 
which a particular rpid element is included in the presence document. 
For example, "include placeype in tuples where the class is "friend"".

However, those are different conditions than what the condition element 
specifies, which is, "should this permission be applied to the 
processing of this subscription". As such, I don't know how to use these 
conditions to specify a rule like the example above.

> into other rule mechanisms.)

OK, fair enough - that would argue for going back to having simply a 
boolean for inclusion of these elements or not. But it seems we want 
more than that, no?

> placetype, with an associated list of included objects.

As I mention, I dont know how this would work. Lets say my presence 
document has two tuples, one with class of "friend" and the other with 
class of "work". Both include the "placetype" element. If you had a 
condition that specified an equality condition on class:

<conditions>
   <class>home</class>
</conditions>

<transformations>
</transformations>

This would remove the placetype element (since no permission is granted 
for it).

When would this rule be applied to a subscription? It matches for one 
tuple, but not another. What would it mean to apply the entire rule only 
for one tuple?

Indeed, it occurs to me that we have a similar problem for the existing 
<sphere> element, which can have different values in different tuples.

> attributes, doesn't strike me as a minimalist design.

Agree with that. If we can find a model whereby the conditional aspects 
of this can be placed in the <conditions> section, I agree its 
definitely better.

Thanks,
Jonathan R.

-- 
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 May 2004 08:13:00 -0400

inline.

<conditions>
   <class>home</class>
</conditions>

<transformations>
</transformations>

Thanks,
Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 May 2004 23:10:53 -0400

Trying to take a step back, maybe we need to examiane a more fundamental 
assumption that we have just silently made, namely whether rules 
logically come before or after composition. Another way of saying this 
is that rules could (logically) apply to tuples individually, and all 
allowed tuples are combined into one presence object.

I haven't thought through all the implications, but it seems like this 
would be cleaner and avoid many of the problems discussed in this 
thread. I suspect it will also make rules simpler, since you don't have 
to specify as many conditions for all the combinations.

This is independent of whether a tuple specifies a device, presentity or 
service, although the rules may differ a bit depending on the choice 
made by a user.

> For example, "include placeype in tuples where the class is "friend"".

this is relatively easy for the rules-specifies-per-tuple behavior

> conditions to specify a rule like the example above.

Elements which (legitimately) can differ among tuples for the same 
presentity don't seem to be suitable as conditions. There are dangers of 
allowing such conditions: imagine where two devices publish tuples for 
one presentity, both using a different value for variable A. The 
compositor comes online and gets first one tuple from one device, then 
the other some minutes later from the other. By the combined rules, the 
subscription might fail, by per-tuple rules it would succeed - 
privacy-unsafe and unpredictable.

> boolean for inclusion of these elements or not. But it seems we want 

Having some realistic use cases might help. I think a set of test cases 
that we can use for 'regression testing' as we try to simplify or expand 
things wouldn't hurt.

> of this can be placed in the <conditions> section, I agree its 

Let's try. It may mean that the conditions for subscriptions and 
inclusion can't quite be the same, for the race condition I mention 
above. Making subscription depend on rapidly-changing conditions is 
probably not such a hot idea in any event - it means that subscriptions 
can succeed and then fail for the same watcher and presentity minutes 
apart. Unless you do polite blocking, you leak information since the 
subscriber can 'poll' and detect that a sensitive condition has changed. 
("Ah, Alice must have left work now since she's blocking my subscription 
attempts.")

The difference between polite blocking and simply not delivering the 
sensitive tuple seems minor.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 May 2004 23:10:53 -0400

---

From: 陳俊忞 \(Chun-Min Chen\) <[email-masked]>
Date: Tue, 4 May 2004 14:38:24 +0800

Hello,

I would like to ask some questions about XCAP implementation.

1. Can XCAP be implemented with current web servers (ex. Apache or IIS)? If
it can, please explains howsimply.

2. From the discussion thread  "[Simple] PUT vs POST in XCAP", it seems we
have to write apache modules to handle PUT, but how about GET an element
from XML document? Should I write another module to handle it?

Thanks for your kindly answer.
Best regards,
Chun-Min Chen

---

From: 陳俊忞 \(Chun-Min Chen\) <[email-masked]>
Date: Tue, 4 May 2004 14:38:24 +0800

Hello,

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 May 2004 05:15:40 -0400

> allowed tuples are combined into one presence object.

I agree that we definitely need to examine this fundamental model 
assumption. I've been thinking along similar lines, and in fact just 
posted on the two models.

> to specify as many conditions for all the combinations.

I'm not sure. I can't really see how this would work. I keep bumping 
into this same wall, which is that <conditions> specify, when a 
subscription arrives, the set of permissions (in terms of 
transformations and actions) to apply. That is quite different from 
using conditions to determine to which tuples a permission applies.

Another point. The model I had implicitly in mind (which I called model 
I in my other note), is that the presence server builds up an uber 
presence document with everything in it, and then permissions determine 
who sees what. That seems, to me, to be a much closer match conceptually 
to the privacy model we and geopriv are using - that there is some core 
information to which access is being granted. Thats quite different from 
view authorization policy as a set of guidelines that define how 
composition works; it was far from obvious to me how our privacy rules 
would work in such a case. Its no longer about giving access to 
information, its about guiding composition. How do you define privacy 
orders?

>> define conditions, and in particular, they specify the conditions 
>> under which a particular rpid element is included in the presence 
>> document. For example, "include placeype in tuples where the class is 
>> "friend"".
> 
> 

Can you provide a concerete description of how it would work?

> 
> 
>>
>> However, those are different conditions than what the condition 
>> element specifies, which is, "should this permission be applied to the 
>> processing of this subscription". As such, I don't know how to use 
>> these conditions to specify a rule like the example above.
> 
> 

Perhaps I am misunderstanding, but it sounds like you are arguing 
against having conditions that are based on presence values?

> that we can use for 'regression testing' as we try to simplify or expand 

What I had in mind for this were cases where you anticipated that the 
data was more sensitive for one type of tuple than another. FOr example, 
  assuming a device view, I might want to allow people to see placetype 
for my fixed work phone (its always "work"), but not see it for my 
mobile (where its value depends on my geographic location).

I'll try and think of more use cases; it may well be that there isnt 
anything particularly pressing that motivates this need. I definitely 
think we need to be able to provide specific tuples based on presence 
attribute values - thats needed for any basic system with lying, for 
example.

> 
> 
>>
>> Agree with that. If we can find a model whereby the conditional 
>> aspects of this can be placed in the <conditions> section, I agree its 
>> definitely better.
> 
> 
> above.

OK, so now I'm really confused about what you had in mind...

> Making subscription depend on rapidly-changing conditions is 
> apart. 

Don't you already have this problem with the <sphere> condition?

> Unless you do polite blocking, you leak information since the 

Yup.

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 04 May 2004 12:17:49 +0300

> Thanks for your kindly answer.
I have written an Apache module to handle XCAP requests. This module
will handle all methods, currently GET, PUT and DELETE. It is fairly
easy to get the header information and payload from Apache and then
return within xcap-module the requested payload. This "glue" code for
Apache is fairly simple to implement. However, as Apache usually acts as
a multiprocess and multithreaded engine some resource locking is
required when several requests for the same resource are handled at the
same time. That may not be so trivial. Furthermore, subscription
handling for events requires also a sip-stack and some tweaking between
them is needed as well. 
The XML and XPATH manipulations are otherwise straightforward but
especially default namespace handling needs careful coding.

There are still quite a lot of other issues as well, but hopefully this
helps somewhat.

BR,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 May 2004 05:15:40 -0400

Yup.

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 04 May 2004 12:17:49 +0300

BR,
Jari

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 May 2004 22:14:15 -0400

Rather than trying more in-line response, let me try to summarize.

I'm starting to think that subscription permissions and view permissions 
are somewhat different and it may well be easier if we don't try to 
shoehorn them into one set of rules.

The model I'm trying to work out details for:

(1) have a rule set that only takes into account watcher identity (with 
the usual exception and wildcard models) and time-of-day for allowing 
subscriptions

(2) another rule set that applies conceptually to each tuple and takes 
into account, as conditions ('if' part), the current state of the 
presentity, including identity, time, location and sphere (but not 
class). The 'then' part simply selects tuples by class (only tuples that 
have 'class X') and adds RPID, contact and other elements, for each 
tuple, according to the rules.

After the filtering, the resulting set of (modified) tuples is 
delivered, if non-empty.

There's no ambiguity as to the current state for (1), so this is easy.

The problem with (2) is that location and sphere can be ambiguous, since 
both may be contributed by different sources. There is not much we can 
do about this, as there is no natural ordering. One possible, 
privacy-safe solution is to apply all states to the rules and then only 
pick those tuples and elements that are selected by all states. Example:

Say, that I have two states at one time (published):

state 1: loc=NY, sphere=work (published by my office PC)
state 2: loc=NJ, sphere=home (published by my home phone)

since I forgot to turn off my presence publisher in my office when I 
went home. My rules might say

if (loc=NJ) then include sphere, location at A1 level
if (loc=NY) then include activities, location at A1-A3 level

I'm omitting the destination URI rules here for simplicity, as they 
don't change based on my state. I would simply run the rule apparatus 
twice, on state 1 and 2. In this case, the intersection would allow only 
to deliver location at the A1 level, nothing else. This is privacy safe, 
albeit conservative.

For permissions that are integers, the minimum is chosen.

My division into two rule sets is not mandatory - you can make this work 
in the current model, using the same intersection/minimum rules. If any 
rule prohibits subscription, the watcher doesn't get in.

However, I'm starting to warm to the idea of divide-and-conquer, as it 
lowers the bar to entry and keeps the protocol specs below the 30-page 
limit... I'm very worried that simple systems will not implement a 
complete subscribe-filter-compose policy, but with no real way for a 
user to know capabilities. If the rules make sense separately, 
modularity suggests describing them as such.

> information, its about guiding composition. How do you define privacy 

We might be talking about roughly the same thing.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 May 2004 22:14:15 -0400

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 May 2004 23:36:31 -0400

Jari - a question inline.

> especially default namespace handling needs careful coding.

I don't understand this last bit. What do you mean? Is there anything 
that we need to do in the spec to help address this, or any of the other 
  implementation issues you've found? Your input is most appreciated.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 May 2004 23:33:39 -0400

inline.

> shoehorn them into one set of rules.

I'm also with you on divide-and-conquer, though I don't think I'd divide 
it like you do. See below.

> There's no ambiguity as to the current state for (1), so this is easy.

Yes, in fact, too easy I think. The problem with this approach is that 
we would have something really, really simple right now, with less 
functionality than existing systems (wireless village, for example, does 
allow you to specify which attributes get delivered to whom). If you 
want more than the minimum, you'd need to add this second thing, and I 
think we're far from being done with that, since the what-is-a-tuple and 
mysteries of composition have yet to be fully fleshed out, and they need 
to be fleshed out if we want to define policies that control them.

So, I'd rather break it this way. For now, we focus on defining privacy 
policies that apply after the server has performed composition, since we 
don't know enough to control composition yet. Those policies allow you 
to accept/deny subscriptions as you suggest, but also grant permissions 
for uers to see various presence attributes. We can go back to the 
simple boolean appraoch we had before (send it or not). We also remove 
sphere as a condition because of the issues about determining what tuple 
sphere is defined in.

We also allow the user to specify which tuples get sent, selecting based 
only on URI scheme and class.

If you remove information so that the result are tuples that seem 
similar, we include some text on optional combining operations that the 
server can do, but clarify that these are not normative in any way. In 
essence, the work we're doing now is truly a privacy filter - it simply 
states who can and can't see what information, rather than saying 
anything about how to structure the information for which we have 
granted permission. I like that model.

Then, at a later point in time, we could define policies that control 
composition, and those would allow for more selective inclusion of 
information in specific tuples.

The benefit here is that the scope of the current work provides what I 
believe to be minimal functionality now, and the framework (viewing 
downstream work as controlling composiiton as opposed to an extension to 
the current work) would allow us to do a lot more later.

Are people comfortable with this scope?

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 May 2004 23:36:31 -0400

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 May 2004 23:33:39 -0400

inline.

Thanks,
Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 May 2004 09:06:37 -0400

> allow you to specify which attributes get delivered to whom). If you 

The separation into subscription and filtering rules does not limit the 
functionality; it simply avoids having to worry about conditions that 
needlessly add complexity to subscription actions.

> Are people comfortable with this scope?

I have to admit that I still prefer my breakdown into three part. I want 
to be able to filter based on my current <sphere>, but I don't want 
subscriptions to depend on <sphere>, for example. I want to be able to 
deal with conflicting information, in the way that I described in an 
earlier message (by logically applying rules to tuples).

This filtering can be conceptually seen as taking place before or after 
composition - indeed, it is probably true that the true pipeline is 
something like this:

PUBLISH (...) -->
    [composition based on favorite view of world]  -->
    [privacy-based filtering for each resulting tuple] --->
    [post-composition to remove deadwood, etc.] -->
    [rate limiting] --> NOTIFY

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 May 2004 09:06:37 -0400

PUBLISH (...) -->

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 07 May 2004 10:20:53 +0300

>   implementation issues you've found? Your input is most appreciated.

First I am assuming that XCAP data model follows what XPATH 1.0 defines.
To my knowledge XPATH was being done in the scope that it is used with
XPointer or XSLT which have proper namespace-handling in their context.

If the QName (http://www.w3.org/TR/xpath#node-tests) does not have a
prefix the namespace in that axis is NULL (this has been changed in
XPATH 2.0 to default element namespace in the expression context). So if
we are using default namespaces the nodes without prefixes do have a
namespace (the inherited default one) attached and queries without
prefixes will result in empty node sets unless some additional "magic"
is being done. So if implementations are using XPATH 1.0 compatible
libraries (instead of doing an own interpreter) when default namespace
is used in the document they have to change e.g. the original query
"/list/node" to either
"/list/*[namespace-uri()="urn:..."][local-name()="node"]" or to
"/list/rls:node" and do a library specific "namespace registration" to
namespace uri ("rls=urn.." in this example). The model in XPATH 2.0 is
more sane as it follows what should IMO be described in the XCAP draft,
too. Furthermore, if non-default namespaces are used, those prefixes has
to be "registered" with the doc/element context so that queries do work
as expected. Also, it should probably be a good idea to emphasize that
prefixes in namespace declarations are not fixed, i.e. they have a
document based context the fact of which application creators should
consider. This is probably worth noting someway in the base XCAP
document.

In the XCAP examples there should also be cases were namespaces
(non-default) are used.

Furthermore, I do have some thoughts on the "multiple insert case" if
they are going to be allowed but there's still another thread about
that.

BR,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 07 May 2004 10:20:53 +0300

BR,
Jari

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 May 2004 12:09:42 -0700

>XPointer or XSLT which have proper namespace-handling in their context.

 From Section 5.2 of the base XCAP bath:

    The QName grammar is defined the XML namespaces specification [3].

    The node selector is based on the concepts in XPath [9]. Indeed, the
    node selector expression happens to be a valid XPath expression.
    However, XPath provides a set of functionality far richer than is
    needed here, and its breadth would introduce complexity into XCAP.

I would not jump from "happens to be a valid XPath expression"
to "XCAP data model follows what XPATH 1.0 defines".   XCAP is
radically simpler than XPATH, and that was intentional.
			regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 May 2004 12:09:42 -0700

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 May 2004 23:54:17 -0400

Jari,

Thanks for clarifying this, it raises some things that definitely need 
clarifying in the spec.

As Ted points out, xcap is not using Xpath directly; it specifies an 
expression syntax that happens to be a compliant xpath expression, but 
that doesn't mean that we inherit all of the specification.

On this particular point, it had been my assumption (which is NOT 
properly stated), that the expressions were evaluated such that, if the 
axis did not contain a namespace prefix, the default namespace of the 
enclosing context would apply, and NOT the null context. So, for 
example, given this doc:

<root xmlns:n1="namespace1" xmlns:n2="namespace2" xmlns="namespace1">
   <n1:bar/>
   <n2:bar/>
</root>

then the expression "root/bar" will select the first bar element (the 
one from namespace 1).

I believe this is consistent with the XPATH 2.0 behavior you describe 
below.

I'll add some text which clarifies this, gives an example, and 
explicitly mentions this difference between the xpath 1.0 and 2.0 
specifications.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 May 2004 23:54:17 -0400

Jari,

Thanks,
Jonathan R.