You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Marc Boorshtein <mb...@gmail.com> on 2007/11/25 21:59:33 UTC
Empty DN ("") String Value?
I wanted to get an opinion from the other java ldap projects. Should
the toString() method of a class that represents a DN return null or
an empty string? I would think an empty string but JLDAP returns
null. Anyone have an opinion on the matter?
Thanks
Marc
Re: Empty DN ("") String Value?
Posted by Marc Boorshtein <mb...@gmail.com>.
> RFC 4514 states :
>
> 2.1. Converting the RDNSequence
>
> If the RDNSequence is an empty sequence, the result is the empty or
> zero-length string.
>
>
>
> Which means that a DN should be the empty String, ie : "", not null.
>
> IMHO and as far as I understand the RFC :)
>
A very good point in-deed. Morale of the story is to check the RFCs :-D
Marc
Re: Empty DN ("") String Value?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Marc Boorshtein wrote:
> I wanted to get an opinion from the other java ldap projects. Should
> the toString() method of a class that represents a DN return null or
> an empty string? I would think an empty string but JLDAP returns
> null. Anyone have an opinion on the matter?
>
> Thanks
>
> Marc
>
>
RFC 4514 states :
2.1. Converting the RDNSequence
If the RDNSequence is an empty sequence, the result is the empty or
zero-length string.
Which means that a DN should be the empty String, ie : "", not null.
IMHO and as far as I understand the RFC :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Empty DN ("") String Value?
Posted by Marc Boorshtein <mb...@gmail.com>.
Well, based on the discussion I am going to change toString() to
return an empty String (""). I think its bad form for an instantiated
object to have 'null' for its string representation anyway.
Marc
Re: Empty DN ("") String Value?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi guys,
> Jon Roberts wrote:
>> Since there is a no-argument constructor DN(), perhaps the original
>> thinking was that null and the rootDSE "" are synonymous.
It was not really a thinking, much more a literal implementation of the
RFC :
RFC 4514 states :
2.1. Converting the RDNSequence
If the RDNSequence is an empty sequence, the result is the empty or
zero-length string.
In java, the zero-length String is "", not null. In no way null and ""
(which is _not_ representing the rootDSE - a very common misconception :
A => B does not necessarily implies that B => A - ) are synonymous.
Talking about Apache DS LdapDN implementation, our internal data
structure handling DNs, the empty constructor is used when you need to
manipulate DNs by adding RDNs to it. And if you have :
LdapDN dn = new LdapDN();
System.out.println( dn ) ;
you will obtain just a empty line (ie, ""), not 'null'.
>> On the other
>> hand, the existence of this constructor makes as much sense to me as the
>> redundant addRDN() and addRDNToFront() methods (ie. none at all). I
>> suppose *somebody* may want to build a DN instance iteratively, but I
>> would consider it easier to do so concatenating strings for submission
>> to the more relevant constructor with argument.
DN are not Strings, DNs are structures which have a String
representation (so the RFC 4514). Inside a LDAP server, it's much better
to hold DNs into such a structure instead of manipulation Strings. A
simple exemple : how do you compare those two DNs and how can you tell
if they are equal ? :
dn1: dc=example, dc=com
dn2: |0.9.2342.19200300.100.1.25=Example, ||0.9.2342.19200300.100.1.25=COM
As String, you bet they are different, but they are just representing
the very same element.
|
Hope it helps.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Empty DN ("") String Value?
Posted by Howard Chu <hy...@symas.com>.
Jon Roberts wrote:
> Since there is a no-argument constructor DN(), perhaps the original
> thinking was that null and the rootDSE "" are synonymous. On the other
> hand, the existence of this constructor makes as much sense to me as the
> redundant addRDN() and addRDNToFront() methods (ie. none at all). I
> suppose *somebody* may want to build a DN instance iteratively, but I
> would consider it easier to do so concatenating strings for submission
> to the more relevant constructor with argument.
Sounds like someone was making a (perhaps futile) stab at instilling the
concept that DNs are honest-to-god sequences of structured data. A good goal,
at least.
> This exercise in software archeology underscores a major reason I think
> JLDAP is latent: a lot of cruft but nobody of original authorship to
> explain or clean it up. As for the rest of us, if nobody touches it
> nobody breaks it, so there it sits. My 2c.
Keep putting in your 2c. It obviously needs more feedback from more people
with real operational experience using it.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Empty DN ("") String Value?
Posted by Jon Roberts <jo...@jonanddeb.net>.
Michael Ströder wrote:
> Marc Boorshtein wrote:
>>I wanted to get an opinion from the other java ldap projects. Should
>>the toString() method of a class that represents a DN return null or
>>an empty string? I would think an empty string but JLDAP returns
>>null. Anyone have an opinion on the matter?
Not a strong one, since I don't make use of DN.toString(). In my view
the DN utility class is for deconstructing, analyzing, and comparing
non-trivial distinguished names... I invariably have the string version
to begin with.
> It really depends on what you want to express. Note that "" represents
> the rootDSE or root naming context. So "" would reference something
> existing or well-defined. IMHO NULL (or None in Python) would better
> signal something undefined or none-existing.
This was my first thought, but according the source as I read it these
cases would not be distinct: if there are no parent RDNs superior to the
entry reflected in the represented DN, toString() will return null.
Since there is a no-argument constructor DN(), perhaps the original
thinking was that null and the rootDSE "" are synonymous. On the other
hand, the existence of this constructor makes as much sense to me as the
redundant addRDN() and addRDNToFront() methods (ie. none at all). I
suppose *somebody* may want to build a DN instance iteratively, but I
would consider it easier to do so concatenating strings for submission
to the more relevant constructor with argument.
This exercise in software archeology underscores a major reason I think
JLDAP is latent: a lot of cruft but nobody of original authorship to
explain or clean it up. As for the rest of us, if nobody touches it
nobody breaks it, so there it sits. My 2c.
Jon Roberts
www.mentata.com
Re: Empty DN ("") String Value?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Michael Ströder wrote:
> Emmanuel Lecharny wrote:
>
>> Hallvard B Furuseth wrote:
>>
>>> Michael Ströder writes:
>>>
>>>
>>>> It really depends on what you want to express. Note that "" represents
>>>> the rootDSE or root naming context. So "" would reference something
>>>> existing or well-defined. IMHO NULL (or None in Python) would better
>>>> signal something undefined or none-existing.
>>>>
>>> Yes. There is one case in the LDAP ASN.1 grammar (in rfc 4511) where
>>> you need to distinguish between an absent DN and an empty DN: The LDAPDN
>>> field ModifyDNRequest.newSuperior, which is 'OPTIONAL'. There may be
>>> others in LDAP extensions defined elsewhere.
>>>
>>>
>> This is starting to be confusing. The initial question was :
>>
>> "Should the toString() method of a class that represents a DN return
>> null or an empty string?"
>>
>
> This can't be answered consistently without knowing what this returned
> value is used for. But I'll try: If you just created an object instance
> of the DN class without assigning any real DN to it method toString()
> should return NULL instead of "".
>
In this very case (ie, you do a new LdapDN(), which is an empty DN), I
would suggest you return "", not null. But if the DN is optional and not
used (as in a ModifyDN with no newSuperior), then you should return NULL
=> no newSuperior DN.
Do we agree ?
>
>> But if the question is :
>> "How do I represent a DN in a structure when I do a toString() on this
>> structure", then the answer would be :
>> - null if the DN member is null
>>
>
> I guess with "DN member" you're referring to the class' attribute for
> storing the DN. So I guess this is the case I described above.
>
yep. Like the 'name' element in a LdapResult (which is a mandatory
value, though should resolve to "" )
>
>> - "" if the DN does not hold any value.
>>
>
> I doubt that this is right or maybe I misunderstood "does not hold any
> value".
>
A LDAPDN is a translation of the X500 structure. It contains RDNs, and
when you don't have any RDN, then the DN does not contain any value.
This is what I wanted to express...
> Again: "" refers to the rootDSE or is the root naming context in search
> requests with scope!=base. If you pass "" to any other method (e.g. for
> a modify request) then it has a specific meaning (e.g. modifying the
> rootDSE).
>
correct.
> Well, not being a Java programmer I will stay out of further discussion
> because I don't know what's common in the Java world.
>
Oh, I don't think it's a Java problem, unless we consider it to be a
question on how to handle Null vs "" in Java.
I'm pretty sure that we are on the same page, to some extent, and that
Marc have the answers he was expecting, thanks to your mails !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Empty DN ("") String Value?
Posted by Michael Ströder <mi...@stroeder.com>.
Emmanuel Lecharny wrote:
> Hallvard B Furuseth wrote:
>> Michael Ströder writes:
>>
>>> It really depends on what you want to express. Note that "" represents
>>> the rootDSE or root naming context. So "" would reference something
>>> existing or well-defined. IMHO NULL (or None in Python) would better
>>> signal something undefined or none-existing.
>>
>> Yes. There is one case in the LDAP ASN.1 grammar (in rfc 4511) where
>> you need to distinguish between an absent DN and an empty DN: The LDAPDN
>> field ModifyDNRequest.newSuperior, which is 'OPTIONAL'. There may be
>> others in LDAP extensions defined elsewhere.
>>
> This is starting to be confusing. The initial question was :
>
> "Should the toString() method of a class that represents a DN return
> null or an empty string?"
This can't be answered consistently without knowing what this returned
value is used for. But I'll try: If you just created an object instance
of the DN class without assigning any real DN to it method toString()
should return NULL instead of "".
> But if the question is :
> "How do I represent a DN in a structure when I do a toString() on this
> structure", then the answer would be :
> - null if the DN member is null
I guess with "DN member" you're referring to the class' attribute for
storing the DN. So I guess this is the case I described above.
> - "" if the DN does not hold any value.
I doubt that this is right or maybe I misunderstood "does not hold any
value".
Again: "" refers to the rootDSE or is the root naming context in search
requests with scope!=base. If you pass "" to any other method (e.g. for
a modify request) then it has a specific meaning (e.g. modifying the
rootDSE).
Well, not being a Java programmer I will stay out of further discussion
because I don't know what's common in the Java world.
Ciao, Michael.
Re: Empty DN ("") String Value?
Posted by Hallvard B Furuseth <h....@usit.uio.no>.
Emmanuel Lecharny wrote:
> This is starting to be confusing. The initial question was :
Uh, right... I was halfway answering the question which is too short,
halfway Michael.
> "Should the toString() method of a class that represents a DN return
> null or an empty string?"
If a class represents a DN, toString() sounds like it should return that
DN's string representation as described in RFC 4514. If you mean to ask
what to return when a class instance represents an _empty_ DN, then the
string representation is "". toString() not returning a string sounds
strange to me whatever the object represents, but maybe that's because I
don't know java. But NULL ought to mean "no dn", not "the empty dn".
--
Regards,
Hallvard
Re: Empty DN ("") String Value?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hallvard B Furuseth wrote:
> Michael Ströder writes:
>
>> It really depends on what you want to express. Note that "" represents
>> the rootDSE or root naming context. So "" would reference something
>> existing or well-defined. IMHO NULL (or None in Python) would better
>> signal something undefined or none-existing.
>>
>
> Yes. There is one case in the LDAP ASN.1 grammar (in rfc 4511) where
> you need to distinguish between an absent DN and an empty DN: The LDAPDN
> field ModifyDNRequest.newSuperior, which is 'OPTIONAL'. There may be
> others in LDAP extensions defined elsewhere.
>
This is starting to be confusing. The initial question was :
"Should the toString() method of a class that represents a DN return
null or an empty string?"
I do think that the answer is : empty String (or zero length String, as
specified in the RFC).
But if the question is :
"How do I represent a DN in a structure when I do a toString() on this
structure", then the answer would be :
- null if the DN member is null
- "" if the DN does not hold any value.
Is it better ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Empty DN ("") String Value?
Posted by Hallvard B Furuseth <h....@usit.uio.no>.
Michael Ströder writes:
> It really depends on what you want to express. Note that "" represents
> the rootDSE or root naming context. So "" would reference something
> existing or well-defined. IMHO NULL (or None in Python) would better
> signal something undefined or none-existing.
Yes. There is one case in the LDAP ASN.1 grammar (in rfc 4511) where
you need to distinguish between an absent DN and an empty DN: The LDAPDN
field ModifyDNRequest.newSuperior, which is 'OPTIONAL'. There may be
others in LDAP extensions defined elsewhere.
OTOH the LDAPDN fields LDAPResult.matchedDN and BindRequest.name are
usually treated as if they meant "absent DN". In those cases it may
be better to return NULL, and/or treat NULL and "" as equivalent.
(For cases where a DN is not well-defined, I suppose an exception would
be the normal way to handle that in Java. But I'm not a Java
programmer.)
--
Regards,
Hallvard
Re: Empty DN ("") String Value?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Michael Ströder wrote:
> ... So "" would reference something existing or well-defined.
>
It's not really the case. The RootDSE is represented by an empty String
("") as specified by RFC 4512, (chap. 5.1), but it does not mean that ""
as a DN represents _only_ the rootDSE, or has any specific meaning, out
of a specific context. There are many other case where you may want to
use this value.
For instance, when you want to manipulate DNs, adding or removing RDNs,
an empty DN ("") makes a lot of sense. A null DN is just a null object,
so you can't write nullDn.toString() (=> a direct NPE will be raised ;)
and returning null when calling toString() makes no sense, as an empty
DN is perfectly valid.
At this point, it's just a personal convenience, if you prefer to test
for a null DN or for an empty String, do like you want :).
> Ciao, Michael.
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Empty DN ("") String Value?
Posted by Michael Ströder <mi...@stroeder.com>.
Marc Boorshtein wrote:
> I wanted to get an opinion from the other java ldap projects. Should
> the toString() method of a class that represents a DN return null or
> an empty string? I would think an empty string but JLDAP returns
> null. Anyone have an opinion on the matter?
I'm not a Java programmer but in Python one has also to distinguish such
cases ("" vs. None).
It really depends on what you want to express. Note that "" represents
the rootDSE or root naming context. So "" would reference something
existing or well-defined. IMHO NULL (or None in Python) would better
signal something undefined or none-existing.
Ciao, Michael.