Subject: [Simple] Comments on: First draft of text on semantic-based authorization policies

From: [email-masked]
Date: Tue, 23 Mar 2004 01:04:29 +0200

Hi Jonathan,

Here are some comments to both the semantic approach and the SIMPLE presence authorization work in general.

General comments:
----------------
I'm currently quite concerned with how the authorization looks like. There are some very nice properties and much thought has been put into it, but I fear that in practice it will fall short. Here are my main issues:

* Exceptions: 
Currently they are allowed only within domains. This was done on purpose for reasons that I don't really believe in. The end result is that it is impossible to do proper block-listing. It was claimed that block-listing is a bad concept anyway, as identities can be created easily to by-pass such lists. While in general this is the case, I don't think it should limit _all_ systems, some of which can deal with identities better than the Internet at large. Below is an example, beyond block-listing, how leaving out exceptions makes things difficult
	[Presentity wants to give group "friends" a privileged access to his presence information. By default he gives out some information, but "friends" should receive a different view of the _same_ information. (Note that this is not additive, but we talk about different views, for instance showing a _different_ "note".) If exceptions are not allowed, "friends" will get the common information in addition to what should be given to them, making things confusing at the watcher side. (For instance a watcher get 2 tuples with the same Contact, having different notes.)]
So I believe the main problem is that presence information is not always additive, but it can also be contradictive! Another huge problem is that there already exists many presence systems which have block-lists, and in some cases we would like to preserve the UI semantics even when the protocol stack is changed to SIP. Now it seems impossible. 
-> Proposal: Allow exceptions in SIMPLE, even though they are not there in the common policies.

* External lists:
Again, external list references were dropped due to GEOPRIV harmonization. I don't understand why they need to be disallowed in all environments. If the service provider has a centralized XCAP server for resource lists, those should be usable by reference in presence auth. rules. (FYI, OMA is working on common "group management" for different applications, and for this external references are also clearly needed.)
-> Proposal: Add external lists, include considerations on where they are usable.

I believe these two modifications would make SIMPLE presence rules much better deployable in practice, and more easily endorsed directly by e.g. 3GPP and OMA.

Comments on semantic rules
--------------------------
In general I think it's good to have some semantics involved in decision-making, and I understand the benefits over pure syntactic model. Here are issues, though:

* view-transformation
This goes clearly in the territory of "what is a tuple" and "compositor policy". I strongly support of trying to deal with the latter at least in some level here. However, I don't fully support the different "views" expressed here. I'm supporter of the service-view - but, _in addition_ to tuples describing service/communication-specific attributes, there can be a presentity tuple describing common things about the presentity. This kind of model should not be excluded here.
-> Proposal: Would it make sense to have the "views" (at least presentity and service) combined using union rather than being mutually exclusive, so that if both presentity and service view are given, the model described above would be taken. Another way would be to describe that service-view could still contain presentity-tuple(s). This probably needs more thinking.

* Extensibility vs. attribute-based semantics
It seems that most attributes won't have semantics beyond a binary show/no-show decision. In this case I see no need for the server to know in _advance_ anything of such attributes. In practice the show vs. no-show could be a general rule applicaple to any attribute through a syntactic match of the attribute name. This would allow handling also unknown or proprietary attributes on a rudimentary level without having to update the presence server/agent. In case that the attribute has some further internal structure, allowing for more complex decisions, such as with "idle" in RPID, it could be defined in an extension spec accompanying the definition of the attribute itself.
-> Proposal: extend the handling specified for e.g. "placetype" or "privacy" to any attributes through syntactic matching on the attribute name.

* Abbreviated expressions
It would be good to have abbreviated ways of saying:
- All tuples
- All tuples having a class attribute
- All tuples not having a class attribute
without needing to list all the classes explicitely.
Also there is a problem that all attribute-names need to be listed, if they are given, as the defaults are "false". This is only an efficiency issue, but maybe some abbreviated form of saying: 
- all attributes in RPID (or CIPID or Prescaps)
  <except>placetype</except>

* Overlapping actions
It should be described what happens if multiple actions are provided. This was discussed in a separate thread.

Regards,
	Markus 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 09 March, 2004 11:25
