RE: [Asrg] 4d. Consent Framework - Protocols and Formats - XML Based
Andrew Akehurst <A.D.Akehurst-99@student.lboro.ac.uk> Wed, 20 August 2003 19:40 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04668 for <asrg-archive@odin.ietf.org>; Wed, 20 Aug 2003 15:40:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYo4-0000M2-FI for asrg-archive@odin.ietf.org; Wed, 20 Aug 2003 15:39:47 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KJdi8C001356 for asrg-archive@odin.ietf.org; Wed, 20 Aug 2003 15:39:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYo4-0000Ln-BL for asrg-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 15:39:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04490; Wed, 20 Aug 2003 15:39:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pYo2-0006RW-00; Wed, 20 Aug 2003 15:39:42 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pYo2-0006RS-00; Wed, 20 Aug 2003 15:39:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYnN-0000Bl-0F; Wed, 20 Aug 2003 15:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYmX-00007H-Ry for asrg@optimus.ietf.org; Wed, 20 Aug 2003 15:38:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04072 for <asrg@ietf.org>; Wed, 20 Aug 2003 15:38:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pYmW-0006MZ-00 for asrg@ietf.org; Wed, 20 Aug 2003 15:38:08 -0400
Received: from bill.lut.ac.uk ([158.125.1.193]) by ietf-mx with esmtp (Exim 4.12) id 19pYmV-0006MV-00 for asrg@ietf.org; Wed, 20 Aug 2003 15:38:07 -0400
Received: from [158.125.1.117] (helo=studentpop1.lboro.ac.uk ident=root) by bill.lut.ac.uk with esmtp (Exim 4.14) id 19pYmT-0004GZ-BV; Wed, 20 Aug 2003 20:38:05 +0100
Received: from [158.125.1.122] (helo=bod.lut.ac.uk) by studentpop1.lboro.ac.uk with esmtp (Exim 3.13 #1) id 19pYmT-0001pW-00; Wed, 20 Aug 2003 20:38:05 +0100
Received: from apache by bod.lut.ac.uk with local (Exim 4.12) id 19pYmT-0006Fn-00; Wed, 20 Aug 2003 20:38:05 +0100
To: research@solidmatrix.com, madscientist@microneil.com
Subject: RE: [Asrg] 4d. Consent Framework - Protocols and Formats - XML Based
Message-ID: <1061408285.3f43ce1d4269a@student-webmail.lboro.ac.uk>
From: Andrew Akehurst <A.D.Akehurst-99@student.lboro.ac.uk>
Cc: asrg@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Originating-IP: 172.186.139.198
X-Spam-Score: -0.1 (/)
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19pYmT-0004GZ-BV*2eH5OZdNlxU*
X-Lboro-Filtered: bill.lut.ac.uk, Wed, 20 Aug 2003 20:38:05 +0100
Content-Transfer-Encoding: 8bit
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/asrg/>
Date: Wed, 20 Aug 2003 20:38:05 +0100
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Quoting Yakov Shafranovich <research@solidmatrix.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@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- [Asrg] 4d. Consent Framework - Protocols and Form… Pete (Madscientist)
- Re: [Asrg] 4d. Consent Framework - Protocols and … Yakov Shafranovich
- RE: [Asrg] 4d. Consent Framework - Protocols and … Pete (Madscientist)
- [Asrg] 4d. Consent Framework - Protocols and Form… Pete McNeil
- Re: [Asrg] 4d. Consent Framework - Protocols and … Yakov Shafranovich
- RE: [Asrg] 4d. Consent Framework - Protocols and … Pete (Madscientist)
- RE: [Asrg] 4d. Consent Framework - Protocols and … Yakov Shafranovich
- RE: [Asrg] 4d. Consent Framework - Protocols and … Andrew Akehurst
- RE: [Asrg] 4d. Consent Framework - Protocols and … Pete (Madscientist)
- RE: [Asrg] 4d. Consent Framework - Protocols and … Yakov Shafranovich
- RE: [Asrg] 4. Consent Framework - General Christopher Bird
- RE: [Asrg] 4. Consent Framework - General Pete - Madscientist