Steve.
RFC 2551
doesn't say, that EMPTY values are not allowed. That is a valid value,
IMO.
I would refrain
from the "meaninless" comment in such discussion. Since LDAP supports "non
existence" check, i.e. I can check if the object contains an attribute, that
feature must be supported in implementation. Another words, the storage, that
has "existence" feature will be used in the way:
if( attribute exists )
{
check for the values ( WHERE an empty value got to
be honored if the spec allow it!!!)
}
else
{
...
}
You can not
replace an EMPTY VALUE with "vbNull" thing, just because, they are not the
same!
A real example.
A device has objects of the same class, but different types. Different
type is being defined by an attribute. The EXISTANCE of another attribute is
sensitive for the physical device, that LDAP mirrors. This ANOTHER attribute
may be empty (NOT SPACE, mind you). In this case (we have around 80 classes of
this kind of objects), since LDAP RFC doesn't deny it explicitly, it
would be unwise to dance around and simulate empty value as SPACE or something
else.
So, the bottom
line is, that if AD doesn't allow to have the empty value, I will accomodate
for it in the program, but to I'm far from saying "It's OK." It is not!
Sincerely,
Val.
From RFC 2251 (complete section
quoted below) "Attributes MUST have at least one value when
stored".
To
releat Charles' question, why do you need to store an empty attribute?
Empty attributes are meaningless: LDAP does not have any concept of null
values. You can empty an attribute after instantiating it, if you want
to.
"4.1.8.
Attribute
An attribute consists of a type and one or
more values of that type.
(Though attributes MUST have at
least one value when stored, due to
access control
restrictions the set may be empty when transferred in
protocol. This is described in section 4.5.2, concerning
the
PartialAttributeList
type.)
Attribute ::=
SEQUENCE
{
type
AttributeDescription,
vals SET OF AttributeValue }
Each
attribute value is distinct in the set (no duplicates).
The
order of attribute values within the vals set is
undefined and
implementation-dependent, and MUST NOT be
relied upon."
Charles.
Thank you
for the input.
I could not
find the fact, that LDAP doesn't allow the empty values for the strings in
4.1.8 of RFC 2251. But, I do know, that both NDS and Netscape Directory
Server allow to have empty values for the attributes. And in a couple of
places of the RFC (particularly in the definition of the Distinguished
Name syntax) there is mentioning of empty value as a valid
one.
Would you
consider LDAP implementation by Novell and Netscape as not going with the
standarts?
Val.
