Subject: The 'any' attribute type

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 26 Aug 1999 18:17:00 -0600

Last year, Bruce Greenblatt brought up the notion of using a nomenclature like "*;lang-ja" in order to specify that 'all' attributes which are stored using the Japanese lang tag be returned from a search operation. There was a problem with that, since the * is a special character which represents an attribute description string (not just an attribute type).

We're at a point where we need to define a new attribute type option, and it would be really nice if this functionality existed. Currently, the special (retired) oid 1.1 is used to specify 'no' attributes should be returned. Does anyone see a problem with introducing a new special oid (maybe 1.1.1) which represents 'all' attributes should be returned?

Bruce's example would look like: 1.1.1;lang-ja

Jim

---

From: Mark Wahl <[email-masked]>
Date: Thu, 26 Aug 1999 19:47:22 -0500

Yes, for four reasons.

First, 

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.

Second, 

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. 

Third,

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

Fourth,

What does a client do with foo;lang-ja when it does not know foo?  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.  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.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 26 Aug 1999 21:51:08 -0700

>would seem to be best left up to the client.

Mark,

I have to disagree with you on this point.   There is a definite need for
this type of feature.  The typical scenario that I use comes from a real
scenario (OfficeVision anyone).  Consider an LDAP server that is being used
as the back end for an address book application.  Assume that it is
installed at a location in Switzerland.  This same server is likely to have
some users that want their information in French, some that want it in
German, some that want it in Italian, and maybe even some that want it in
Swiss or English...  There is currently no way to make use of the language
tags for this purpose.  I see this as being completely different from
"asking for all attributes whose attribute types have a 'k' in them".  From
my perspective it would be very cumbersome for the client to have to get
back all of the attributes in every language, sort through them (in random
order for each entry) and then display them.  Since the server has already
tagged the attributes with the language tag, I think that it makes
substantially more sense to ask the LDAP server to make use of the
information that it has already tagged.  I also think that such a feature
would make the sort control substantially more useful.

That said, I'm not too keen on the OID thing that Jim proposed.  Mark's
arguments are very persuasive.  What was the rationale that my "*;jp"
proposal got shot down.  I can't remember what it was, and my slow link
from home prevents my from searching the archive.  If this doesn't work,
some company (Novell maybe) could always define an OID under their branch
in the tree to mean the same thing that Jim proposed 1.1.1  to be.

Bruce

>Innosoft International, Inc.
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: [email-masked] (Rob Weltman)
Date: Thu, 26 Aug 1999 22:12:46 -0700

We also had the short-lived "preferred language control" a year or two ago, which would have filled the same purpose but better (as I recall) - it would have caused the
most explicit language-tagged attribute subtypes to be returned if there were any, and otherwise the base (untagged) attributes. That would let you get a full set of
attributes back with one search, including "shared" attributes without any language variants.

  When that was killed, we added support for doing it in the client (in the C and Java LDAP client SDKs).

Rob

---

From: Bruce Greenblatt <[email-masked]>
Date: Sun, 29 Aug 1999 13:13:05 -0700

At 10:12 PM 8/26/99 -0700, Rob Weltman wrote:
>  We also had the short-lived "preferred language control" a year or two
ago, which would have filled the same purpose but better (as I recall) - it
would have caused the
>most explicit language-tagged attribute subtypes to be returned if there
were any, and otherwise the base (untagged) attributes. That would let you
get a full set of
>  When that was killed, we added support for doing it in the client (in
the C and Java LDAP client SDKs).

Why was that control killed?  It would certainly meet the requirement to
get all the attributes in a certain language, and not get one's that are in
some unwanted language.

Bruce