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

From: Andrew Akehurst <[email-masked]>
Date: Wed, 20 Aug 2003 20:38:05 +0100 (BST)

Quoting Yakov Shafranovich <[email-masked]>:

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Pete (Madscientist)" <[email-masked]>
Date: Thu, 21 Aug 2003 14:37:53 -0400

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Andrew Akehurst

|Quoting Yakov Shafranovich <[email-masked]>:
|
|> 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

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 22 Aug 2003 00:48:11 -0400

At 03:38 PM 8/20/2003, Andrew Akehurst wrote:
>.........
>...........

One thing that could be done here is to create an IANA registry for 
maintaning the basic primitives in order not to publish another RFC.

>able to. However I can't think why anyone would want to. Do you

o A user who needs to merge his policy with the ISP's. It would be useful 
to include the identification of the ISP in the policy.
o Two parties exchanging consent tokens and policies. ID is needed.

Yakov

---

From: "Christopher Bird" <[email-masked]>
Date: Sun, 24 Aug 2003 16:58:53 -0500

As part of the work on consent frameworks, is there a proposal somewhere
to allow a user or delegated administrator) to see the consents that
s/he has in place? Rather like Credit reporting. I periodically receive
my credit report and check it out to see if there is anything weird on
it. I would also like, periodically, to see the consents that I have in
place and to be able to tweak them (or revoke them).

Scenario:

I have just bought a business and the previous owner has "consented" to
receive some email that I really don't want. He is on every one of the
dating services, and several pornographic sites too. They regularly send
him mail. Trouble is that he used a "functional mailbox"
([email-masked]) to sign up for these things. Even with a nice
consent framework, he can have consented to all of this stuff. Now as
the business owner, I suddenly find that my [email-masked] mailbox
has been inundated with mail that has been legitimately consented to,
but I don't want. I actually have no idea what consents that mailbox
has. I just know that I would really like not to have them extant any
more.

Of course, it is quite possible that the previous owner did this on
purpose, because he was forced to sell the company - it wasn't a going
concern and the other investors wanted their money out.

Every one of the current customers knows that [email-masked] is
the way to get in touch when they want to buy things from us, so the
email address is itself, a thing of value and an asset that was valued
in the asset purchase agreement.

End of scenario

There are plenty of scenarios like this, so I think the ability to find
out the "consents" (even for a fee, like the credit reports) could be
quite valuable. I really don't want to see a "yes you did, no I didn't"
kind of war breaking out between email address holders and marketers if
at all possible.

At least a reasonable consent framework might prevent me from getting
the interminable emails from companies that I have never done business
with, but who have my email address because they were harvested by klez
or one of the other viruses from the mail box of a colleague.

Chris

---

From: "Pete - Madscientist" <[email-masked]>
Date: Mon, 25 Aug 2003 16:49:46 -0400

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Christopher Bird
<snip>
|As part of the work on consent frameworks, is there a proposal 
|somewhere to allow a user or delegated administrator) to see 
|the consents that s/he has in place? Rather like Credit 
|reporting. I periodically receive my credit report and check 
|it out to see if there is anything weird on it. I would also 
|like, periodically, to see the consents that I have in place 
|and to be able to tweak them (or revoke them).

Though it is not stated yet on the site, in the XML-CPDL it is presumed
that a good implementation would be able to produce a comprehensive
XML-CPD from the perspective of any SYSTEM in the network including all
of the inherited policy elements.

This may take a few extra elements to iron out, or at least some
understanding of the securities required in the scope of such a system,
but one can fairly easliy conjecture that in a hierarchcally organized
network or CPDs an administrator could "dump" a comprehensive CPD for
the system, and presumably limit the scope of that document to the
perspecitive of one or more "leaf" SYSTEMs.

ie:

Get policies through

Border MTA,
Domain x MTA/MDA,
User y MUA

With a little bit of tweaking and security work one might expect that
User y would also be able to request the same document.

_M