OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Issue#39:number of policies to return is too large


On Wed, 6 Sep 2006, Anne Anderson - Sun Microsystems wrote:

> If the client can't handle all the policies that may be returned, that seems 
> like a client problem.  If the client actually needs all policies that match 
> the client's request, then the client simply isn't able to deal with its own 
> request; the PAP's response was a correct one for the query that was 
> submitted.

Well, I guess that *IS* a client problem! Is the client aware by some 
standard how much stuff is going to be returned apriori? I guess it will 
just crash. I realize it's different problem, but with similar 
circumstances, fair enough. You don't need to address it at the present 
time.

>> How are you going to maintain state between the consecutive requests?
>> "Implementation dependent"? Is that fair? Then why have a standard?
>
> The state would be contained in an implementation-dependent way in the 
> XACMLPolicyContinuation element.  The contents need not be standard because 
> they will always be used with the same PAP that issued them.
> [snip]
> I think what I am doing is similar.  The XACMLPolicyContinuation element lets 
> the client maintain the state, just as an iterator does.  The PAP can still 
> be stateless.

Whether it is perceived to be stateful (cookie?) or stateless (including 
same search critera and some progress pointer?) in implementation is 
immaterial to its stateful or stateless use to the client. You still have 
protocol questions: If you say that it is just "implementation dependent", 
then there are still operable "implementation" questions that should be 
answered for dealing with that PAP. For instance, but not limited to:

1. How long is the continuation good for?
2. Must the client's next request be the continuation in a consecutive
    order?
3. If so,  when can the client abandon the continuation and get on with
    the next?
    etc.

I'm just saying that you can write a whole document on this new protocol 
generated by one element, it should just be thorough.

Cheers,
-Polar


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]