Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)
RFC 3876
Note: This ballot was opened for revision 07 and is now closed.
(Ned Freed) (was Yes) Discuss
Discuss (2003-12-07)
The note at the end of section 2 says: Note. If the AttributeDescriptionList is empty or comprises "*" then the control MUST be applied against every user attribute. If the AttributeDescriptionList contains a "+" then the control MUST be applied against every operational attribute. But "AttributeDescriptionList" appears nowhere else in the document, nor is it part of any of any of the components of SimpleFilterItem. I assume this is referring to the attributes field of the search request this control is attached to, but this really needs to be made more explicit. More generally, an interesting side effect of this control is that it doesn't seem to be possible to say "return only the values of these attributes that match these criteria but return all values of all other attributes". Is this going to be a problem? And even if it isn't a problem, some text describing this limitation would seem to be in order. Nits: The first example uses the domains hotmail.com and sun.com. These should be changed to our customary example domains. Section 7. "Registrigration" -> "Registration". Copyright boilerplate has (date) rather than an actual date. Section 12 should be marked as needing to be removed prior to publication. Further discussion: We now have a number of LDAP controls that apply to searching (2891 - server side result sorting, 2696 - paged results, 2649 - signed results). I believe I can argue that the utility of being able to specify any of these in an LDAP URL is questionable, and that wanting paged results, sorted results, or signed results is a function of the underlying application and not of the URL the application is processing. But I cannot make the same argument stick for this document -- it seems quite reasonable to want to be able to construct an LDAP URL that says "return only the attribute values that match these criteria". As such, I wonder if it would not be appropriate to define an LDAP URL extension that allows this control to be specified. (Is this why ABNF for specifying a string version of this control was worked out so carefully?)
(Harald Alvestrand) Yes
(Ted Hardie) Yes
Comment (2003-12-17)
No email
send info
send info
In reply to Ned's Discuss: AttributeDescriptionList is defined in RFC2251, and is part of the core LDAP spec. The RFC is referenced as [2] in this draft. I suspect the community of developers working won't have an issue with it, but just in case, would "(see [2])" at the first mention of AttributeDescriptionList solve the problem?
(Steven Bellovin) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Russ Housley) No Objection
Comment (2003-12-17)
No email
send info
send info
The document does not follow the guidelines for examples. It uses the author's phone numbers and email addresses.
(Allison Mankin) No Objection
(Thomas Narten) No Objection
(Jon Peterson) No Objection
(Bert Wijnen) No Objection
Comment (2003-12-18)
No email
send info
send info
From OPS Directorate review: The editorial quality is not too good. As one nit, there should not be numbered references in the boilerplate to RFC2026, that'll go awry when rfc-editor remvoes the boilerplate.. Registrigration of the Matched Values control as an LDAP Protocol ==> s/Registrigration/Registration/ Bert adds: - IANA considerations: This document uses the OID 1.2.826.0.1.3344810.2.3 to identify the matchedValues control described here. This OID was assigned by TrueTrust Ltd, under its BSI assigned English/Welsh Registered Company number [13]. Probably OK? I am not sure. In any event we should decide consciously. - no IPR section. Would that not be usefull to have, to make sure that individual submitter understands that he needs to file any IPR that he/she may have?