Re: RFC 2596 questions

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:12 PM 9/13/00 -0600, Jim Sermersheim wrote:
>I have a few questions about RFC 2596 (Language Codes in LDAP).

Timely post... I've been meaning to post my comments regarding
this TS based upon my recent implementation of it.

>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
>Is that correct?

Yes.  But I believe this should be changed to:
        "An attribute description SHALL NOT contain more than
        one language option."

with that said, the statement above might have actually meant:
  An entry MAY contain any number of attributes with or
  without language options.

That is, the statement may just refer to the fact that you
can have:
        cn: x
        cn;lang-en: x
        cn;lang-en-us: x

and not, how you and I read it.  That is, as allowing:
        cn;lang-en;lang-en-us: x


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

That's my read as well.  "cn;lang-en-US;lang-ja" has super types
"cn", "name;lang-en-US;lang-ja", and "name".

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

What about "cn;binary;lang-en"?  Should not this have the same
super types of "cn;lang-en" but be transferred using ";binary"?
Is ";dynamic" like ";binary"?
Why aren't multiple language tags, if allowed, like this?

I concur that this is counter to RFC2251.  However, if the
server holds for in an entry:
        cn: foo
        cn;lang-x-rot13: sbb

and request cn;binary the server should only return the
first value (using binary transfer) and not the second.
This seems odd to me.  Then, again, ;binary is odd.


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

Correct.

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

This seems odd.  I would think the opposite to be true.  That
is, if I search for "cn=foo" I will match more than just cn values,
I'll match cn;lang-en, cn;lang-x-rot13, etc..

In our implementation, we don't allow multiple language tags
(as you and I read the RFC) as they don't behave like other
content (e.g MIME) tags with multiple language tags.  And,
unlike some implements, we adhere to the following:
   Implementations MUST NOT otherwise interpret the structure of the
   code when comparing two codes, and MUST treat them as simply strings
   of characters.

So, if you want to tag some content for multiple languages, you
have to provide it as separate attribute descriptions:
        cn: foo
        cn;lang-EN: foo
        cn;lang-EN-US: foo
        cn;lang-EN-GB: foo
        cn;lang-x-rot13: sbb

and request search to return "cn" would return all and "cn;lang-X"
would return the particular "cn;lang-X" value.

As far as ";binary" is concerned, we'd strip it from the option
list before doing subtyping.  So, asking for "cn;binary" would
return all them using binary transfer.

BTW, we don't actually support binary transfer of directoryString
(yet), but we do this for syntaxes we do support binary transfer
of.