> To: Simple WG
> Subject: [Simple] First draft of text on semantic-based authorization
> policies
> 
> 
> Folks,
> 
> During the SIMPLE meeting at IETF, we had a discussion about 
> whether to 
> move from the current syntactic based permissions (show-namespace, 
> show-tuple, show-element) to semantic-based ones. I took an 
> action item 
> to write up proposed text within one week on how the semantic-based 
> approach might look. Below is a first cut (in xml2rfc) at what such 
> permissions might look like.
> 
> One thing that became clear to me in doing this is that certain 
> transformations are easily expressed semantically, but nearly 
> impossible 
> syntactically. The "view" permission was one example. There 
> are a bunch 
> of open issues; mostly minor, all noted in the text. Comments 
> on any and 
> all of it are welcome. I'd like to get buy in (or lack 
> thereof) of this 
> general direction within the next week or two so I can integrate the 
> text and submit a revision.
> 
> Thanks,
> Jonathan R.
> 
> 
> ---
> <section title="Transformations">
> 
> <t>
> Each of the sections below defines a particular transformation that is
> applied to the presence document before distribution.
> </t>
> 
> <section titie="View">
> 
> <t>
> The view transformation indicates the way in which the published
> presence data is aggregated before being presented to the watcher. The
> value of this element is an enumerated token with the following
> values:
> </t>
> 
> <list style="hanging">
> 
> <t hangText="presentity:">This token has a value of zero. It indicates
> that the presence agent should aggregate the presence information for
> the presentity into a single tuple. This tuple will contain a single
> contact value that reaches the presentity. Because this causes
> aggregation of data into a single tuple, it reveals the least amount
> of information about a presentity, and thus has the value of zero.
> </t>
> 
> <t hangText="service:">This token has a value of one. It indicates
> that the presence agent should model the presentity as a sequence of
> tuples, each representing a "service" by which the presentity can be
> reached. Examples of services and how they are represented is
> described in <xref target="I-D.roach-simple-service-features"/>.</t>
> 
> <t hangText="device:">This token has a value of two. It indicates that
> the presence agent should model the presentity as a sequence of
> tuples, each representing a "device" that can be used to contact the
> user. Examples of devices are wireless phones, PC-based IM 
> applications, 
> PDAs
> and standalone hard phones.</t>
> 
> </list>
> 
> <t>The values of the tokens have been chosen such that "presentity"
> represents the greatest level of privacy, followed by "service", and
> "device" represents the least. [[OPEN ISSUE: Should we space out the
> values to allow for other types to be defined down the road?]]. [[OPEN
> ISSUE: This permission will require roach-simple-service-features, or
> the text present in it, to proceed. What are the plans for that?]].
> </t>
> 
> <t>The default value of this permission is "presentity" or zero.</t>
> 
> </section>
> 
> <section title="Contact URI">
> 
> <t>
> The "contact-uri" permission indicates whether or not the Contact URI
> for tuples is presented to the watcher or not. This element has an
> optional "class" attribute, which indicates the class of tuples for
> which the permission applies. Absence of this attribute indicates that
> the permission applies to all tuples. There can be multiple
> "contact-uri" elements, but each of them MUST differ in the presence
> and/or value of the "class" attribute.
> </t>
> 
> <t>The "contact-uri" permission is of boolean type. A value of false
> means that the Contact URI for the associated tuples is not to be
> distributed to watchers. A value of true means that it is. By default,
> the Contact URI for all tuples is distributed to watchers.
> </t>
> 
> <t>
> For the purposes of combining permissions, the contact-uri for each
> class is treated as an independent variable. If there is a contact-uri
> without a class attribute, this is modeled as N separate contact-uri
> elements, one for each of the N tuple classes in the presence
> document. Tuples that are not explicitly labeled with a class are
> considered to belong to the same class, which we call the implicit
> class.
> </t>
> 
> <t>
> For example, consider a presence document with three tuples. The first
> one is labeled with a class of "friend", the second one is labeled
> with a class of "work", and the third has no label. This document has
> tuples in three classes - work, friend and implicit. When a watcher
> subsribes to the presence of this presentity, two rules match:
> </t>
> 
> <figure><artwork>
> <![CDATA[
> RULE 1
>    <contact-uri class="friend">true</contact-uri>
>    <contact-uri>false<contact-uri>
> 
> RULE 2
>    <contact-uri class="work">true</contact-uri>
> 
> ]]></artwork></figure></t>
> 
> <t>
> To combine these permissions, the contact-uri in the first rule
> without a class attribute is modeled as if it were three
> contact-uris:</t>
> 
> <figure><artwork>
> <![CDATA[
>    <contact-uri class="friend">false</contact-uri>
>    <contact-uri class="work">false<contact-uri>
>    <contact-uri class="implict">false<contact-uri>
> ]]></artwork></figure></t>
> 
> <t>The contact-uri for each class is then treated as an independent
> variable, and the standard combining rules are applied. There are two
> instances of the contact-uri element for friends - one with a value of
> true (from rule 1), and one with a value of false (from the expanded
> classless contact-uri). These are combined to yield a value of
> true. As a result, the contact in the tuple with class "friend" will
> be shown to the watcher. There are two instances of the contact-uri
> element for work - one with a value of true (from rule 2), and one
> with a value of false (from the expanded classless contact-uri). These
> are combined to yield a value of true. As a result, the contact in the
> tuple with class "work" will be shown to the watcher. There is a
> single instance of the contact-uri element for "implicit", with a
> value of false (from the expanded classless contact-uri). As a result,
> the contact in the tuple without a class label will not be shown to
> the watcher.
> </t>
> 
> <list style="indent"><t>
> OPEN ISSUE: There is no way to define that a contact-uri applies to
> all tuples without a class label. We could introduce that by defining
> a special value of the class attribute, say "implicit". This would
> cause problems if a presence document ever had a class label with the
> actual value of "implicit". Another choice is to define another
> attribute to the contact-uri element, say "implicit", which indicates
> that it applies to implicit classes or not.
> </t></list>
> 
> </section>
> 
> <section title="Activity">
> 
> <t>This permission controls access to the "activity" element defined
> in <xref target="I-D.ietf-simple-rpid"/>. The name of the element is
> "activity", and it is a boolean type. When true, it means that the
> RPID activity is to be distributed to watchers, and when false, means
> that it is to be withheld.
> </t>
> 
> <t>
> Like the "contact-uri" element, the "activity" element can have an
> optional "class" attribute that defines which tuples the permission
> applies to. Rules for composition are identical to those for
> "contact-uri".
> </t>
> 
> <t>
> The default value for this permission is false.
> </t>
> 
> </section>
> 
> <section title="Tuples by Class">
> 
> <t>
> This permission controls access to tuples. It indicates which tuples
> published into the presence agent will be used as an input to the
> composition process. Tuples are selected by the value of their
> "class" element. The "tuples-by-class" element has, as its content,
> the name of a specific class which is to be used as input in the
> composition process. There can be multiple instances of the
> "tuples-by-class" element, each one indicating a different
> class. [[OPEN ISSUE: Same issue as above on how to indicate tuples
> that have no explicit class.]]. The result is that the
> "tuples-by-class" element is a "set" data type.
> </t>
> 
> <t>
> The default value of this permission is "implicit", meaning that in
> absence of specific instructions otherwise, only tuples without the
> class label will be distributed to watchers.
> </t>
> 
> <list style="indent"><t>
> OPEN ISSUE: There are other reasonable chocies for this
> default. Another choice is that all tuples, regardless of class, are
> distributed.
> </t></list>
> 
> </section>
> 
> <section title="Class">
> 
> <t>
> This permission controls access to the "class" element within the PIDF
> document. This is in contrast to the "tuples-by-class", which 
> indicates
> which tuples are passed to the watcher. This permission indicates
> whether the RPID "class" element is passed to the watcher.
> </t>
> 
> <t>
> This permission is a boolean type. Its default is false, meaning that
> the class element will normally be stripped from PIDF documents unless
> the presentity instructs otherwise. The element can contain a "class"
> attribute which indicates for which classes this permission
> applies. The aggregation rules for this permission are identical to
> those for "contact-uri".
> </t>
> 
> </section>
> 
> <section title="Contact Type">
> 
> <t>
> This permission, "contact-type" controls access to the "contact-type"
> element within
> the PIDF document. It is of boolean type. When true, the
> "contact-type" element is passed to watchers. When false, it is
> removed from the document. The default value is false.
> </t>
> 
> <t>
> The element can contain a "class"
> attribute which indicates for which tuples, based on their class, this
> permission applies. The aggregation rules for this permission are
> identical to those for "contact-uri".
> </t>
> 
> </section>
> 
> <section title="Idle">
> 
> <t>
> This permission, "idle" controls access to the "idle"
> element within
> the PIDF document. It is an enumerated integer type. Its values are
> "hide", with a value of zero, that indicates that the "idle" element
> is to be removed from the presence document, "no-time", with a value
> of one, that indicates that the "idle" element is to be passed on to
> watchers, but without the specific duration for which the user has
> been idle, and "full", with a value of two, that indicates that the
> "idle" element is to be passed onto watchers, and should include a
> specific duration if available.
> </t>
> 
> <t>
> The element can contain a "class"
> attribute which indicates for which tuples, based on their class, this
> permission applies. The aggregation rules for this permission are
> identical to those for "contact-uri".
> </t>
> 
> </section>
> 
> <section title="PlaceType">
> 
> <t>
> This permission, "placetype" controls access to the "placetype"
> element within
> the PIDF document. It is of boolean type. When true, the
> "placetype" element is passed to watchers. When false, it is
> removed from the document. The default value is false.
> </t>
> 
> <t>
> The element can contain a "class"
> attribute which indicates for which tuples, based on their class, this
> permission applies. The aggregation rules for this permission are
> identical to those for "contact-uri".
> </t>
> 
> <list style="indent"><t>
> OPEN ISSUE: Do we want any finer grained permissions than just whether
> to include, or not include, placetype in the presence document?
> </t></list>
> 
> </section>
> 
> <section title="Privacy">
> 
> <t>
> This permission, "privacy" controls access to the "privacy"
> element within
> the PIDF document. It is of boolean type. When true, the
> "privacy" element is passed to watchers. When false, it is
> removed from the document. The default value is false.
> </t>
> 
> <t>
> The element can contain a "class"
> attribute which indicates for which tuples, based on their class, this
> permission applies. The aggregation rules for this permission are
> identical to those for "contact-uri".
> </t>
> 
> </section>
> 
> <section title="Relationship">
> 
> <t>
> This permission, "relationship" controls access to the "relationship"
> element within
> the PIDF document. It is of boolean type. When true, the
> "relationship" element is passed to watchers. When false, it is
> removed from the document. The default value is false.
> </t>
> 
> <t>
> The element can contain a "class"
> attribute which indicates for which tuples, based on their class, this
> permission applies. The aggregation rules for this permission are
> identical to those for "contact-uri".
> </t>
> 
> </section>
> 
> <section title="Sphere">
> 
> <t>
> This permission, "sphere" controls access to the "sphere"
> element within
> the PIDF document. It is of boolean type. When true, the
> "sphere" element is passed to watchers. When false, it is
> removed from the document. The default value is false.
> </t>
> 
> <t>
> The element can contain a "class"
> attribute which indicates for which tuples, based on their class, this
> permission applies. The aggregation rules for this permission are
> identical to those for "contact-uri".
> </t>
> 
> </section>
> 
> <section title="Example Document">
> 
> <figure><artwork>
> <![CDATA[
> 
> <?xml version="1.0" encoding="UTF-8"?>
>     <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
>         xmlns:pres="urn:ietf:params:xml:ns:pres-policy">
> 
>       <rule id="f3g44r1">
> 
>         <conditions>
>           <identity>
>             <uri>[email-masked]</uri>
>           </identity>
>           <validity>
>             <from>2003-12-24T17:00:00+01:00</from>
>             <to>2003-12-24T19:00:00+01:00</to>
>           </validity>
>         </conditions>
> 
>         <actions>
>           <confirmation>true</confirmation>
>         </actions>
> 
>         <transformations>
>           <pres:view>service</pres:view>
>           <pres:activity>true</pres:activity>
>           <pres:tuples-by-class>business</pres:tuples-by-class>
>           <pres:tuples-by-class>work</pres:tuples-by-class>
>           <pres:class class="work">true</pres:class>
>           <pres:idle>no-time</pres:idle>
>         </transformations>
> 
>       </rule>
> 
>     </ruleset>
> 
> ]]></artwork></figure>
> 
> </section>
> 
> <section title="More Open Issues">
> 
> <list style="symbols">
> 
> <t>OPEN ISSUE: Is the naming of these permissions confusing? Each
> permission has the same name as the PIDF/RPID element it controls
> access to. Namespaces will make it clear which is which, but we could
> use different names if it was confusing.
> </t>
> 
> <t>OPEN ISSUE: Right now, the permissions apply to all tuples, or to
> tuples selected by class. There is no other way to select which tuples
> the permission applies to, except for class. We could extend the
> attributes to allow for selection based on other thing - for example,
> placetype or sphere. The aggregation process begins to get
> complicated, however, and I'm not sure how to do it.
> </t>
> 
> <t>OPEN ISSUE: Do we want a way to specify any syntactic-based
> authorization policies, in order to allow the server to handle
> permissions for new presence elements without simultaneously
> supporting the permission schemas for those elements?
> </t>
> 
> </list>
> 
> </section>
> 
> -- 
> 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
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2004 09:13:49 -0500

