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

Re: RFC 2596 questions



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