Re: RFC 2596 questions

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

At 05:23 PM 9/14/00 -0600, Jim Sermersheim wrote:
>Kurt, I agree with everything you say here except I don't get one point:
> 
>>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.
> 
>Explain why you wouldn't return both?

For the same reasons "cn;lang-en" shouldn't return
"cn;lang-en;lang-en-us" nor "cn;lang-en-us;dynamic".
   An AttributeDescription with one or more options is treated as a
   subtype of the attribute type without any options. 

That is,
        cn;binary is a subtype of cn
        cn;lang-x-rot13 is a subtype of cn
        cn;binary;lang-x-rot13 is a subtype of cn

but
        cn;binary;lang-x-rot13 is NOT a subtype of cn;binary

So, when requesting cn;binary you only get cn;binary.  However,
I think most servers (if they returned binary transfer for the
attributes syntax) would return cn;binary and cn;binary;lang-x-rot13.

Maybe we read what we want into this statement:
   The presence or absence of the "binary" option only affects the
   transfer of attribute values in protocol; ...
That is, taking it out of context of the rest of the sentence:
   servers store any particular attribute in a single format.  

>Are you saying that the lang-x-rot13 is defined to be a transfer-only attribute type option?

no.  I'm saying that it appears that everyone is treating ";binary"
as a flag to indicate a different transfer mode, not as subtyping
option.

>The only other case I can think of is where the server doesn't know how to return a binary version of the rot13 value.

They are all directoryStrings so if ;binary is support for one,
likely supported for all.

>Then I just wanted to idly bitch for a bit... The way attribute type options are overloaded to sometimes be treated as subtypes and other times only affect transfer format is a nasty thing.

I concur...  

I have an idle bitch of my own:  For x of syntax binary and
I ask for "x".  Are folks expecting to get "x;binary" or just "x"
when they ask for all attributes?  inetOrgPerson defines some
attributes of binary syntax and says they should be transferred
using ";binary".  Are there counter examples?  What do implementations
do? 

OpenLDAP currently always transfer a binary syntax attribute using
;binary.  This is legal, but is it expected?


>I really hope we can document the difference well in 2251bis, and state that in fact, attribute type options that only affect wire transfer are NOT subtypes.

I concur.

>It'd be even better if we had a different nomenclature for those.

Too late for that, I think.


>Jim
>
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 9/13/00 7:31:27 PM >>>
>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.
>
>
>
>