I think it would be helpful to discuss these issues separately; they 
have little to do with each other.

[email-masked] wrote:

> * Exceptions: Currently they are allowed only within domains. This
> was done on purpose for reasons that I don't really believe in. The
> end result is that it is impossible to do proper block-listing. It
> was claimed that block-listing is a bad concept anyway, as identities
> can be created easily to by-pass such lists. While in general this is
> the case, I don't think it should limit _all_ systems, some of which
> can deal with identities better than the Internet at large. Below is
> an example, beyond block-listing, how leaving out exceptions makes
> things difficult [Presentity wants to give group "friends" a
> privileged access to his presence information. By default he gives
> out some information, but "friends" should receive a different view
> of the _same_ information. (Note that this is not additive, but we
> talk about different views, for instance showing a _different_
> "note".) If exceptions are not allowed, "friends" will get the common
> information in addition to what should be given to them, making
> things confusing at the watcher side. (For instance a watcher get 2
> tuples with the same Contact, having different notes.)] So I believe
> the main problem is that presence information is not always additive,
> but it can also be contradictive! Another huge problem is that there
> already exists many presence systems which have block-lists, and in
> some cases we would like to preserve the UI semantics even when the
> protocol stack is changed to SIP. Now it seems impossible. ->
> Proposal: Allow exceptions in SIMPLE, even though they are not there
> in the common policies.

I don't understand this comment. Black lists can easily be implemented 
by splitting them across domains. This is just a syntactic transformation.

The note issue ('different information') is a more interesting one. We 
had earlier decided not to support lying, so this seems to refer only to 
free-form fields like 'note'. The problem you note can be solved within 
the framework by an ordering mechanism that associates a value with a 
parameter. That way, the highest ("best") value would be picked, but 
only one, instead of all. I think the easiest would be to associate an 
ordering with 'class' and just have the publisher upload different 
tuples. I don't think it makes sense to use the policies to set actual 
presence values.

Exceptions greatly complicate the processing and, in conjunction with 
external lists, are privacy-unsafe. Thus, I'm opposed to including such 
mechanisms. Since people mean many different things when they talk about 
exceptions, it would be helpful if you could actually state an exception 
rule that you envision.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2004 09:13:49 -0500

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2004 09:19:28 -0500

> * External lists: Again, external list references were dropped due to
> GEOPRIV harmonization. I don't understand why they need to be
> disallowed in all environments. If the service provider has a
> centralized XCAP server for resource lists, those should be usable by
> reference in presence auth. rules. (FYI, OMA is working on common
> "group management" for different applications, and for this external
> references are also clearly needed.) -> Proposal: Add external lists,
> include considerations on where they are usable.

External lists are a separable issue. I would suggest that if this is to 
be supported, it should be a separate 'layer'. That layer would simply 
consist of a list of URI or local references identifying rule sets 
elsewhere. That nicely separates rules from references to rules. I see 
no advantage in commingling them.

The difficulty with separate lists is to define the appropriate caching 
and failure behavior (how long should the rule maker try to get the 
external rules? is normal HTTP caching used?)

As noted earlier, external lists are manageable from a privacy 
perspective if they are additive. They break badly if you allow 
exceptions that remove privileges.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2004 09:19:28 -0500

Henning

---

From: Ted Hardie <[email-masked]>
Date: Tue, 23 Mar 2004 11:44:57 -0800

At 1:04 AM +0200 03/23/2004, [email-masked] wrote:
>* Exceptions:
>Currently they are allowed only within domains. This was done on 
>purpose for reasons that I don't really believe in. The end result 
>is that it is impossible to do proper block-listing. It was claimed 
>that block-listing is a bad concept anyway, as identities can be 
>created easily to by-pass such lists. While in general this is the 
>case, I don't think it should limit _all_ systems, some of which can 
>deal with identities better than the Internet at large. Below is an 
>example, beyond block-listing, how leaving out exceptions makes 
>things difficult
>	[Presentity wants to give group "friends" a privileged access 
>to his presence information. By default he gives out some 
>information, but "friends" should receive a different view of the 
>_same_ information. (Note that this is not additive, but we talk 
>about different views, for instance showing a _different_ "note".) 
>If exceptions are not allowed, "friends" will get the common 
>tuples with the same Contact, having different notes.)]
>So I believe the main problem is that presence information is not 
>always additive, but it can also be contradictive! Another huge 
>problem is that there already exists many presence systems which 
>have block-lists, and in some cases we would like to preserve the UI 
>semantics even when the protocol stack is changed to SIP. Now it 
>seems impossible.

