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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: [security-services] Request All Attributes- was RE: Issues Statu s


Title: [security-services] Request All Attributes- was RE: Issues Status

> I don't like the fact that if there aren't any attributes in
> the attribute
> query it means "get me all" of them. This ruins the montonicity of the
> function the service is providing. Which means special cases
> have to be
> made when generating requests.
>
> I've run into this problem in implemenations before, when
> automatically
> generating requests for attributes by their types. Some
> systems due to the
> access decision language and other dynamic information the
> attribute types
> are automatically derived, which could be for no attribute
> types. All of a
> sudden, it got a whole host of things it didn't want, which
> complicated
> the process, not to mention slowed it down.
>
> If the Query function is "get me the attributes that match
> these types"
> and there aren't any types supplied, isn't the logical
> consistent thing to
> do is maintain consitency and return no attributes?

Yes, there were other people uncomfortable with the "nothing means all" scheme way back, but it never reached the point of a specific proposal. As I recall the notion of a "*" or "ALL" key word was discussed. Personally I would prefer that.

However, at this late date, my main concern was that the spec does not currently provide ANY WAY AT ALL that is required to be interpreted as asking for all available attributes.

Hal



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


Powered by eList eXpress LLC