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...
My own intuition is that there's a clue in the name "CPDL". We're
talking about a consent *policy definition* language. Your initial
draft seems to mix together two aspects:
- the definition and enumeration of which actions and tests exist
- the code which implements the evaluation of those tests and the
execution of those actions
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.
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.
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".
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.)
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.
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?
... or...
b) Did you intend to embed actual script language commands within
the same XML file as the rest of the policy definition?
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.
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.
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?
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?
Andrew
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg