Subject: RE: [Simple] presence-rules: providing all attributes

From: [email-masked]
Date: Mon, 17 Jan 2005 23:29:32 +0200

Hi,

Yes, I agree that there should be a shortcut for saying "give everything". I think both <provide-all-attributes> and <provide-all> would be useful. I suppose all attributes would mean also all "unknown" attributes.

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Robert Sparks
> Sent: 15 January, 2005 16:10
> To: Simple WG
> Subject: [Simple] presence-rules: providing all attributes
> 
> 
> I had an offline conversation with Jonathan about the minimum
> statement a presentity needs to make to say "give the matching
> subscriber everything in my presence document". Currently,
> that requires a pretty beefy transformation section for something
> that's likely to be a common policy to assert.
> 
> We discussed adding a shorthand like <provide-all-attributes>
> inside each of person, service, device, or even a <provide-all>
> at the transformations level.
> 
> Thoughts?
> 
> RjS
> 
> 
> _______________________________________________
> 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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Jan 2005 21:32:55 -0500

I'd propose that we have a "provide-all-attributes" that is similar to 
"provide-unknown-attributes" This would provide attributes across the 
device, service and person components of the document.

One important point on the impact of this on combining of authorization 
documents.

THe common policy document talks about the computation of the value of a 
permission when it appears more than once based on data-type specific 
operations - MAX for integers, union for sets, OR for booleans. This 
works great under the assumption that each permission in the rule covers 
a non-overlapping part of the document; that is, for any part of the 
document you are interested in, its inclusion in the document is based 
on the value of a single permission in the rules. Thus, construction of 
the final document is fully spceified by the meaning of each permission 
and the generic combination rules.

However, adding a <provide-all> means that the inclusion of a piece of 
data in the presence document, say the <activities> element, now depends 
on the value of two permissions - <provide-all> and 
<provide-activities>. Thus, there needs to be a rule about combining 
those too, in a way that is consistent with the architectural principles 
of the common policy framework.

In thise case at least, I think its relatively easy. A particular 
attribute is included if its specific rule (provide-foo) indicates that, 
OR if the <provide-all> is present. In essence, <provide-all> can almost 
be considered as a macro, expanding out into a sequence of <provide-foo> 
for every foo in the document. Indeed, I think it probably makes sense 
to define it explicitly that way, so as it fits within the framework of 
the combining rules. That is, if you define it this way, then it is 
still the case that the final document is determined by the semantics of 
each permission along with the generic combining rules. You don't need 
to specify more combining rules specific to new permissions.

That does have an interesting implication in your selection of an 
initial set of permissions. Ideally, you want those to be fairly fine 
grained, so that you could specify future permissions that affect the 
same data through a macro operation that expands into a series of these 
more fine-grained rules.

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