ietf-asrg
[Top] [All Lists]

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

2003-08-21 11:40:17
|-----Original Message-----
|From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org] 
On 
|Behalf Of Andrew Akehurst

|Quoting Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>:
|
|> At 04:31 PM 8/15/2003, Pete (Madscientist) wrote:
|
|>> I have started a web site for the development of an XML based CPDL 
|>> (Consent Policy Description Language). ... 8< ...
|>>
|>> 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.
|
|This aspect of the CPDL issue is important. I agree with Yakov 
|that separating the implementation from the overall standard 
|is desirable.
|
|In particular, perhaps I have misunderstood your intentions with 
|regards to the scripting of tests and actions using the 
|"method" attribute. I'll elaborate in order to make my 
|concerns more clear...

An implementation may choose to have separate files for any part of the
XML-CPDL, and we may even recommend that as a "best practice", however
since the elements describing the implementation are contained within a
unique data structure there is no reason that they cannot live within
the same file. In fact I know that ability would make management and
debugging much easier in some cases. (more later in context).

<snip>

|Usually a machine language is either
|
| - declarative: it specifies what form the result should take but not 
|   the algorithm or specific code to do it. (e.g. PROLOG)
|
| - imperative: it specifies the precise sequence of actions
|   (the algorithm) to execute a program. (e.g C, Java etc.)
|
|Your example XML file seems to merge both aspects. The trouble 
|is that specifying algorithms in a way which works seamlessly 
|across multiple platforms and environments is difficult to 
|achieve and rarely works well in practice. Languages like PERL 
|and Java have improved things somewhat but anyone who has used 
|them in a cross-platform scenario will tell you that there are 
|still many implementation-specific issues which require very 
|careful use of the language. 

All true. 

The example shows the _ability_ to include implementation specific
elements, but it does not necessarily require them. It is presumed that
any implementation specific code would not be shared unless there were
an agreement between the peers to do so - thereby implying
compatibility.

Any TESTS or ACTIONS which are on the _must implement_ list would be
enacted using a "well known name" so that any POLICY would be guaranteed
to have consistent use of those features. The implementation of those
features _might_ be proprietary in a particular SYSTEM, however that
implementation would only be shared if the peers agreed that the
implementation coding was compatible.

It is expected that implementation sharing would occur primarily between
different SYSTEMS in the same installation - where the administrator of
that installation has complete control over all of the systems involved.

IMPORT and EXPORT rules provide a ready means to control which parts of
a given CPD might be shared, and each SYSTEM has the final word on it's
local policy regarding what is shared and how potentially incompatible
elements will be resolved. The default resolution for an incompatible
element (procedural or declarative) is to reject the IMPORT of that
element.

|In the case of e-mail, the proliferation of mailbox formats and 
|system-specific locations alone makes trying to script such 
|things (in general) very difficult. There will always be an 
|implementation 
|layer which must translate script commands into 
|system-specific behaviour.

True. The TESTS and ACTIONS sections provide a location for that
implementation layer. These sections are not necessarily shared between
SYSTEMs, and they need not be within the same file. However the
structure of the XML-CPDL allows them to be without necessarily causing
a conflict.

In general it is presumed that a given SYSTEM will rely primarily (if
not entirely) on it's local implementation, but _may_ share POLICY
elements between many other SYSTEMs.

(BTW: I plan to encapsulate the TESTS and ACTIONS sections into an
IMPLEMENTATIONS section which will be symmetrical with the POLICIES
section based on an earlier review of RFC3060. Perhaps when this is done
these issues will become clearer.)

|What I would suggest is that certain tests and policy actions 
|should be regarded as being fundamental primitives which all 
|CPDL conformant 
|consent-based systems must support. These would probably 
|include basic tests like "header X matches expression Y" and 
|essential policy actions such as "allow delivery" and 
|"silently discard message".

Agreed. We need to develop a list of TESTS and ACTIONS that are on the
"must implement" list. We will create instances of these in the XML-CPDL
example document.

Must Implement TESTS and ACTIONS must be defined with a standard set of
inputs that are required (if any) and a standard "well known name" (id)
that must be used to be compatible with the specification.

POLICY definitions can then rely on these TESTS and ACTIONS to exist and
to perform according to the specification.

Specific implementations of the XML-CPDL can then customize these
locally if desired and if the software allows for this, however a
requirement for compliance will be that any customization to a required
TEST or ACTION implementation must be such that policies that use those
customized elements will perform as specified if they are shared with
other SYSTEMs.

An example of an appropriate customization might be:

-- The software developer provides a "standard implementations"
component to their software which includes "method" tags and scripts
that produce the required results. These scripts could be in any
language (or none) that is selected by the software developer - that is
to say they are implementation specific.

-- The administrator of the system determines the need to modify one of
the "standard implementations" to fit their specific needs - perhaps to
add a logging component or to trigger some other actions that are
necessary for their installation.

Perhaps:

Original - <ACTION... method="Reject();" />

Modified - <ACTION... method="Reject();LogInstance();..." />

In order to remain compliant the outwardly visible result of the ACTION
must be compatible with the specification for the "standard
implementation".

Presumably administrators using identical software in their
installations might wish to duplicate customized implementations - and
they would be able to do so either by IMPORTing those implementations or
by simply coding them locally.

I mention IMPORT again here because the ability to IMPORT and EXPORT
implementations can be a powerful administrative tool.

The software developer might use this ability to distribute upgrades and
corrections to their users.

Administrators of large installations might use this ability to
implement site wide changes.

