[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Resource sets and resource string semantics
Regarding the "middle position," I believe that this is what Phill intended the <Advice> element to do (p. 14 of V.07). You can pass anything you want in it, but you can't demand that it be taken into consideration in processing. Eve At 11:25 AM 5/15/01 -0500, George_Robert_Blakley_III@tivoli.com wrote: >All, > >I am generally sympathetic with Darren's position here. I think passing >back policy is a complexity which we do not >absolutely *have* to add to release one of our spec, as we could support >the "dumb PEP" case without it. > >I think it's particularly naive to assume that the PDP has a policy which >can be expressed entirely as a hierarchical >name-based thing.... so wildcards may not fit naturally into the URL >structure depending on what the policy looks like. > >Figuring out the issues surrounding passing policy back will take us time, >but there's a middle position. In aznAPI >we provided essentially an opaque field through which explanatory or policy >information could be returned in >response to an authorization decision request. We require that the caller >know what kind of PDP it's talking to >when it makes this request and hence be able to interpret both the datatype >and the contents of any >information returned in this field, thus punting the issue to implementors. >We could initially take this approach and >then go back and fill in details of what types & values should be passed >for interoperable PDP/PEP combinations >in this field in a future release of the spec. -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Development eve.maler @ east.sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC