Subject: [Geopriv] Re: Supported Permissions

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Dec 2003 03:01:31 -0500

Tschofenig Hannes wrote:

> Hi Jonathan, Hi all,
> 
> in section 5 of the xcap-authz draft so-called "supported
> permissions" are described. if i understood them correctly then
> their purpose is to allow the entity which creates the rules to
> dynamically determine the current version of the xcap-authz
> policies (i.e., which xml attributes are understood by the server).

Right. The main reason is for a single client to be able to be used 
against multiple service providers.

> 
> 
> it is certainly important to think about extensibility of the
> authorization policies. in geopriv we have also thought a little
> about these issues. have you thought about other mechanisms for
> determining the version? maybe there are simpler mechanisms.

There has not been much discussion on alternate mechanisms.

> 
> looking at the example in section 5.6 i had the impression that you
> also combine the authorization policies with the actual data. i
> think that some information is missing in the xml schema (and in
> the example) to be complete. in any case i think that they should
> be separated. please correct me if i misunderstood your intention.

The way I designed the schema for this is that the supported 
permissions are declared by including a valid statement that includes 
all of the supported permissions. In order to be valid, the statement 
has to include values for some of the attributes (for example, 
show-element). However, the value is irrelevant.

Thinking about this some more, perhaps a better way to do it is like this:

<supported-permissions>

   <enum name="show-element"/>
   <enum name="show-namespace">
     <value>namespace1</value>
     <value>namespace2</value>
   <integer name="accuracy">
     <max-value>100</max-value>
     <min-value>1</min-value>
   </integer>

</supported-permissiosn>

In other words, elements are defined for each of the data types 
supported (integer, boolean, enumerated token list). The actual 
permission is included as the value of an attribute. We could also 
include constraints, such as the set of supported values for a token 
list, or a range for an integer.

What do folks think of this?

-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

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