Subject: RE: The 'any' attribute type

From: Ron Ramsay <[email-masked]>
Date: Fri, 27 Aug 1999 10:35:33 +1000

Yes, I have a problem.

The advantage of the use of 1.1 is that it isn't a valid OID. It
therefore requires no special processing as it will never be found in
the directory. Maybe you could try something like unix wildcard matching
where *;ja will match <anything>;ja.

The problem with 1.1.1 is it can only be used once. You really need a
taxonomy:

iso(1)
    invalid-attr(1)
    kludge(2)
        a-silly-idea(1)
        another-silly-idea(2)
            being-silly-this-way(1)
            being-silly-that-way(2)
        placeholder(3)
    kludge(3)

(You can't use 1.1.1 having already terminated at 1.1.)

(Got DAP?)

> -----Original Message-----
> From:	Jim Sermersheim [SMTP:[email-masked]]
> Sent:	Friday, August 27, 1999 10:17 AM
> To:	[email-masked]
> Subject:	The 'any' attribute type
> 
> 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: Ron Ramsay <[email-masked]>
Date: Fri, 27 Aug 1999 15:07:54 +1000

I agree with Mark. The client can simply ask for the attributes it
wants. In the reply, any attributes with a language option set to French
(say) or with no language option at all can be displayed and all others
can be discarded. This would be the 'French' configuration of the
address book. The Italian version would work similarly.

I don't think servers should be burdened with tasks that are better
handled in other ways. In particular, changing the model to suit the
client is very irksome. I refer here to the notion that a particular OID
can represent 'all attributes'.

> From:	Bruce Greenblatt [SMTP:[email-masked]]
> Sent:	Friday, August 27, 1999 2:51 PM
> To:	Mark Wahl; Jim Sermersheim
> Cc:	[email-masked]
> Subject:	Re: The 'any' attribute type
> 
> 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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 27 Aug 1999 19:00:32 -0600

Ok, I'll quit teasing. There are three I think, (someone else here is defining them) They look something like this (these are only vague descriptions):

This one is used to request that a value's CSN is returned, prepended to the value like T#S#R#s:attrvalue (see LDUP for meaning of TSRs)
myAttr;valueCSN

This one is used to ask that deleted values be returned.
myAttr;deletedValues

This one is used to ask that only values, update since xxx be returned.
myAttr;valuesSince-xxx (where xxx is a GMT spec)

I know... Why not just use controls? In the first case (valueCSN) it's handy for LDIF and in the other two cases, it's a solution that doesn't require changes/additions to the client.

I didn't want to introduce the specific attr type options because I was afraid of falling down a rathole and not addressing the 'all' attrs thing.

Jim

>>> Mark Smith <[email-masked]> 8/27/99 5:12:10 PM >>>
Jim Sermersheim wrote:.
>
> ...
> The attribute type option I want to use this with, is one that affects
> the transmission of any value, regardless of syntax.

I'll reserve final judgment until I see your proposal, but offhand such
an attribute type option scares me a bit (it sounds like using it will
be a big change for clients and servers).  I am not a big fan of ;binary
even.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: Ron Ramsay <[email-masked]>
Date: Mon, 30 Aug 1999 11:26:53 +1000

I'm fascinated by the ;valuesSince-xxx option. Are we moving towards
stored procedures? What are the OIDs for the attribute descriptions?

1.1.<valuesSince>.1999.8.30.11.25?

I for one will be sorry to see the passing of the 'static' directory.

> Sent:	Saturday, August 28, 1999 11:01 AM
> To:	[email-masked]
> Cc:	<; <
> Ok, I'll quit teasing. There are three I think, (someone else here is
> defining them) They look something like this (these are only vague
> descriptions):
> 
> This one is used to request that a value's CSN is returned, prepended
> to the value like T#S#R#s:attrvalue (see LDUP for meaning of TSRs)
> myAttr;valueCSN
> 
> I know... Why not just use controls? In the first case (valueCSN) it's
> handy for LDIF and in the other two cases, it's a solution that
> doesn't require changes/additions to the client.
> 
> I didn't want to introduce the specific attr type options because I
> was afraid of falling down a rathole and not addressing the 'all'
> attrs thing.
> 
> Jim
>