[Odrl-version2] Requirement Analysis

[Alapan Arnab]

> Alapan - thanks for the analysis - great work and raise some 
> interesting options.
> 
> I was wondering if it maybe more useful to define a "rights protocol" 
> which outlines the
> request/response/deny/accept/etc actions that one would like to do in a 
> transactions.
> 

Assuming a super-distribution environment, the flow of messages should
look something like:

C :             Consumer
R :             Rights Holder
RightsX:     A set of rights X

//The controller requests rights for some protected digital object. At
this moment, the consumer would not know of any options available
C->R:        Request(Object_ID)

//The rights holder responds with a set of offers for various license
types. In ODRL 1.1 this would be simple as there was only one license
type. However, for the proposed model, there could be offers for
Statements, Agreements or Tickets. 
R -> C : Offer(Agreement{Rights_A}, Statement{Rights_X},
Ticket{Rights_Y}, Agreement{Rights_Z})

>From here on, a negotiation can take place as described in my earlier
attachment, i.e.

C -> R : Offer(Agreement{Rights_A}, Reject),
Request(Statement{Rights_B})
R -> C : Request(Statement{Rights_B}, Reject), Offer(Ticket{Rights_C})
C -> R : Offer(Ticket{Rights_C}, Accept)
R -> C : Rights{Ticket(Rights_C)}



> Then these can become the "headers" and ODRL the "body" of a SOAP 
> message?
> 

Yes, the alternative is to instead of putting any negotiation in ODRL
license, do negotiation in header. In that case, the ''offer'' construct
would not belong in ODRL also. But my main issue with such a move is
that it could create problems with interoperability as different
implementers will start using different language in the headers for
request, accept, deny etc. Also, while the preferred implementation for
would be SOAP, there is no restrictions on using other mechanisms such
as RPC. If a system wants to support multiple communication protocols,
it will also have to deal with multiple headers etc. If everything is in
the language itself, communication layer will only deal with the
communication and not what the communication is intended for.

Anyway, as I stated earlier, there are basically two approaches; and we
need to agree on one.

Cheers,
Alapan

________________________________________________________________________



Alapan Arnab
Data Networks Architecture (DNA) Group
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/
----------
"You must always believe that you can be the best, but you must never
believe you have achieved it".
Juan Manuel Fangio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20050804/fbe6cbcf/attachment.html