Subject: [Asrg] 4d. Consent Framework - Protocols and Formats - XML Based

From: "Pete (Madscientist)" <[email-masked]>
Date: Fri, 15 Aug 2003 16:31:43 -0400

ASRG folks,

I have started a web site for the development of an XML based CPDL
(Consent Policy Description Language).

I have also posted a boilerplate example that we can refine until we are
happy with it. I know there are a number of examples and notes that are
missing from the boilerplate. I will review the archives and "massage
them in" to the example document as I have time - I am out of time for
today.

The site is at the following URL.
Comments are strongly encouraged.

http://www.sortmonster.com/ASRG/

I recommend - for sanity's sake - that comments on this particular
project should use the same subject line as this note so that I can more
easily keep up with the editing process.

My time is limited, but I believe I can keep up with this project for
the time being. If I begin to fall behind I will make arrangements to
coordinate with other volunteer editors... but for now let's try to keep
things simple.

Thanks,
_M

Pete McNeil (Madscientist)
President, MicroNeil Research Corporation
Chief SortMonster, www.SortMonster.com
VOX: 703-406-2016
FAX: 703-406-2017

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 18 Aug 2003 15:54:21 -0400

>http://www.sortmonster.com/ASRG/

Any particular reason why the implementation specific details are included 
within the same XML files? Consent policies will need to be 
implementation-independent and it might be a good idea to split them up 
into two XML files. This is similar to the way the J2EE platform handles 
deployment - two XML files are provided, one vendor and implementation 
neutral, and the second implementation-specific.

Also, do we need to include the identification of the person or system that 
the policy applies to?

Yakov

---

From: "Pete (Madscientist)" <[email-masked]>
Date: Mon, 18 Aug 2003 18:13:18 -0400

|>The site is at the following URL.
|>Comments are strongly encouraged.
|>
|>http://www.sortmonster.com/ASRG/
|
|Any particular reason why the implementation specific details 
|are included 
|within the same XML files? Consent policies will need to be 
|implementation-independent and it might be a good idea to 
|split them up 
|into two XML files. This is similar to the way the J2EE 
|platform handles 
|deployment - two XML files are provided, one vendor and implementation 
|neutral, and the second implementation-specific.

I agree. I am showing them in the same file for now so that those who
have suggested scripting as a method of defining CPDL might see how that
might be implemented with the framework.

In the end we may decide to allow the separation of any number of
components of the CPDL.

Though the reference does not show it yet I think we should also define
language for including segments. This might satisfy the separation by
itself. I consider the part of the work that allows the inclusion of
segments to be part of the inheritance and sharing models so I've not
clarified that yet in the reference.

Presumably the specification would allow for a specific implementation
to derive a complete policy for a given scope from any number of other
policies available by using some rules to define how this merge takes
place.

In the broadest sense this may include merging parts of the CPDL that
define implementation where certain systems may provide features on a
group and/or user basis... or may provide facilities to allow user
provided features.

I think we should allow for this flexibility but we should be careful
not to make the mechanisms for separating segments of the CPDL overly
complex. I'm hopeful we can define a few simple mechanisms and rules
that will provide the bulk of this capability, along with some broad
room for implementation specific enhancements.

For now at least I think the reference should move ahead with all parts
combined - perhaps with the understanding that what we see in the
reference would be the effective combined result of an implementation's
use of inheritance, sharing, and isolation mechanisms.

(Given the nature of XML, it is generally easy to visualize how each
element might translate into an object in software. Therefore,
expressing the entire composition in a single document may help to imply
the necessary linkages so that those too might be evaluated... this will
make for a good specification that can be readily translated into
working code... (works for us usually!)).

This will allow us to concentrate first on language elements and their
interactions. Once that part is stabilized we can create implementation
references to act as examples of each facility at work.

|Also, do we need to include the identification of the person 
|or system that 
|the policy applies to?

Yes. I have some thoughts on that and will be making a stab at it
shortly. Again this touches on inheritance and sharing mechanisms since
one will need to be able to define the 'who' in "who owns this policy",
"who can see these policy elements", "who did I inherit these elements
from", etc...

The sharing mechanisms are the next "hard problem" I plan to focus on.
The implementation of tests, and the creation of policies seems to be
largely solved and is now a matter of exploration, iteration and
refinement.

I'll focus more on the sharing mechanisms next.

Suggestions are welcome.

_M