[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Last Call Comment: LDAP & X.500 Component Matching RulestoProposed Standard



--On mandag, mai 12, 2003 17:29:44 +1000 Steven Legg <steven.legg@adacel.com.au> wrote:

Hi Harald,
Hi Steve!

(Kurt - you have been dragged into this thread because of draft-zeilenga-ldap-features - see section at the end...)
Harald Tveit Alvestrand wrote:

Last Call comment on this document:

The document fails to describe how a client can determine
whether or not an
LDAP server implements the componentFilterMatch matching rule.

Which is normal practice for matching rule definitions, and various
other things in LDAP. LDAP and X.500 don't have a standardized
mechanism for determining what a server can or can't support,
and LDAP specifications rarely address this question.
draft-zeilenga-ldap-features-xx.txt is attempting to rectify this
situation, though it is not clear to me what the current status
of this draft is.

One way to deal with the varying capabilities of LDAP servers
is for directory-using application specifications to include an
application profile that lists all the features, matching rules included,
that an LDAP server must support in order to claim conformance with the
application. This is the approach PKIX has taken.

so instead of specifying a ways to find out runtime, you have a way to
specify it at procurement time..... I wouldn't call it invalid, but it
seems unpleasant to me....




Since the extension is complex, and presently unsupported,



There is one implementation.



good. I was thinking "unsupported in the presently fielded LDAP servers".





it
will likely
be critical for interoperability (and proper error messages)
that a client
know how to check whether this extension is present or not in
a server.
(It's possible, albeit expensive, for a client to have
fallback in some
situations by pulling large sets of objects to the client and
doing the
required matching client-side. Unless he knows whether or not it is
supported, this becomes more complex.)

It is not clear to this reader whether this should be indicated via
"supportedControl", "supportedExtension",
"supportedLDAPVersion"



None of the above apply. The best fit is "supportedFeatures" from
draft-zeilenga-ldap-features-xx.txt, though it is debatable whether
a simple yes/no indication is adequate for expressing support for
something as expansive as component matching. I expect at least some
implementors will support component matching incrementally, thus
application profiles would appear to be more appropriate. I leave it to
the IESG to decide.




ouch - you're saying that you expect clients to have to deal with not only 
implemented/unimplemented, but with partial implementations?????



that gets VERY thorny to deal with client-side... if you specify one or two 
subsets, I could live with it, but "random subset of functionality 
implemented" is something I do not like to say is conformant to any IETF 
protocol.....



but in an ideal world, that would be decided by an LDAP WG, not by the IESG.



fyi, the present situation with draft-zeilenga-ldap-features is that it was 
looked at by the IESG in November of last year, but was returned to the 
author with comments, and hasn't been updated since. I'm CCing Kurt on this 
mail too, so that he gets a heads-up.... if that document makes it through 
quickly, I'd be a LOT happier if you specified an OID for use with 
"supportedFeatures"....



                  Harald