Subject: Re: RFC 2596 questions

From: Mark Wahl <[email-masked]>
Date: Mon, 18 Sep 2000 18:20:21 -0500

> I have a few questions about RFC 2596 (Language Codes in LDAP).
  
> Section 3.1 says "Multiple language options may be present on a particular 
> value.".
> To me, this says the following is allowable:
> cn;lang-en-US;lang-ja: JoeBob

Yes.

> Is that correct? If so, I believe the following assumption is also correct:
> Any value held in an attribute with more than one language option (i.e. the 
> example above) does NOT exist in the attribute with a subset of those 
> language options. In other words, the example above does NOT imply that 
> there are values like:
> cn;lang-en-US: JoeBob
> cn;lang-ja: JoeBob
> Right?
  
Those are different values.  You could have them there as well, if you wished.

For example, 'cn' and 'sn' are subtypes of 'name'.  You can have an entry with
the three attributes:

name: joe
cn: joe
sn: joe

> 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.

> 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 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.

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 21 Sep 2000 17:50:40 +0100

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

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.
> 
> > 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.
> 

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

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 [email-masked]
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

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