Re: The 'any' attribute type

[rweltman@netscape.com (Rob Weltman)]

  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


Bruce Greenblatt wrote:

> At 07:47 PM 8/26/99 -0500, Mark Wahl wrote:
> >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,
>
> 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
>
> >Mark Wahl, Directory Product Architect
> >Innosoft International, Inc.
> >
> >
> >
> ==============================================
> Bruce Greenblatt, Ph. D.
> Directory Tools and Application Services, Inc.
> http://www.directory-applications.com