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] x500


> the first problem I have is with the wording terminal sequence.  
> Terminal sequence of an X.500 DN, from an X.500 perspective, is the  
> leaf end of the DIT. In X.500 DNs are written as strings in little- 
> endien order, ie. they typically start with C= and typically end  
> with CN=. LDAP then reversed this in its string format of RDNs, to  
> be conformant with DNS big-endian name forms. So if you make the  
> statement "terminal sequence of RDNs" it is ambiguous, do you mean  
> the X.500 terminal sequence or the LDAP terminal sequence? I would  
> therefore propose that the text is reworded to specify the semantics  
> of what is intended rather than relying on the syntax of the  
> particular strings. Semantically what is intended is that the two  
> specified DIT subtrees match. So my rewording would be
>
> "it SHALL return “True” if and only if the subtree specified by the  
> first argument matches the root of the subtree specified by the  
> second argument, when compared using x500Name-equal."

good point. this makes sense.

> The second problem I have is, what if the first subtree is smaller  
> than the second subtree? Do they still match? In all of Bill's  
> examples, the first subtree was larger than the second subtree. So  
> what is the result of the reverse case e.g.
>
> first argument: dn=alice,ou=xacml, o=oasis
> second argument: o=oasis
>
> is this a match or not? If it does match, then the above text is  
> sufficient. If it does not, the above text will need supplementing  
> with "The first subtree must be larger than or equal to the second  
> subtree".

personally, i think that allowing the second subtree to be larger  
doesn't make sense. my understanding of the intended functionality is  
to provide a way to define a base context that would match a set of  
subcontainers/nodes. allowing for a match in the case above would  
effectively create a match that exceeds the scope of the first  
expression. this seems Bad to me.

b


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