|>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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg