[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Active Directory question

At 04:01 PM 4/19/2004, Jim Sermersheim wrote:
>Regarding #1, My opinion is that servers should not return extension information like this unless it is solicited.

You and I like differ in what we consider 'like this'.

The problem with the range extension is that it using options
not to create subtypes.  It using options (which don't conform
to the protocol specification) to alter the basic semantics
of the search operation in a fashion which is incompatible
with peers which don't support the extension.  Assuming the
client doesn't puke, the client certainly won't treat these
values as being of the right type (it might consider them
to be of some oddly named subtype, but that's not quite the
same thing).

>Unfortunately, we have already set a precedent with language tags and the binary option which both return unsolicited attribute options.

But there are some significant differences.  First, language
tag options and the binary option conform to RFC 2251, 4.1.5.
These range options don't.

Second, with language tags, the presumption is that values of
the subtypes (the tagged descriptions) are being returned in
addition to those of the untagged description, just like
values of 'cn' when asking for 'name'.  With these range options,
the values of the ranged descriptions are sent INSTEAD of
unranged descriptions.  This means, even clients which don't
choke on the protocol violation, still won't recognize the
values as being of the same description.

Third, with the binary option (as used in practice), only applies
to attribute types (e.g., userCertificate) which do not have
native string encodings and isn't a problem (the information
presented with ;binary is not available otherwise).  While it
could technically be used with other attribute types (e.g., cn),
it is recognized that returning such without solicitation
would be problematic (because the client might treat it as
a subtype) (and was intended only be used where the server
couldn't make the information available without ;binary, e.g.,
server didn't support the native string encoding (or syntax
didn't have one)).  I think Steven's ;binary revision proposal
adequately addresses this problem (e.g., don't return cn;binary
unless cn;binary was requested).

>The danger is exaclty the problem you've run into ? clients are given data that they don't understand and can't properly work with.

I disagree that this is the case with language tags and ;binary.
I believe LDAP was designed specifically with language tags
and ;binary in mind.

With range option is quite different.  Not only are the options
invalid, the client not supporting this extension will interpret
the response as not containing values of the requested type
(but might interpret the response as containing values of a
subtype)... or interpret the response as a protocol error
(and disconnect).

This is why I say the range extension is truly non-optional,
which is far worse than being not truly optional.  I think
language tags and ;binary, when properly implemented (or
as generally implemented in practice), are truly optional.

>Since we're talking about this on the LDAPBis list, I'll suggest that we add a recommendation to this effect:
> 
>Servers SHOULD NOT return attributes with options unless solicited to do so.

Since '*' does solicit all user attributes and 'cn;lang-x-foo'
is a user attribute, it should be returned.  Since a requesting
'name' is a request for the attribute 'name' AND its subtypes,
'name;lang-x-foo' (as well as 'cn') is solicited.  So, your
suggestion seems meaningless as worded.

But, if I take your suggestion as I think you intended it,
I would argue strongly against it.

Attribute options mechanism and subtypes created through this
mechanism IS a standard feature of LDAP.  RFC 2596 defines
a set of option-based subtypes just as some schema document
might define a set of SUP-based subtypes.  As long as these
subtypes are used consistently with core specification, the
are no significant interoperability issues.

Now, I note, the language tag specification needs to be more
clear that tagged values are provided IN ADDITION TO non-tagged
values.  And ;binary specification needs to be address issues
previously raised on this list.

But, I think, the [Protocol] and [Models] are fine with
regards to attribute options.

However, [Roadmap] likely should say something in general
about extensions.
        LDAP is an extensible protocol.  Extensions are
        expected to be truly optional.

There is little we can say beyond this to deter creation
of extensions which are not truly optional or extensions,
such as range options, which are truly non-optional.

Kurt


> 
>Jim
>
>>>> "Schleiff, Marty" <marty.schleiff@boeing.com> 4/18/04 12:31:39 AM >>>
>Gentlemen,
>
>When using ldapsearch to lookup the membership in an Active Directory group, I got the following (abbreviated) response:
>
>CN=PC Backup Group 1,OU=Groups,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com
>member;range=0-999=CN=Peterson\, Randy R,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com
>member;range=0-999=CN=Tatham\, William C,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com
>member;range=0-999=CN=Pham\, Steve,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com
>
>I'd never before encountered "range=0-999" and wondered what it meant. A little searching turned up the following URLs:
><http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt>http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and <http://www.hut.fi/cc/docs/kerberos/nss_ldap.html>http://www.hut.fi/cc/docs/kerberos/nss_ldap.html 
>
> From the second URL: "Active directory uses a method called "Incremental Retrieval of Multivalued Properties" which nss_ldap has no support for, at least not yet. Querying groups having more than 1000 members will return the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. This is not recognized by nss_ldap, so you will not see any members for that group. More information can be found in the (now expired) Internet Draft labeled Incremental Retrieval of Multivalued Attributes <draft-kashi-incremental-00.txt> ."
>
>I was also referred to <http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt>http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not sure that applies to my situation (it seems to describe how a client could request the server to return a partial set of values for a multi-valued attribute -- in my case I didn't request the range, Active Directory just gave it to me when I really wanted the complete set of values).
>I'd value the opinions of this list around the following questions:
>1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions.
>2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". 
>3) Does The Open Group assessment of "LDAP Ready" require a client to understand ranges?
>4) Does The Open Group assessment of "LDAP Certified" require a server to return ranges? Or if a server does return ranges (which probably would confuse many clients), can that server be "LDAP Certified".
>5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be able to request ranges of multi-values attributes (or do they already have this capability and I'm just unaware)?
>Thx,
>
><mailto:Marty.Schleiff@boeing.com>Marty.Schleiff@boeing.com ; CISSP
>Associate Technical Fellow - Cyber Identity Specialist
>IT Access & Security Services
>(425) 957-5667
>