I think you are, in fact, asking for two things here:  a different 
view of how information
flow works and a change in permission processing.

I think the mental model of information flow is "there is data about 
reality, which
is revealed at different levels of accuracy based on permission"; 
with polite lying,
some of those "levels of accuracy" are lies.  You seem to be proposing that
there are different data sets associated with groups; these aren't 
due to permissions
that state how close to the full set of "real data" this data is , 
but that these are
sets that are independent of each other, and seem to me to imply that
their relationship to the "real data" isn't as important as their relationship
to the group to whom the data will be given.  The permission processing
isn't really "here is the level of accuracy for this group" but "here is
the data set for this group".

My take on this may be colored a bit by GeoPriv, but I don't think
this is a very useful change.  For a system that is fundamentally
about presence, a view that there is a set of real presence data
("currently typing up a message to simple") that may be reflected
in various ways ("busy" to a general watcher, "in my office" to my
colleagues, "interrupt okay" to my boss) seems to me pretty useful.
When I leave for lunch, all can be appropriately updated with
relation to the real data ("away" to a general watcher, "temporarily
out of office" to my colleagues, "available by cell" to my boss).

In a much more abstract system describing my characteristics,
I could see a different view.  For a "favorite record"
entry, for example, I could see saying "Stunt" to one set of people,
"Rhythm of the Saints" to another, and "Carcassonne" to a third; these
might reflect the kind of music I'd like to listen to with those people.  But
these are relatively long lived entries, and unlikely to need updating
on a many-times-a-day basis.  For entries which do,  updating
each entry for each group each time would be painful.  The
practical result of that is that you would have to define relationships
among the groups' data sets, so that an update to an entry is
reflected correctly in the others without having to define what
the new value is in each set.  Doing that from a "base" set (a.k.a.
the real data) seems like a useful model, since the application
of the rules is cleaner than having set 5 depend on set 3 which
depends on set 1 (which in the worst case depends on set 5 and
runs you into real trouble).

The exception processing issue is trickier, because I believe that there
was common agreement that exceptions would be a very powerful
tool, but that they were a fair number of cases where they were difficult
to get right without ordering.  In the case where one rule might grant
access to a piece of information and another forbid access to that
piece of information, you have to have a precedence mechanism
that says which one is implemented; that looks easy to get right,
but in complex rule sets it can get very hairy very quickly.  I
was originally against even the domain-based exceptions, but the
careful crafting of a rule that avoids the precedence processing
has convinced me that that exception can be implemented without
too much risk of silly states.  But a general "let's allow exceptions
again" raises all those issues again, without answering them; a
concrete proposal for how to get them right would be much
more valuable.

>* External lists:
>Again, external list references were dropped due to GEOPRIV 
>harmonization. I don't understand why they need to be disallowed in 
>all environments. If the service provider has a centralized XCAP 
>server for resource lists, those should be usable by reference in 
>presence auth. rules. (FYI, OMA is working on common "group 
>management" for different applications, and for this external 
>references are also clearly needed.)

I'm not clear on which external lists you mean; external lists making up group
membership or external lists describing rules.  If the latter, I think you may
be arguing at cross purposes to your desire to move away from additive
rules.  With additive rules, the failure to resolve an external list containing
rules implies that the group to whom the list is applied will get *less* than
they might (which is unfortunate, but not a privacy problem).  With the
model you proposed above, the list might contain exceptions and the failure
to resolve it may mean individuals who ought not get data do.  That's
a real issue.  A concrete proposal on how to allow them and where would
again be more useful than a general proposal, at least in my opinion.

>I believe these two modifications would make SIMPLE presence rules 
>much better deployable in practice, and more easily endorsed 
>directly by e.g. 3GPP and OMA.

These groups have been in the minds of folks preparing the docs all along, so
more concrete references to the issues would be helpful; if you believe
that there are requirements these groups have for this work that are not
being addressed, a liaison statement containing that requirement is always
useful.  The IETF reserves, of course, the right to decide that a requirement
cannot be met within the bounds of an appropriately designed system, but
it does appreciate understanding more fully the needs of specific
deployments.

Speaking for myself,
			regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 23 Mar 2004 11:44:57 -0800

Speaking for myself,
			regards,
				Ted Hardie

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Mar 2004 03:26:43 -0500

> concrete proposal for how to get them right would be much

Two points.

Firstly, I think that any external lists would have to follow the same 
model as the current domain exceptions. That is, they are not "global" 
exceptions; they merely serve to identify the set of people to whom this 
particular rule applies. This addresses Ted's concerns.

Henning has correctly pointed out that there are non-trivial issues 
involved in external lists, notably around error processing. While I 
agree that they are issues, they hardly seem insurmountable. In fact, 
the right thing to me seems to be:

1. if the external list cannot be obtained, then the rule must not be 
applied to the watcher (this provides privacy safety)
2. the external list cannot be cached unless there is a reliable way to 
perform cache synchronization. In other words, the PA must be able to 
ensure that the list it is using is current.
3. The amount of time to wait before giving up a fetch of the list is a 
matter of local configuration.
4. A presence server can cache the fact that it was unable to fetch the 
list, and then next time a request arrives, assume that it cannot be 
obtained. In such a case, point 1 applies. This will speed up presence 
processing, remain privacy safe, but at the cost of proving users with 
less information than they might otherwise be entitled to.

I also think that the external list is, as the name implies, a reference 
to a list of URI that resides elsewhere. It is not a reference to an 
external ruleset, as I think Henning has suggested. In one iteration of 
the xcap authorization rules, the URI was an xcap resource that resolved 
to a list of URI in the resource-lists application usage.

Does anyone see problems with this?

I would therefore suggest that we pursue extternal lists as a separate 
document, which can follow shortly after the baseline specification.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Mar 2004 03:26:43 -0500

Two points.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2004 17:48:44 -0500

Part of the confusion is that, like exceptions, external rule sets have 
had different meanings in different groups. We've had one discussion, 
along my lines of thought, in GEOPRIV and another one in SIMPLE.

There seem to be two definitions:

- external rulesets containing whole rules
- external lists of identities within a single rule

I agree that the second one can be handled in a privacy-safe manner, 
although it makes implementations much less efficient if the PA cannot 
expand the list when submitted and has to consult it on each matching 
operation. Among other problems, it makes a database implementation 
impossible.

Making it a separate document would presumably also allow a server to 
say "no thanks" if it does not want to take the performance hit.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2004 17:48:44 -0500

Henning