|Then such primitive tests and actions would not need to be 
|defined in terms of additional scripting languages: any 
|conforming MUA or MTA could implement them in whatever 
|specific way suits its own low-level implementation details. 
|(And indeed MUST implement them in order to comply with the standard.)

An implementation is not required or expected to provide a mechanism for
customizing "well known" tests or actions, but they may. They _must_
implement them in order to be compliant with the standard.

|Then you can concentrate on defining additional tests and 
|actions via some external mechanism, either in terms of the 
|primitives or by using some additional libraries. 

The intent in the XML-CPDL example is to provide a link between the CPDL
and any libraries or functions that are provided by the implementation's
software. It is possible that an implementation would chose to have all
scripting of any kind completely outside of the CPDL and that it would
simply publish the names of the available TESTS and ACTIONS in the file
for compliance. 

However, it is likely to be more practical to allow an implementation to
integrate some of this scripting/customization capability within the CPD
itself since that capability consolidates many administration tasks.
This is why the examples are shown this way.

|I do still believe that the definition of such extensions should 
|be somehow distinct from the definition of the policy. It 
|depends on what you intend the "method" attribute on ACTION, 
|TEST etc. to mean and on what an IMPORT element is importing. Either:
|
|a) Do you mean that it is to be used like a C ".H" header file? 
|ie. it specifies which functions are available to be called 
|and their function signatures, but the actual executable code 
|is held in a binary library file somewhere else in the filesystem? 

That is one possibility. And, in fact, a more aggressive isolation might
simply state that the ACTION or TEST be named and empty in the CPD in
order for it to be enabled.

|
| ... or... 
|
|b) Did you intend to embed actual script language commands 
|within the same XML file as the rest of the policy definition?

This is also possible, and I believe the most likely/practical
implementation in many cases.

The XML-CPDL does not, and I believe should not, exclude either
possibility and explicitly leaves that choice to the implementer.

|In principle I'm not opposed to (a), although I do still 
|wonder about the effect of references to non-standard policies being 
|shared from a system with the correct code library to another 
|system which lacks that library. This may simply be an issue 
|of careful scope definition, however it's why I'm arguing in 
|favour of some essential primitive elements common to all such 
|systems. Then there would always be a guaranteed minimum 
|consent policy level which could be safely imported and 
|exported as needed.

Presumably if a SYSTEM were IMPORTing policy elements from an
incompatible peer, the IMPORT and EXPORT policies would be established
so that only compatible elements would be shared. If an incompatible
implementation or policy were imported then the importing system would
either refuse the import entirely, refuse the incompatible elements,
and/or produce some kind of error. This behavior would also be
implementation specific with the provision that any system implementing
the XML-CPDL standard would be required to accept well formed policies
that utilize only well known TESTS and ACTIONS.

The linkage between those TESTS and ACTIONS with the local SYSTEMs
implementations is based only on the "well known names" so that it is
not necessary to import any implementations from a publishing peer.

|I see (b) as a way of resolving the issue of missing libraries 
|at run-time which occurs with (a). However it mixes definition 
|with implementation detail, which I've already said I'm 
|sceptical about - not least because of the work involved in 
|designing and 
|implementing a new imperative scripting language from scratch.

Presumably the best implementations would use a well known scripting
language or variant such as Pearl, Java, JavaScript, etc... and would
provide library functions that hook into their software. None the less,
the choice of language (if any) is implementation specific.

|I get the impression that your use of the IMPORT element might 
|provide a way around these problems. However the comments in 
|that same file don't make it clear *what* you're importing or 
|how it might be used by conformant software. Perhaps you could clarify?

I will work on the file a bit to clarify the meanings. I admit that the
current file is very sparse. I think it will also make good sense for me
to create a descriptive companion document so that the example XML-CPDL
can be more representative of "live" XML-CPD - I knew this time would
come.

|YS> Also, do we need to include the identification of the person or
|YS> system that the policy applies to?
|
|Why might this be useful? In principle I don't object unless 
|people are forced to include such details (because then there 
|are privacy issues involved).
|
|If anyone wants to include such details then maybe they should 
|be able to. However I can't think why anyone would want to. Do 
|you have an example?

Presumably an implementation might allow a SYSTEM to append any amount
of identifying data, public keys, etc... Presumably there will be some
standard names for many of those elements and perhaps some of them may
be required.

In general, the identity of a SYSTEM in the current example is defined
entirely in the local context. Any relationship to an external identity
system is implementation specific and potentially optional.

Currently, a SYSTEM defines itself and peer systems within it's own CPD.
The definition of peer SYSTEMs must provide at a minimum the information
required to communicate with that SYSTEM given the facilities of the
implementation in question. From that perspective the identity of any
SYSTEM is entirely local by default.

Consider A<-->B<-->C<-->A

A has a local SYSTEM definition for B and C.
B has a local SYSTEM definition for A and C.
C has a local SYSTEM definition for B and A.

Each SYSTEM by default considers it's peers to be entirely separate and
unique. The relationship it has to it's peers is entirely defined by
it's local elements.

The only outward identity for these peers depends upon an external
mechanism such as DNS.

That said, an adaptive implementation of this specification might create
or use any number of naming systems, policies, and algorithms to
periodically reorganize a network of SYSTEMS.

We have been researching and proposing implementations like this for
some time - where a collection of CPD based SYSTEMS (cellular automata)
might elect peers based on the affinity of their policies. This network
might then continually adapt to changing policy decisions at leaf nodes
so that the work of implementing the policies would be highly optimized.
(This discussion is beyond scope.)

At any rate, the notion of "identity" has only local scope in the
XML-CPDL by default. Higher level capabilities would be implementation
specific.

_M


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg