From renato at odrl.net Fri Jun 2 14:20:08 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Response to Susanne Guth's mail New ODRLv2 Model Semantics`` In-Reply-To: <20060529214622.168390@gmx.net> References: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> <20060529214622.168390@gmx.net> Message-ID: On 30 May 2006, at 07:46, Susanne Guth wrote: > 3.) Well the rights holder kind of disappeared. In our previous > draft, we had the relationship of the rightsholder. Renato, Alapan > why was that removed again? How do we express, I own my music file? Not sure what happened to it - I suspect it was dropped (from the May 2005 version) by mistake! Please add it back into the model! Cheers Renato Iannella ODRL Initiative http://odrl.net From vickyw at cs.cornell.edu Sun Jun 4 12:56:29 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Discussion of ODRL v2.0 Model (Cont) References: Message-ID: Hi Susanne, I think that your contribution is required for the Model and the Core Profile. However, I think it might make sense to open up new documents for your contribution. What do you think? I don't have a good sense of what each document will include, so it's hard to say. I'll probably have an opinion after I read the descriptions of the docs. I think of a fragment as something incomplete. However, a statement can still be a complete rights expression with parties, permissions, constraints, etc. and then fragment would not really fit. Maybe we find some other term? I wonder if the naming problem is symptomatic of a larger issue. Maybe there should be 2 names/constructs; one for a collection of fragments and another for a (complete) statement. a Request usually provokes an offer Ah ha! The problem is that I misinterpreted the role of requests. I thought a request was formed by an agent who wanted immediate access to an asset (e.g., Alice requests to download the movie), rather than an agent who wanted an offer to be made that would, if accepted, permit access under certain conditions (e.g., Alice requests the movie company to tell her the terms under which she can download the movie). Vicky I don't see that we can not express "consumer is over 18 years of age" or "consumer must have a valid driver's license." We would simply chose the constraint name accordingly. E.g. ( age_consumer >= 18 ) or ( valid_driverslicense == TRUE) If I understand your response correctly, then every statement can be written as a constraint. In particular, for any statement s, we can create a symbol m to represent s (e.g., m could be s written in English with the words separated by underscores rather than spaces), then we can write s as the constraint "m == true". I'm concerned that evaluating the statements might be a bit tricky. For example, to determine whether "age_consumer >= 18", I think we would need some sort of processing algorithm that would take the entire context (consumer is Bob Smith, asset is file f, maybe some other info?) and the constraint as input; munge it to get an appropriate database query such as "what is Bob Smith's age?"; and then replace "age_consumer" with Bob's age. Note that the problem is somewhat more complex if the constraint is written as "age_of_consumer_is_at_least_18 == true". If, instead, the constraint is written as "Age(user) >= 18" then we at least know what the relevant part of the context is; we might also be able to look up the information more easily, but I'm not sure. I also don't see your concerns with the duties. We only have duties now, so that we CAN express your examples. "if the user plays a movie, then she must pay 5 dollars at the end of the month" --> permission= play, asset = a movie, duty = pay, object (of duty) = 5 dollars, constraint (of duty) = by the end of the month. I the duty is not fulfilled then the permission is not granted. Does that make sense? I thought a duty, as written in the current draft, had to be some sort of payment, so you couldn't have a duty be an action such as giving attribution. I'm also a bit confused about the role of constraints. I thought the intuition was as follows: if an agent exercises a permission that is associated with a duty d and the constraints associated with d hold, then d must be performed. Your example seems to suggest the following: if an agent exercises a permission that is associated with a duty d then d must be fulfilled while the constraints hold (e.g., while today's date <= 30/6/2006). So suppose an agreement gives Alice permission to print a file f and, if she prints it more than 100 times, then she has to pay 5 dollars. We'd write this as permission=print, asset = f, duty = pay, object (of duty) = 5 dollars, and constraint (of duty) = number_of_copies_by_consumer <= 100. Yes? Best, Vicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060603/bc8c5ba5/attachment.html From renato at odrl.net Mon Jun 5 12:06:00 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Discussion of ODRL v2.0 Model (Cont) In-Reply-To: References: Message-ID: On 4 Jun 2006, at 12:56, Vicky Weissman wrote: > So suppose an agreement gives Alice permission to print a file f > and, if she prints it more than 100 times, then she has to pay 5 > dollars. We'd write this as permission=print, asset = f, duty = > pay, object (of duty) = 5 dollars, and constraint (of duty) = > number_of_copies_by_consumer <= 100. Yes? We can break this down into two permission statements: ====Permission 1====== Asset = f Permission = print [Constraint <= 100] ====Permission 1====== ====Permission 2====== Asset = f Permission = print [Constraint > 100] Duty = Pay [amount = AUD5] ====Permission 2====== This way the constraint related to printing is associated with the Permission, not the Duty. Is this a clearer ??? Cheers... Renato Iannella -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060605/fa466b1f/attachment.html From vickyw at cs.cornell.edu Tue Jun 6 12:32:48 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 17, Issue 3 References: Message-ID: Hi Renato, I'm sorry but I still don't understand. More precisely, your encoding makes perfect sense, and the question I was trying to answer using the example is still open. Let me try to ask the question again. Suppose an agreement gives Alice permission to download a file f; this policy is associated with the duty "pay 5 dollars"; the Boolean flag is not set (so the duty must be fulfilled before the permission is granted); and this duty is associated with a constraint c. Which of the following should we conclude (or should we conclude something else)? (a) If c holds and Alice pays 5 dollars, then she may download f. (b) If c does not hold, then Alice may download f; if c does hold, then Alice may download f if she pays 5 dollars. Note: (a) suggests that a constraint c associated with a duty is the same as c associated with a permission; (b) suggests that the constraint on the duty says whether the duty must be fulfilled; and, as far as I can tell, neither interpretation can be used to say that Alice may download f (now) if she pays 5 dollars by the end of the month (sometime in the near future). Thanks for the help, Vicky -----Original Message----- From: odrl-version2-bounces@odrl.net on behalf of odrl-version2-request@odrl.net Sent: Mon 6/5/2006 10:00 PM To: odrl-version2@odrl.net Subject: ODRL-Version2 Digest, Vol 17, Issue 3 Send ODRL-Version2 mailing list submissions to odrl-version2@odrl.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.odrl.net/mailman/listinfo/odrl-version2 or, via email, send a message with subject or body 'help' to odrl-version2-request@odrl.net You can reach the person managing the list at odrl-version2-owner@odrl.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ODRL-Version2 digest..." Today's Topics: 1. Re: Discussion of ODRL v2.0 Model (Cont) (Renato Iannella) ---------------------------------------------------------------------- Message: 1 Date: Mon, 5 Jun 2006 12:06:00 +1000 From: Renato Iannella Subject: Re: [Odrl-version2] Discussion of ODRL v2.0 Model (Cont) To: "ODRL Version 2.0" Message-ID: Content-Type: text/plain; charset="us-ascii" On 4 Jun 2006, at 12:56, Vicky Weissman wrote: > So suppose an agreement gives Alice permission to print a file f > and, if she prints it more than 100 times, then she has to pay 5 > dollars. We'd write this as permission=print, asset = f, duty = > pay, object (of duty) = 5 dollars, and constraint (of duty) = > number_of_copies_by_consumer <= 100. Yes? We can break this down into two permission statements: ====Permission 1====== Asset = f Permission = print [Constraint <= 100] ====Permission 1====== ====Permission 2====== Asset = f Permission = print [Constraint > 100] Duty = Pay [amount = AUD5] ====Permission 2====== This way the constraint related to printing is associated with the Permission, not the Duty. Is this a clearer ??? Cheers... Renato Iannella -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060605/fa466b1f/a ttachment-0001.htm ------------------------------ _______________________________________________ ODRL-Version2 mailing list ODRL-Version2@odrl.net http://lists.odrl.net/mailman/listinfo/odrl-version2 End of ODRL-Version2 Digest, Vol 17, Issue 3 ******************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060605/2d16999e/attachment.html From renato at odrl.net Wed Jun 7 15:22:38 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 17, Issue 3 In-Reply-To: References: Message-ID: On 6 Jun 2006, at 12:32, Vicky Weissman wrote: > I'm sorry but I still don't understand. More precisely, your > encoding makes perfect sense, and the question I was trying to > answer using the example is still open. Let me try to ask the > question again. Suppose an agreement gives Alice permission to > download a file f; this policy is associated with the duty "pay 5 > dollars"; the Boolean flag is not set (so the duty must be > fulfilled before the permission is granted); and this duty is > associated with a constraint c. Which of the following should we > conclude (or should we conclude something else)? > > (a) If c holds and Alice pays 5 dollars, then she may download f. > > (b) If c does not hold, then Alice may download f; if c does hold, > then Alice may download f if she pays 5 dollars. > > Note: (a) suggests that a constraint c associated with a duty is > the same as c associated with a permission; (b) suggests that the > constraint on the duty says whether the duty must be fulfilled; > and, as far as I can tell, neither interpretation can be used to > say that Alice may download f (now) if she pays 5 dollars by the > end of the month (sometime in the near future). Ok - lets define these as: Party=Alice Perm=Download Asset=F Duty=Pay[amt=5] Duty.Constraint=Date[before30June06] Given this, Statement (a) above is OK. The first part of Statement (b) is not OK (since the Duty.Constraint is false). The second part of Statement (b) is OK. I think you are asking what is the impact/difference between a Constraint on a Duty and on a Permission (and is there any difference) In the above case, as long as Duty and Duty.Constraint are fulfilled, then you can do Perm (ie download) any time after that. Consider the following similar example: Party=Alice Perm=Download Perm.Constraint=Date[before30June06] Asset=F Duty=Pay[amt=5] In this case, as long as Duty is fulfilled, you can do Perm, BUT you need to do it (download) before 30June06. So, if you paid $5 after that date, you still could not download the Asset (doh!) Cheers Renato Iannella ODRL Initiative http://odrl.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060607/84c8d754/attachment.html From vickyw at cs.cornell.edu Fri Jun 9 00:14:58 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Still not sure about constraints on duties References: Message-ID: Hi Renato, If I understood your response correctly, then the following two statements are equivalent. Party=Alice Perm=Download Asset=F Duty=d Duty.Constraint=c Party=Alice Perm=Download Asset=F Duty=d Constraint=c Is this right? If so, why allow duties to have constraints at all? -------------- Again, if I understood correctly, then Party=Alice Perm=Download Asset=F Duty=Pay[amt=5] Duty.Constraint=Date[before30June06] says that Alice may download F if she has paid 5 and the current date is before June 30, 2006. So the encoding does not match the example I gave; namely, Alice may download F (now) if she pays 5 dollars at the end of the month. Examples of similar policies in real life include credit card policies (you can buy what you want but are obligated; that is, have a duty, to pay a certain percentage of your balance at the end of the month) and traditional library policies (you can check out a book but are obligated to return it within 2 weeks). I could understand if ODRL was not interested in capturing such policies but then having a construct called a "duty" seems odd. --------------- Finally, is it true that duties can only require some party to make a payment, or could a duty require other types of actions such as attribution being given? (Note: if a duty can only discuss a payment, then duties are less expressive than requirements as defined in v1.0, although maybe requirements in v1.0 can be captured by constraints in v2.0.) Thanks, Vicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060608/23c505ad/attachment.html From Susanne.Guth at gmx.net Fri Jun 9 01:38:25 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Still not sure about constraints on duties In-Reply-To: References: Message-ID: <20060608153825.243980@gmx.net> Vicky, just a comment on your last comment. Duties can contain Actions (such as Attribution) or Objects. Therefore, the duties in ODRL Version 2.0 totally cover the v1.0 requirements. Susanne >?-------- Original-Nachricht -------- >?Datum: Thu, 8 Jun 2006 10:14:58 -0400 >?Von: Vicky Weissman >?An: odrl-version2@odrl.net >?Betreff: [Odrl-version2] Still not sure about constraints on duties >? > Hi Renato, > > If I understood your response correctly, then the following two statements > are equivalent.? > > Party=Alice > Perm=Download > Asset=F > Duty=d > Duty.Constraint=c > > Party=Alice > Perm=Download > Asset=F > Duty=d > Constraint=c > > Is this right?? If so, why allow duties to have constraints at all? > > -------------- > > Again, if I understood correctly, then > > Party=Alice > Perm=Download > Asset=F > Duty=Pay[amt=5] > Duty.Constraint=Date[before30June06] > > says that Alice may download F if she has paid 5 and the current date is > before June 30, 2006.? So the encoding does not match the example I gave; > namely, Alice may download F (now) if she pays 5 dollars at the end of the > month.? Examples of similar policies in real life include credit card > policies (you can buy what you want but are obligated; that is, have a > duty, to pay a certain percentage of your balance at the end of the month) > and traditional library policies (you can check out a book but are > obligated to return it within 2 weeks).? > > I could understand if ODRL was not interested in capturing such policies > but then having a construct called a "duty" seems odd.?? > > --------------- > Finally, is it true that duties can only require some party to make a > payment, or could a duty require other types of actions such as > attribution > being given?? (Note: if a duty can only discuss a payment, then duties > are > less expressive than requirements as defined in v1.0, although maybe > requirements in v1.0 can be captured by constraints in v2.0.) > > Thanks, > Vicky -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ "Feel free" ? 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From renato at odrl.net Tue Jun 13 13:45:55 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Still not sure about constraints on duties In-Reply-To: References: Message-ID: <8BDC0150-9E31-47FD-B84E-60249C2A105D@odrl.net> On 9 Jun 2006, at 00:14, Vicky Weissman wrote: > If I understood your response correctly, then the following two > statements are equivalent. > > Party=Alice > Perm=Download > Asset=F > Duty=d > Duty.Constraint=c > > Party=Alice > Perm=Download > Asset=F > Duty=d > Constraint=c > > Is this right? If so, why allow duties to have constraints at all? The Constraint in the second example has to be associated with a Permission, Duty, or Prohibition. (This is the V2.0 Model semantics.) Hence, you can't just have a Constraint by itself - does that clear up things? > > Again, if I understood correctly, then > > Party=Alice > Perm=Download > Asset=F > Duty=Pay[amt=5] > Duty.Constraint=Date[before30June06] > > says that Alice may download F if she has paid 5 and the current > date is before June 30, 2006. So the encoding does not match the > example I gave; namely, Alice may download F (now) if she pays 5 > dollars at the end of the month. Examples of similar policies in > real life include credit card policies (you can buy what you want > but are obligated; that is, have a duty, to pay a certain > percentage of your balance at the end of the month) and traditional > library policies (you can check out a book but are obligated to > return it within 2 weeks). You can do what you want by adding the following to your example: Duty.Relax=True This would fit into the model of "buy now, pay later" - even to the point of not paying by the due date and incurring interest or worse, a library fine ;-0 > > --------------- > Finally, is it true that duties can only require some party to make > a payment, or could a duty require other types of actions such as > attribution being given? (Note: if a duty can only discuss a > payment, then duties are less expressive than requirements as > defined in v1.0, although maybe requirements in v1.0 can be > captured by constraints in v2.0.) Duties can relate to *any* action, not just payments. Cheers... Renato Iannella National ICT Australia (NICTA) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060613/a6fb4f2a/attachment.html From aarnab at cs.uct.ac.za Tue Jun 13 16:51:41 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] comments regarding the last series of emails Message-ID: <1150181501.6995.6.camel@iduna> Hi, Sorry - I have been meaning to reply to the ODRL emails ... so here are my 2c for the last few emails ... (I have tried to keep it in chronological order) Bottom line: I think we should stick with "one owner per asset". Handling more than one owner per asset (as information) is not difficult. However, validtating which owner can assign rights is more difficult. Maybe, in this case we should change the definition of owner as the logical entities that have the right to assign permissions. 5.) I agree, that the negotiation process maybe requires more detail. Alapan, how does the process look like, and how can we indicate negotiable attributes? Did you already state that in one of your documents? I did outline the process in an earlier document, and that has been subsequently refined a few times now ... I am currently refining it, so I can submit for consideration at the ACM-DRM workshop later this year ... I can post it once I am done. In my opinion, any part of the license should be negotiable, and thus all elements should have a "tradable" attribute to indicate that it is not negotiable. Ah ha! The problem is that I misinterpreted the role of requests. I thought a request was formed by an agent who wanted immediate access to an asset (e.g., Alice requests to download the movie), rather than an agent who wanted an offer to be made that would, if accepted, permit access under certain conditions (e.g., Alice requests the movie company to tell her the terms under which she can download the movie). It can work in the first way also. Alice requests to download a movie, and the agent replies - yes, but with the attached set of conditions ... I think we would need some sort of processing algorithm that would take the entire context (consumer is Bob Smith, asset is file f, maybe some other info?) and the constraint as input; munge it to get an appropriate database query such as "what is Bob Smith's age?"; and then replace "age_consumer" with Bob's age. Note that the problem is somewhat more complex if the constraint is written as "age_of_consumer_is_at_least_18 == true". If, instead, the constraint is written as "Age(user) >= 18" then we at least know what the relevant part of the context is; we might also be able to look up the information more easily, but I'm not sure. The choice of vocabulary is particularly important, and that could a whole series of discussion on its own I think! Alapan -- Alapan Arnab Data Networks Architecture (DNA) Laboratory Department of Computer Science University of Cape Town Rondebosch, 7700 South Africa Tel: +27 21 650 3127 Web: http://people.cs.uct.ac.za/~aarnab/ Blog: http://idiots-mind.blogspot.com ---------- "You must always believe that you can be the best, but you must never believe you have achieved it". Juan Manuel Fangio From vickyw at cs.cornell.edu Thu Jun 15 00:11:57 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 17, Issue 7 In-Reply-To: Message-ID: Hi, I'm sorry to keep pressing, maybe I'm just being dense, but I'm still confused. Are the following 2 agreements the same? If not, what is the difference (in English)? Can you give me an example where one agreement implies that Alice may download F, and the other does not? If the agreements are the same, then why complicate the model by allowing constraints to be assigned to duties? (Note: the first agreement has the constraint c associated with the duty d, the second has the same constraint c associated with the permission download.) Party=Alice Perm=Download Asset=F Duty=d Duty.Constraint=c Party=Alice Perm=Download Asset=F Duty=d Perm.Constraint=c ------------------- If we set the Boolean Duty.Relax=True, then that means the user is obligated to fulfill the duty sometime (anytime!) in the future. So we can't use duties to obligate a user to do something at a certain time after the right has been exercised (e.g., unlocking a resource within 48 hours of acquiring the lock). Yes? ------------------ -Vicky From vickyw at cs.cornell.edu Thu Jun 15 22:12:09 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 17, Issue 8 In-Reply-To: Message-ID: -----Original Message----- From: odrl-version2-bounces@odrl.net [mailto:odrl-version2-bounces@odrl.net] On Behalf Of odrl-version2-request@odrl.net Sent: Wednesday, June 14, 2006 10:00 PM To: odrl-version2@odrl.net Subject: ODRL-Version2 Digest, Vol 17, Issue 8 Send ODRL-Version2 mailing list submissions to odrl-version2@odrl.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.odrl.net/mailman/listinfo/odrl-version2 or, via email, send a message with subject or body 'help' to odrl-version2-request@odrl.net You can reach the person managing the list at odrl-version2-owner@odrl.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ODRL-Version2 digest..." Today's Topics: 1. RE: ODRL-Version2 Digest, Vol 17, Issue 7 (Vicky Weissman) ---------------------------------------------------------------------- Message: 1 Date: Wed, 14 Jun 2006 10:11:57 -0400 From: "Vicky Weissman" Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 17, Issue 7 To: Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi, I'm sorry to keep pressing, maybe I'm just being dense, but I'm still confused. Are the following 2 agreements the same? If not, what is the difference (in English)? Can you give me an example where one agreement implies that Alice may download F, and the other does not? If the agreements are the same, then why complicate the model by allowing constraints to be assigned to duties? (Note: the first agreement has the constraint c associated with the duty d, the second has the same constraint c associated with the permission download.) Party=Alice Perm=Download Asset=F Duty=d Duty.Constraint=c Party=Alice Perm=Download Asset=F Duty=d Perm.Constraint=c ------------------- If we set the Boolean Duty.Relax=True, then that means the user is obligated to fulfill the duty sometime (anytime!) in the future. So we can't use duties to obligate a user to do something at a certain time after the right has been exercised (e.g., unlocking a resource within 48 hours of acquiring the lock). Yes? ------------------ -Vicky ------------------------------ _______________________________________________ ODRL-Version2 mailing list ODRL-Version2@odrl.net http://lists.odrl.net/mailman/listinfo/odrl-version2 End of ODRL-Version2 Digest, Vol 17, Issue 8 ******************************************** From renato at odrl.net Fri Jun 16 12:29:53 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 17, Issue 7 In-Reply-To: References: Message-ID: On 15 Jun 2006, at 00:11, Vicky Weissman wrote: > Are the following 2 agreements the same? If not, what is the > difference (in English)? They are not the same. The "c" Constraint applies to different parts of the expression. In the first case, the "c" Constraint applies to the Duty, and the second case, the "c" Constraint applies to the Permission. So, assuming "c" is "before 2006-06-30" and "d" is "pay $EU5", then the first agreement says that: "Alice can Download Asset F if she pays $EU5 before 2006-06-30" The second agreement would then say that: "Alice can Download Asset F before 2006-06-30 if she pays $EU5" So, in the first agreement, Alice cannot do anything unless she pays $EU5 before 2006-06-30. If she does pay $EU5 before 2006-06-30, then she can Download Asset F (at any time now or in the future). So, in the second agreement, Alice cannot do anything unless she pays $EU5. If she does pay $EU5, then she can Download Asset F before 2006-06-30. If it is after that date, then she cannot download it, even if she has paid. Is that a bit clearer? > ------------------- > If we set the Boolean Duty.Relax=True, then that means the user is > obligated > to fulfill the duty sometime (anytime!) in the future. So we can't > use > duties to obligate a user to do something at a certain time after > the right > has been exercised (e.g., unlocking a resource within 48 hours of > acquiring > the lock). Yes? > ------------------ Correct, "relax" really means "relaxed" ;-) Perhaps we need a constraint on that as well ? Cheers Renato Iannella ODRL Initiative http://odrl.net From vickyw at cs.cornell.edu Wed Jun 21 04:28:43 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Constraints on duties - I think I've got it now... In-Reply-To: Message-ID: Hi, If I understood your last mail correctly, the agreement Party=Alice Perm=Download Asset=F Duty=d Duty.Constraint=c Duty.Relax = false means that Alice may download F if she has (1) fulfilled duty d at time t and (2) at time t, constraint c holds. So, if d = "pay 5 Euros" and c is "time is before June 30, 2006", then Alice may download F if she has already paid 5 euros and that payment was made before June 30, 2006. Assuming this correct, lets see how the definition plays out in a few other examples. Party=Alice Perm= lock Asset= f.src Duty= unLock Duty.Constraint= within 24 hours Duty.Relax = true This means that Alice is allowed to lock the source file f.src, and she can keep the lock for as long as she wants. However the agreement writer/owner asks that she release the lock within 24 hours of taking it (i.e., she ought to - but is not legally required to - unlock within 24 hrs.) Note: I'm assuming Duties do not have to be payments (as clarified by Susanne) and the application-specific vocabulary includes the constant "time_Alice_Last_Locked_f.src", so we can have a constraint "before time_Alice_Last_Locked_f.src + 24 hrs". I wonder if duties should have (optional) consequences. For example, maybe the agreement owner would like to say "Alice may lock f.src; she should return the lock within 24 hours, and, if she doesn't return the lock, then she'll be charged one Euro a day". More generally, relaxed duties allow obligations to hold after the right has been granted/exercised, so I think it'd make sense (and is often the case in practice) for there to be consequences to unmet obligations. What do you think? ----- Party=Alice, Bob Perm= download Asset= F Duty= pays 1 euro Duty.Constraint= user is over 21 Duty.Relax = false This means (1) if Alice is over 21, then she may pay 1 euro and, if she pays the euro, then she may download F. The same is true for Bob. So the agreement is equivalent to one that says "Alice/Bob may download F if she/he is over 21 and pays a euro". That is, the agreement is equivalent to Party=Alice, Bob Perm= download Asset= F Duty= pays 1 euro Perm.Constraint= user is over 21 Duty.Relax = false ---- (This one's really about parties v. individuals.) Party=Alice Perm= download Asset= F Duty= pays 1 euro Duty.Assignee = {Alice, Bob} Duty.Beneficiary = {Charlie, Dan} Duty.Relax = false The agreement says that Alice may download F if {Alice, Bob} has paid 1 euro to {Charlie, Dan}. Suppose Bob gives a euro to Charlie. Then does it necessarily follow that {Alice, Bob} has given a euro to {Charlie, Dan} and, thus, Alice may download F? Thank you so much for your patience. Best, Vicky From aarnab at cs.uct.ac.za Wed Jun 21 20:17:56 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Constraints on duties - I think I've got it now... In-Reply-To: References: Message-ID: <1150885077.7015.5.camel@iduna> Hi, > I wonder if duties should have (optional) consequences. For example, maybe > the agreement owner would like to say "Alice may lock f.src; she should > return the lock within 24 hours, and, if she doesn't return the lock, then > she'll be charged one Euro a day". More generally, relaxed duties allow > obligations to hold after the right has been granted/exercised, so I think > it'd make sense (and is often the case in practice) for there to be > consequences to unmet obligations. What do you think? > I think this is a great idea, and should be a part of duties. > ----- > > Party=Alice, Bob > Perm= download > Asset= F > Duty= pays 1 euro > Duty.Constraint= user is over 21 > Duty.Relax = false > > This means (1) if Alice is over 21, then she may pay 1 euro and, if she pays > the euro, then she may download F. The same is true for Bob. So the > agreement is equivalent to one that says "Alice/Bob may download F if she/he > is over 21 and pays a euro". That is, the agreement is equivalent to > > Party=Alice, Bob > Perm= download > Asset= F > Duty= pays 1 euro > Perm.Constraint= user is over 21 > Duty.Relax = false > Not sure what is the difference between the two. > ---- > (This one's really about parties v. individuals.) > > Party=Alice > Perm= download > Asset= F > Duty= pays 1 euro > Duty.Assignee = {Alice, Bob} > Duty.Beneficiary = {Charlie, Dan} > Duty.Relax = false > > The agreement says that Alice may download F if {Alice, Bob} has paid 1 euro > to {Charlie, Dan}. Suppose Bob gives a euro to Charlie. Then does it > necessarily follow that {Alice, Bob} has given a euro to {Charlie, Dan} and, > thus, Alice may download F? > Yes, as long as Bob was paying 1 Euro for the purpose of Alice downloading (and not for something else). Alapan -- Alapan Arnab Data Networks Architecture (DNA) Laboratory Department of Computer Science University of Cape Town Rondebosch, 7700 South Africa Tel: +27 21 650 3127 Web: http://people.cs.uct.ac.za/~aarnab/ Blog: http://idiots-mind.blogspot.com ---------- "You must always believe that you can be the best, but you must never believe you have achieved it". Juan Manuel Fangio From renato at odrl.net Fri Jun 23 21:51:13 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Constraints on duties - I think I've got it now... In-Reply-To: References: Message-ID: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> On 21 Jun 2006, at 04:28, Vicky Weissman wrote: > Party=Alice > Perm=Download > Asset=F > Duty=d > Duty.Constraint=c > Duty.Relax = false > > means that Alice may download F if she has (1) fulfilled duty d at > time t and > (2) at time t, constraint c holds. So, if d = "pay 5 Euros" and c > is "time > is before June 30, 2006", then Alice may download F if she has > already paid 5 > euros and that payment was made before June 30, 2006. > > Assuming this correct, Yes... > I wonder if duties should have (optional) consequences. For > example, maybe > the agreement owner would like to say "Alice may lock f.src; she > should > return the lock within 24 hours, and, if she doesn't return the > lock, then > she'll be charged one Euro a day". More generally, relaxed duties > allow > obligations to hold after the right has been granted/exercised, so > I think > it'd make sense (and is often the case in practice) for there to be > consequences to unmet obligations. What do you think? I like this idea. We should introduce the "unmet" entity for Duties (that can take any Action) So your example might now look like: Party=Alice Perm= lock Asset= f.src Duty= unLock Duty.Constraint= within 24 hours Duty.Unmet = EU1/day When can then use the null case, that is "Duty.Unmet=null" to be the same as Duty.Relax=true. Ie you can not meet the duty, but nothing will happen > Party=Alice, Bob > Perm= download > Asset= F > Duty= pays 1 euro > Duty.Constraint= user is over 21 > Duty.Relax = false > > This means (1) if Alice is over 21, then she may pay 1 euro and, if > she pays > the euro, then she may download F. The same is true for Bob. So the > agreement is equivalent to one that says "Alice/Bob may download F > if she/he > is over 21 and pays a euro". That is, the agreement is equivalent to > > Party=Alice, Bob > Perm= download > Asset= F > Duty= pays 1 euro > Perm.Constraint= user is over 21 > Duty.Relax = false Your first example means that the person paying needs to be over 21, whereas the second example means you need to be over 21 to download the file (both are valid examples) Now, we need to be clear on the multiple parties you have listed. We have the concept of "assignee" and "assignees" in our model. The former is for a single party, and the latter for multiple parties (although you identify that latter group with a single identifier) and each of the members of that group receives the same set of Permissions and Prohibitions. (We should extend that to Duties as it is not in the model yet). So if we use Party.assignees=alice-n-bob-group-id, then each member of that group would get the permission and be liable for the Duty, unless we use Duty.assignee=alice-n-bob- group-id. > ---- > (This one's really about parties v. individuals.) > > Party=Alice > Perm= download > Asset= F > Duty= pays 1 euro > Duty.Assignee = {Alice, Bob} > Duty.Beneficiary = {Charlie, Dan} > Duty.Relax = false > > The agreement says that Alice may download F if {Alice, Bob} has > paid 1 euro > to {Charlie, Dan}. Suppose Bob gives a euro to Charlie. Then does it > necessarily follow that {Alice, Bob} has given a euro to {Charlie, > Dan} and, > thus, Alice may download F? Since you used "assignee" then yes. Does that make sense? Cheers... Renato Iannella National ICT Australia (NICTA) Cheers Renato Iannella ODRL Initiative http://odrl.net From Susanne.Guth at gmx.net Fri Jun 23 22:36:18 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Constraints on duties - I think I've got it now... In-Reply-To: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> References: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> Message-ID: <20060623123618.325120@gmx.net> Hi Vicky, Renato, I like the idea of the "unmet", too. I will try to find a good spot in the model to link not fullfilled duties to new/or (two) choices of duties. This will also enable us to express Service Level Agreement. For example, if the mobile network operator meets his duty to always supply full coverage, then the customer pays the full price - otherwise he pays only a lower price... Thanks and so long Susanne -------- Original-Nachricht -------- Datum: Fri, 23 Jun 2006 21:51:13 +1000 Von: Renato Iannella An: "ODRL Version 2.0" Betreff: Re: [Odrl-version2] Constraints on duties - I think I\'ve got it now... > > On 21 Jun 2006, at 04:28, Vicky Weissman wrote: > > > Party=Alice > > Perm=Download > > Asset=F > > Duty=d > > Duty.Constraint=c > > Duty.Relax = false > > > > means that Alice may download F if she has (1) fulfilled duty d at > > time t and > > (2) at time t, constraint c holds. So, if d = "pay 5 Euros" and c > > is "time > > is before June 30, 2006", then Alice may download F if she has > > already paid 5 > > euros and that payment was made before June 30, 2006. > > > > Assuming this correct, > > Yes... > > > I wonder if duties should have (optional) consequences. For > > example, maybe > > the agreement owner would like to say "Alice may lock f.src; she > > should > > return the lock within 24 hours, and, if she doesn't return the > > lock, then > > she'll be charged one Euro a day". More generally, relaxed duties > > allow > > obligations to hold after the right has been granted/exercised, so > > I think > > it'd make sense (and is often the case in practice) for there to be > > consequences to unmet obligations. What do you think? > > I like this idea. We should introduce the "unmet" entity for Duties > (that can take any Action) > > So your example might now look like: > > Party=Alice > Perm= lock > Asset= f.src > Duty= unLock > Duty.Constraint= within 24 hours > Duty.Unmet = EU1/day > > When can then use the null case, that is "Duty.Unmet=null" to be the > same as Duty.Relax=true. > Ie you can not meet the duty, but nothing will happen > > > Party=Alice, Bob > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Duty.Constraint= user is over 21 > > Duty.Relax = false > > > > This means (1) if Alice is over 21, then she may pay 1 euro and, if > > she pays > > the euro, then she may download F. The same is true for Bob. So the > > agreement is equivalent to one that says "Alice/Bob may download F > > if she/he > > is over 21 and pays a euro". That is, the agreement is equivalent to > > > > Party=Alice, Bob > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Perm.Constraint= user is over 21 > > Duty.Relax = false > > Your first example means that the person paying needs to be over 21, > whereas the second example > means you need to be over 21 to download the file (both are valid > examples) > > Now, we need to be clear on the multiple parties you have listed. We > have the concept of "assignee" > and "assignees" in our model. The former is for a single party, and > the latter for multiple parties > (although you identify that latter group with a single identifier) > and each of the members of that group > receives the same set of Permissions and Prohibitions. (We should > extend that to Duties as it is not in the > model yet). > > So if we use Party.assignees=alice-n-bob-group-id, then each member > of that group would get the permission > and be liable for the Duty, unless we use Duty.assignee=alice-n-bob- > group-id. > > > > ---- > > (This one's really about parties v. individuals.) > > > > Party=Alice > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Duty.Assignee = {Alice, Bob} > > Duty.Beneficiary = {Charlie, Dan} > > Duty.Relax = false > > > > The agreement says that Alice may download F if {Alice, Bob} has > > paid 1 euro > > to {Charlie, Dan}. Suppose Bob gives a euro to Charlie. Then does it > > necessarily follow that {Alice, Bob} has given a euro to {Charlie, > > Dan} and, > > thus, Alice may download F? > > Since you used "assignee" then yes. > > Does that make sense? > > > Cheers... Renato Iannella > National ICT Australia (NICTA) > > > > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ "Feel free" ? 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From Susanne.Guth at gmx.net Mon Jun 26 20:05:12 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Constraints on duties - I think I've got it now... In-Reply-To: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> References: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> Message-ID: <20060626100512.167160@gmx.net> Hi Renato, just a comment. We do have Assigner and Assignee in the Model relating the Party and the Duty element. Did you mean somewhere else? So long Susanne -------- Original-Nachricht -------- Datum: Fri, 23 Jun 2006 21:51:13 +1000 Von: Renato Iannella An: "ODRL Version 2.0" Betreff: Re: [Odrl-version2] Constraints on duties - I think I\'ve got it now... > > On 21 Jun 2006, at 04:28, Vicky Weissman wrote: > > > Party=Alice > > Perm=Download > > Asset=F > > Duty=d > > Duty.Constraint=c > > Duty.Relax = false > > > > means that Alice may download F if she has (1) fulfilled duty d at > > time t and > > (2) at time t, constraint c holds. So, if d = "pay 5 Euros" and c > > is "time > > is before June 30, 2006", then Alice may download F if she has > > already paid 5 > > euros and that payment was made before June 30, 2006. > > > > Assuming this correct, > > Yes... > > > I wonder if duties should have (optional) consequences. For > > example, maybe > > the agreement owner would like to say "Alice may lock f.src; she > > should > > return the lock within 24 hours, and, if she doesn't return the > > lock, then > > she'll be charged one Euro a day". More generally, relaxed duties > > allow > > obligations to hold after the right has been granted/exercised, so > > I think > > it'd make sense (and is often the case in practice) for there to be > > consequences to unmet obligations. What do you think? > > I like this idea. We should introduce the "unmet" entity for Duties > (that can take any Action) > > So your example might now look like: > > Party=Alice > Perm= lock > Asset= f.src > Duty= unLock > Duty.Constraint= within 24 hours > Duty.Unmet = EU1/day > > When can then use the null case, that is "Duty.Unmet=null" to be the > same as Duty.Relax=true. > Ie you can not meet the duty, but nothing will happen > > > Party=Alice, Bob > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Duty.Constraint= user is over 21 > > Duty.Relax = false > > > > This means (1) if Alice is over 21, then she may pay 1 euro and, if > > she pays > > the euro, then she may download F. The same is true for Bob. So the > > agreement is equivalent to one that says "Alice/Bob may download F > > if she/he > > is over 21 and pays a euro". That is, the agreement is equivalent to > > > > Party=Alice, Bob > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Perm.Constraint= user is over 21 > > Duty.Relax = false > > Your first example means that the person paying needs to be over 21, > whereas the second example > means you need to be over 21 to download the file (both are valid > examples) > > Now, we need to be clear on the multiple parties you have listed. We > have the concept of "assignee" > and "assignees" in our model. The former is for a single party, and > the latter for multiple parties > (although you identify that latter group with a single identifier) > and each of the members of that group > receives the same set of Permissions and Prohibitions. (We should > extend that to Duties as it is not in the > model yet). > > So if we use Party.assignees=alice-n-bob-group-id, then each member > of that group would get the permission > and be liable for the Duty, unless we use Duty.assignee=alice-n-bob- > group-id. > > > > ---- > > (This one's really about parties v. individuals.) > > > > Party=Alice > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Duty.Assignee = {Alice, Bob} > > Duty.Beneficiary = {Charlie, Dan} > > Duty.Relax = false > > > > The agreement says that Alice may download F if {Alice, Bob} has > > paid 1 euro > > to {Charlie, Dan}. Suppose Bob gives a euro to Charlie. Then does it > > necessarily follow that {Alice, Bob} has given a euro to {Charlie, > > Dan} and, > > thus, Alice may download F? > > Since you used "assignee" then yes. > > Does that make sense? > > > Cheers... Renato Iannella > National ICT Australia (NICTA) > > > > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From Susanne.Guth at gmx.net Mon Jun 26 20:36:56 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] New role Assignees for Duties In-Reply-To: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> References: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> Message-ID: <20060626103656.115710@gmx.net> Dear *, after looking at your point in more detail, I see what you mean. The "assignees" role is missing. Please also note that I added an important semantic bit to the descriptions: - "A Party entity can receive Permissions and Prohibitions by being the Assignee (consumer) of such. Note, the Assignee can also represent a group of people and/or legal entities, but only one member of the group receives the set of Permissions." - "A Party entity can receive Permissions and Prohibitions by being the Assignees (consumers) of such. In this case, the Party entity must identify a group of people and/or legal entities. Each member of the group receives the same set of Permissionss and Prohibitionss [ODRL-REQ#1.13]." With this we can express both cases (and now it is semantically clear): Only one of the group gets the permission AND every member of the group get the permission. The same descriptive text was added to Duties. And Duty now has three relations: Assigner, Assingee, Assignees. So long Susanne -------- Original-Nachricht -------- Datum: Fri, 23 Jun 2006 21:51:13 +1000 Von: Renato Iannella An: "ODRL Version 2.0" Betreff: Re: [Odrl-version2] Constraints on duties - I think I\'ve got it now... > > On 21 Jun 2006, at 04:28, Vicky Weissman wrote: > > > Party=Alice > > Perm=Download > > Asset=F > > Duty=d > > Duty.Constraint=c > > Duty.Relax = false > > > > means that Alice may download F if she has (1) fulfilled duty d at > > time t and > > (2) at time t, constraint c holds. So, if d = "pay 5 Euros" and c > > is "time > > is before June 30, 2006", then Alice may download F if she has > > already paid 5 > > euros and that payment was made before June 30, 2006. > > > > Assuming this correct, > > Yes... > > > I wonder if duties should have (optional) consequences. For > > example, maybe > > the agreement owner would like to say "Alice may lock f.src; she > > should > > return the lock within 24 hours, and, if she doesn't return the > > lock, then > > she'll be charged one Euro a day". More generally, relaxed duties > > allow > > obligations to hold after the right has been granted/exercised, so > > I think > > it'd make sense (and is often the case in practice) for there to be > > consequences to unmet obligations. What do you think? > > I like this idea. We should introduce the "unmet" entity for Duties > (that can take any Action) > > So your example might now look like: > > Party=Alice > Perm= lock > Asset= f.src > Duty= unLock > Duty.Constraint= within 24 hours > Duty.Unmet = EU1/day > > When can then use the null case, that is "Duty.Unmet=null" to be the > same as Duty.Relax=true. > Ie you can not meet the duty, but nothing will happen > > > Party=Alice, Bob > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Duty.Constraint= user is over 21 > > Duty.Relax = false > > > > This means (1) if Alice is over 21, then she may pay 1 euro and, if > > she pays > > the euro, then she may download F. The same is true for Bob. So the > > agreement is equivalent to one that says "Alice/Bob may download F > > if she/he > > is over 21 and pays a euro". That is, the agreement is equivalent to > > > > Party=Alice, Bob > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Perm.Constraint= user is over 21 > > Duty.Relax = false > > Your first example means that the person paying needs to be over 21, > whereas the second example > means you need to be over 21 to download the file (both are valid > examples) > > Now, we need to be clear on the multiple parties you have listed. We > have the concept of "assignee" > and "assignees" in our model. The former is for a single party, and > the latter for multiple parties > (although you identify that latter group with a single identifier) > and each of the members of that group > receives the same set of Permissions and Prohibitions. (We should > extend that to Duties as it is not in the > model yet). > > So if we use Party.assignees=alice-n-bob-group-id, then each member > of that group would get the permission > and be liable for the Duty, unless we use Duty.assignee=alice-n-bob- > group-id. > > > > ---- > > (This one's really about parties v. individuals.) > > > > Party=Alice > > Perm= download > > Asset= F > > Duty= pays 1 euro > > Duty.Assignee = {Alice, Bob} > > Duty.Beneficiary = {Charlie, Dan} > > Duty.Relax = false > > > > The agreement says that Alice may download F if {Alice, Bob} has > > paid 1 euro > > to {Charlie, Dan}. Suppose Bob gives a euro to Charlie. Then does it > > necessarily follow that {Alice, Bob} has given a euro to {Charlie, > > Dan} and, > > thus, Alice may download F? > > Since you used "assignee" then yes. > > Does that make sense? > > > Cheers... Renato Iannella > National ICT Australia (NICTA) > > > > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ Echte DSL-Flatrate dauerhaft f?r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl From Susanne.Guth at gmx.net Mon Jun 26 22:56:35 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Updated Model Semantics In-Reply-To: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> References: <02F51800-8D85-4F84-9F3D-74A5C4CFB364@odrl.net> Message-ID: <20060626125635.167150@gmx.net> Dear all, I did update the model. Please find the new version here. I did not put it up as an official new draft, as I did not go through all your comments yet. For the changes made, please refer to the "Changes" Section. Thanks Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ Echte DSL-Flatrate dauerhaft f?r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl