[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: RFC 2596 questions



> > I don't want to believe part of Section 3.3. It says that given the
> > filter (name;lang-en-US"=Billy Ray), that the following is a match:
> > CN;lang-EN-US;dynamic: Billy Ray To me, this is a different,
> > distinct subtype. In other words: cn;foo is a subtype of cn
> > cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype of cn.
> 

I would take the opposite stance and say that bar should be a 
subtype of foo, which is a subtype of cn.

> > Am I off in my thinking? RFC 2251 says that "An AttributeDescription
> > with one or more options is treated as a subtype of the attribute
> > type without any options".
> 

I would not agree with the above sentence. So my opinion would be 
that the examples are correct and the text is wrong. The text as it 
stands implies that it can only support one level of subtyping, rather 
than multiple levels which is needed.

Try to draw a Venn diagram for an attribute type with multiple 
options, where the options intersect is surely a multiple level 
subtypes of the attribute, is it not.

For example, a home phone number is a subtype of a phone 
number, and a private home phone number is a subtype of a home 
phone number. We should be able to cater for this in the LDAP data 
model with multiple options e.g. phone;home;private.

David



> I agree it needs to be clarified. There are two ways of interpreting
> this sentence.  I parse subtyping as 
>  If A is a subtype of B and B is a subtype of C, A is a subtype of C,
>  just not an 'immediate' subtype.  
> 
> > Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic
> > examples in 2596 are invalid. RFC 2251 states that the options must
> > appear in ascending order.
> 
> You're right, that's a typo in 2596.  We'll fix that when it is time
> to reissue.
> 
> 
> > At the end of section 3.3, it says: "Thus in general, clients SHOULD
> > NOT use the language code option in AttributeDescription fields in
> > search filters". Is this because they might get more matches than
> > they bargained for? It would be nice if the "Thus in general" part
> > was spelled out a bit more.
> 
> It was earlier in this section.  This is just a reminder.
> 
>    Client implementors should however note that providing a language
>    code in a search filter AttributeDescription will often filter out
>    desirable values where the language code does not match exactly.  
> 
> Mark Wahl
> Sun Microsystems, Inc.
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************