Subject: [Simple] Re: pres-rules: extensibility

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Nov 2004 02:49:52 -0500

inline.

[email-masked] wrote:

> Hi,
> 
> The I-D says about extensibility:
> 
> 6.  Schema Extensibility
> 
> It is anticipated that future changes to this specification are 
> accomplished through extensions that define new types of permissions.
>  These extensions MUST exist within a different namespace. 
> Furthermore, the schema defined above and the namespace for elements 
> defined within it MUST NOT be altered by future specifications. 
> Changes in the basic schema, or in the interpretation of elements 
> within that schema, may result in violations of user privacy due to 
> mis-interpretation of documents.
> 
> If someone extends the schema defined in the draft in a new
> namespace, the result could be a new authorization document with
> different semantics. 

Different, in the sense that it adds new permissions - yes. different, 
in that it changes the meaning of existing permissions - no.

> So, when applying the extended authorization
> document on a raw presence document, authorization decisions are
> probably different as when applying the same authorization document
> restricted to the "original" namespace. The question is whether it is
> still makes sense to store the extended document under AUID
> "pres-rules" (or one should reserve a new AUID?), as Presence Servers
> understanding only the schema defined in
> draft-ietf-simple-presence-rules-01 (and ignoring the extensions)
> could make incorrect decisions.

I think they should all use pres-rules. I don't see what the problem is 
with doing that, or what changes if they are placed under a different auid.

-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

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

---

From: "Thanos Diacakis" <[email-masked]>
Date: Wed, 3 Nov 2004 12:53:13 -0700

If any extensions make the authorization rules more restrictive, then an
application that doesn't understand the extensions, would not be able to
apply them correctly.

Using the same AUID would tell the application that the contents of the
documents conform to the semantics of "presence-rules", which would clearly
not be the case.

If a different AUID was used, then the application would have to understand
that AUID and what the semantical implications are, due to the utilized
extensions.

Thanos

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Wednesday, November 03, 2004 12:50 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Simple] Re: pres-rules: extensibility
> 
> inline.
> 
> namespace, 
> > the result could be a new authorization document with different 
> > semantics.
> 
> Different, in the sense that it adds new permissions - yes. 
> different, in that it changes the meaning of existing 
> permissions - no.
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Nov 2004 18:53:14 -0500

> application that doesn't understand the extensions, would not be able to

The authorization policies are designed to be privacy safe. New 
permissions defined in extensions can only grant access to data - they 
can never restrict it. As such, if a client places a document onto a 
server, and the server doesn't understand some of the extensions, in the 
worst case, the server will give out less information than the 
presentity had desired.

In any case, if xcap is used, the client can discover what namespaces 
are understood by the server ahead of time, and avoid using permissions 
the server won't understand.

> documents conform to the semantics of "presence-rules", which would clearly

It is the case; presence-rules were designed to support extensibility, 
and the model above is part of that.

> that AUID and what the semantical implications are, due to the utilized

I just don't see how this can work. If you assign an auid for each 
extension (i.e., for each new schema/namespace that defines new 
permissions), what would you do with a document that contains 
permissions from multiple namespaces? This ends up being a combinatorial 
explosion.

-Jonathan R.