Re: The 'any' attribute type

[Jim Sermersheim <JIMSE@novell.com>]

>Yes, for four reasons.
Ha ha. I initially wrote "how many problems can people see with this" but I thought it would invite too much...

>1.1 is known not to be attribute because of who it owns it and because it is 
>already assigned to be something that is not an attribute.  That does not mean
>you could assign new semantics to 1.2 or 1.1.1, because ISO or ITU-T 
>control those OIDs.

Okay, I was working off the assumption that the entire 1.1 arc (and any sub-arc) was retired/dead/unused.  I was just going off of Harald's page which says it's retired.  If there's a better OID to use, or a 'right' way to get something like this assigned, I'm open to ideas.  It's easy enough for me to get a Novell OID, I just thought 1.1.1 would be nice since what I'm trying to define is so close in functionality to what we use 1.1 for.

>That is not the way attribute subtyping is defined for LDAPv3 and X.500.  
>Attributes with options act as subtypes of the attribute without the option,
>and an attribute can be defined as a subtype of another.  This forms a hierarchy
>of attribute subtyping. 

I guess I'm feeling a little lost by this statement. First, I'm not trying to change the way attribute subtyping is defined, only new ways in which we can ask for attribute subtypes to be returned in a search.  I only mean for this functionality to be used in the attributes to be returned value of a search operation. Second, the attribute type option that we're trying to come up with IS slightly different than what people normally think of when they think of an attribute subtype, but only as much as the 'binary' attribute type is. It's rather hard to think of an attribute with the binary attribute type option attached as a true attribute subtype. The binary option only affects the manner in which the attribute values are transferred, not stored.

Currently, there is no way to say "return all attributes from this search in binary format".

>Language tags have an internal structure.  While you might not see both lang-ja
>and lang-ja-JP for differentiating between different forms of Japanese, in 
>other countries, such as Norway, you need differentiators for different
>cultural subsets of a single 'language'.

I'm slightly lost again but I'll take a stab. When I used the example of '1.1.1;lang-ja', The functionality I was trying to describe was that this is an attribute description which could be passed to a search request in the attribute description list of attributes to be returned. The server would respond by returning only attributes which had the lang-ja option. I'm not up on whether or not lang-ja-JP is or is not a subtype of lang-ja. If it is, attributes values of sn;lang-ja as well as sn;lang-ja-JP would be returned, otherwise only attributes of lang-ja would be. I'm beginning to regret using language tags in my examples, though I thought there would be *some* useful functionality there.  We really need this for a new attribute subtype which we're trying to define.

>What does a client do with foo;lang-ja when it does not know foo?

The same thing it does today when it asks for all attributes to be returned. If it either doesn't specify any attributes to be returned, or specifies a *, foo will be returned.

>I don't 
>see the value of an option that allows a client to be sent some subset of the
>attributes that is neither what it asked for nor a subtype of that.  We already
>have a way of asking for all information.  

As I said earlier, I can't implicitly ask for all attributes to be transferred in binary format.  The reason I want this functionality is so I can pair it with an attribute type option which causes the server to behave much like the binary attribute does (it alters or adds to the transmission format)

>This control is basically the same
>as asking for all attributes whose attribute types have a 'k' in them: the 
>client might get some information that it expected.  This sort of processing 
>would seem to be best left up to the client.

(I think this summarizes my want for such a thing) The only way the client can get back every attribute AND specify an attribute type option (like binary or some other attribute akin to it), is to dredge the schema and build a humongous attribute description list for the attributes to be returned in a search request.

The attribute type option I want to use this with, is one that affects the transmission of any value, regardless of syntax.

Jim