Bug #34689 for perl-ldap: suggestion for the position of CR character in Net::LDAP::LDIF entry

Fri Apr 04 18:35:27 2008 Uwe.Werler [...] o3si.de - Ticket created

Subject:	suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Sat, 05 Apr 2008 00:35:05 +0200
To:	bug-perl-ldap [...] rt.cpan.org
From:	Uwe Werler <Uwe.Werler [...] o3si.de>

Hello, after some testing and playing around with Net::LDAP::LDIF and the back_perl "database" from OpenLDAP I found that some entries will not be accepted by the latter if I use an entry (or a list of them) produced by the LDIF module. The cause of this is the "CR" at the beginning of each entry/DN and the missing empty line at the end. I know that this doesn't break RFC2849 and so is not the problem of Net::LDAP::LDIF. But for compatibility reasons I suggest to print the "\n" character not before but after each entry. This produces the same output as by ldapsearch and will be accepted by the perl backend from OpenLDAP. Thanks in advance for Your advices. Regards Uwe

Sat Apr 05 04:19:59 2008 Uwe.Werler [...] o3si.de - Correspondence added

Subject:	[rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Sat, 5 Apr 2008 10:19:05 +0200
To:	bug-perl-ldap [...] rt.cpan.org
From:	Uwe Werler <uwe.werler [...] o3si.de>

Hello again, after re-reading of RFC2849 I found that Net::LDAP::LDIF isn't conform to the RFC2849 spec: ldif-file = ldif-content / ldif-changes ldif-content = version-spec 1*(1*SEP ldif-attrval-record) ldif-changes = version-spec 1*(1*SEP ldif-change-record) ldif-attrval-record = dn-spec SEP 1*attrval-spec ldif-change-record = dn-spec SEP *control changerecord This states that a LDIF file must start with 0 or 1 version-specs, then a dn-spec. And, all records must end with LF or CR/LF. Regards Uwe Show quoted text

> ------------------------------------------------------------------------- > Hello, > > after some testing and playing around with Net::LDAP::LDIF and the > back_perl "database" from OpenLDAP I found that some entries will not > be accepted by the latter if I use an entry (or a list of them) > produced by the LDIF module. The cause of this is the "CR" at the > beginning of each entry/DN and the missing empty line at the end. > > I know that this doesn't break RFC2849 and so is not the problem of > Net::LDAP::LDIF. But for compatibility reasons I suggest to print the > "\n" character not before but after each entry. This produces the same > output as by ldapsearch and will be accepted by the perl backend from > OpenLDAP. > > Thanks in advance for Your advices. > > Regards Uwe > >

Sat Apr 05 09:31:47 2008 gbarr [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Sat, 5 Apr 2008 08:27:11 -0500
To:	bug-perl-ldap [...] rt.cpan.org
From:	Graham Barr <gbarr [...] pobox.com>

On Apr 5, 2008, at 3:20 AM, Uwe Werler via RT wrote: Show quoted text

> after re-reading of RFC2849 I found that Net::LDAP::LDIF isn't > conform to the RFC2849 spec:

I disagree. Show quoted text

> ldif-file = ldif-content / ldif-changes > > ldif-content = version-spec 1*(1*SEP ldif-attrval-record)

That shows the SEP (LF or CRLF) before the record, not after it Show quoted text

> ldif-changes = version-spec 1*(1*SEP ldif-change-record) > > ldif-attrval-record = dn-spec SEP 1*attrval-spec

attrval-spec is attrval-spec = AttributeDescription value-spec SEP value-spec = ":" ( FILL 0*1(SAFE-STRING) / ":" FILL (BASE64-STRING) / "<" FILL url) ; See notes 7 and 8, below value-spec does not mention SEP at all, so that SEP in attrval-spec is the end of the attribute line. So not having a blank line after each record, but breo each record, is perfectly correct as per RFC. Show quoted text

> ldif-change-record = dn-spec SEP *control changerecord > > This states that a LDIF file must start with 0 or 1 version-specs, > then > a dn-spec. And, all records must end with LF or CR/LF.

All records from Net::LDAP::LDIF do end with LF, but what you are asking for is an extra LF, but ldif-content clearly shows, by the 1*SEP, that the space between records is defined as being before records, not after them. Graham.

Sat Apr 05 09:32:11 2008 The RT System itself - Status changed from 'new' to 'open'

Sat Apr 05 11:36:43 2008 Uwe.Werler [...] o3si.de - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Sat, 05 Apr 2008 17:35:30 +0200
To:	bug-perl-ldap [...] rt.cpan.org
From:	Uwe Werler <Uwe.Werler [...] o3si.de>

Hallo Graham, thanks for Your reply. But after rereading the RFC again I have now to disagree with You. The RFC says that an LDIF file MUST begin with a version number of 1: Notes on LDIF Syntax 1) For the LDIF format described in this document, the version number MUST be "1". If the version number is absent, implementations MAY choose to interpret the contents as an older LDIF file format, supported by the University of Michigan ldap-3.3 implementation [8]. That means that the first line of the file MUST contain the version spec. Applications MAY accept the file if this line/spec is missing. The line itself is followed by a SEP and by a ldif-attrval-record: ldif-content = version-spec 1*(1*SEP ldif-attrval-record) The ldif-attrval-record itself consists if a dn-spec followed by a SEP and attrval-spec. ldif-attrval-record = dn-spec SEP 1*attrval-spec The attributes itself are described in AttributeDescription followed by the value specification and ENDING with a SEP: attrval-spec = AttributeDescription value-spec SEP That means that the file SHOULD be as followed: version-spec FILL version-number(CR LF / LF) dn-spec FILL distinguishedName(CR LF / LF) AttributeDescription FILL value-spec(CR LF / LF) As example: version: 1(CR LF / LF) dn: distinguishedName(CR LF / LF) attribute: value(CR LF / LF) attribute: value(CR LF / LF) dn: distinguishedName(CR LF / LF) attribute: value(CR LF / LF) attribute: value(CR LF / LF) dn: distinguishedName(CR LF / LF) attribute: value(CR LF / LF) attribute: value(CR LF / LF) and so on. The same applies naturally for the change records. That means if You leave the first line with the version number blank the first line MUST contain an entry starting with a DN. And after each entry MUST be (CR LF / LF) eg. empty line. Thank You for Your attention. Regards Uwe Am Samstag, den 05.04.2008, 09:32 -0400 schrieb Graham Barr via RT: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > > > On Apr 5, 2008, at 3:20 AM, Uwe Werler via RT wrote:

> > after re-reading of RFC2849 I found that Net::LDAP::LDIF isn't > > conform to the RFC2849 spec:

> > I disagree. >

> > ldif-file = ldif-content / ldif-changes > > > > ldif-content = version-spec 1*(1*SEP ldif-attrval-record)

> > That shows the SEP (LF or CRLF) before the record, not after it >

> > ldif-changes = version-spec 1*(1*SEP ldif-change-record) > > > > ldif-attrval-record = dn-spec SEP 1*attrval-spec

> > attrval-spec is > > attrval-spec = AttributeDescription value-spec SEP > > value-spec = ":" ( FILL 0*1(SAFE-STRING) / > ":" FILL (BASE64-STRING) / > "<" FILL url) > ; See notes 7 and 8, below > > value-spec does not mention SEP at all, so that SEP in attrval-spec > is the end of the attribute line. So not having a blank line after > each record, but breo each record, is perfectly correct as per RFC. >

> > ldif-change-record = dn-spec SEP *control changerecord > > > > This states that a LDIF file must start with 0 or 1 version-specs, > > then > > a dn-spec. And, all records must end with LF or CR/LF.

> > All records from Net::LDAP::LDIF do end with LF, but what you are > asking for is an extra LF, but ldif-content clearly shows, by the > 1*SEP, that the space between records is defined as being before > records, not after them. > > Graham. > >

Sat Apr 05 15:52:07 2008 gbarr [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Sat, 5 Apr 2008 14:29:30 -0500
To:	bug-perl-ldap [...] rt.cpan.org
From:	Graham Barr <gbarr [...] pobox.com>

On Apr 5, 2008, at 10:36 AM, Uwe Werler via RT wrote: Show quoted text

> But after rereading the RFC again I have now to disagree with You. The > RFC says that an LDIF file MUST begin with a version number of 1:

No it does not. Show quoted text

> Notes on LDIF Syntax > > 1) For the LDIF format described in this document, the version > number MUST be "1". If the version number is absent, > implementations MAY choose to interpret the contents as an > older LDIF file format, supported by the University of > Michigan ldap-3.3 implementation [8].

It says there that it must for LDIF described by that document. LDIF existed before that document. The existance of the version line is how to tell the difference. Show quoted text

> That means that the first line of the file MUST contain the version > spec. Applications MAY accept the file if this line/spec is missing.

And if you tell NetLLKDAP::LDIF that you want to write version 1 then it will write the version line Show quoted text

> The line itself is followed by a SEP and by a ldif-attrval-record:

The line followed by 1 OR MORE SEP Show quoted text

> > ldif-content = version-spec 1*(1*SEP ldif-attrval-record) > > The ldif-attrval-record itself consists if a dn-spec followed by a SEP > and attrval-spec.

correct Show quoted text

> ldif-attrval-record = dn-spec SEP 1*attrval-spec > > The attributes itself are described in AttributeDescription > followed by > the value specification and ENDING with a SEP:

correct Show quoted text

> attrval-spec = AttributeDescription value-spec SEP > > That means that the file SHOULD be as followed: > > version-spec FILL version-number(CR LF / LF)

There can be more (CR CR/LF) in here Show quoted text

> dn-spec FILL distinguishedName(CR LF / LF) > AttributeDescription FILL value-spec(CR LF / LF) > > As example: > > version: 1(CR LF / LF) > dn: distinguishedName(CR LF / LF) > attribute: value(CR LF / LF) > attribute: value(CR LF / LF) > > dn: distinguishedName(CR LF / LF) > attribute: value(CR LF / LF) > attribute: value(CR LF / LF) > > dn: distinguishedName(CR LF / LF) > attribute: value(CR LF / LF) > attribute: value(CR LF / LF)

With the extra line after the version line, which is legal, that is exactly what Net::LDAP::LDIF will output if you tell it you want version 1 Show quoted text

> and so on. The same applies naturally for the change records. > > That means if You leave the first line with the version number > blank the > first line MUST contain an entry starting with a DN. And after each > entry MUST be (CR LF / LF) eg. empty line.

No. Nowhere in the spec does it say that there MUST be an empty line following each entry. The spec states that each entry is preceeded by 1 or more SEP Graham.

Sat Apr 05 18:12:20 2008 Uwe.Werler [...] o3si.de - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Sun, 06 Apr 2008 00:10:45 +0200
To:	bug-perl-ldap [...] rt.cpan.org
From:	Uwe Werler <Uwe.Werler [...] o3si.de>

Dear Graham, I'm now confused in the interpretation of the RFC. Howard from the OpenLDAP team yetserday answered me: "> The database backend "back_perl" expects LDIF entries beginning with "dn:" and Show quoted text

> ending with an empty line. RFC2849 only describes that an entry is

everything Show quoted text

> except an empty line and a line not beginning (after a CR/LF) with a

single Show quoted text

> white space character.

Wrong. The grammar in RFC2849 quite explicitly states: ldif-file = ldif-content / ldif-changes ldif-content = version-spec 1*(1*SEP ldif-attrval-record) ldif-changes = version-spec 1*(1*SEP ldif-change-record) ldif-attrval-record = dn-spec SEP 1*attrval-spec ldif-change-record = dn-spec SEP *control changerecord That means an LDIF file must start with 0 or 1 version-specs, then a dn-spec. And, all records must end with LF or CR/LF. Show quoted text

> After some testing with back_perl I noticed that the LDIF entries

produced by Show quoted text

> the perl module Net::LDAP::LDIF were not acceptet because they are

beginning Show quoted text

> with an empty line and ending only with a simple CR charakter. > > This behavior breaks RFC2849. After changing LDIF.pm from that module

to produce Show quoted text

> the CR after the entry back_perl accepts this entries too. > > IMHO this is a misbehavior so I'm very glad if You'll take a look at

this Show quoted text

> issue.

Apparently it Net::LDAP::LDIF is broken. Since that is not a piece of OpenLDAP Software I don't see what we can do about it. This ITS will be closed. Contact the author of Net::LDAP::LDIF to pursue this further. --" Who is wrong and who is in right now? To avoid in running problems already solved by newer software releases I installed the actual release of OpenLDAP (2.4.8) and the Net::LDAP::LDIF module (0.35) and I run into the same problematic. I for myself want to understand what's going wrong and how to make my software better and to learn. Because of the differences between the interpretation of the RFC it's very important for me to hear Your opinion again regarding this issue. I'm very glad if You take a look at this. Thanks in advance for Your advice! Regards Uwe Am Samstag, den 05.04.2008, 15:52 -0400 schrieb Graham Barr via RT: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > > > On Apr 5, 2008, at 10:36 AM, Uwe Werler via RT wrote:

> > But after rereading the RFC again I have now to disagree with You. The > > RFC says that an LDIF file MUST begin with a version number of 1:

> > No it does not. >

> > Notes on LDIF Syntax > > > > 1) For the LDIF format described in this document, the version > > number MUST be "1". If the version number is absent, > > implementations MAY choose to interpret the contents as an > > older LDIF file format, supported by the University of > > Michigan ldap-3.3 implementation [8].

> > It says there that it must for LDIF described by that document. > > LDIF existed before that document. The existance of the version line > is how to tell the difference. >

> > That means that the first line of the file MUST contain the version > > spec. Applications MAY accept the file if this line/spec is missing.

> > And if you tell NetLLKDAP::LDIF that you want to write version 1 then > it will write the version line >

> > The line itself is followed by a SEP and by a ldif-attrval-record:

> > The line followed by 1 OR MORE SEP >

> > > > ldif-content = version-spec 1*(1*SEP ldif-attrval-record) > > > > The ldif-attrval-record itself consists if a dn-spec followed by a SEP > > and attrval-spec.

> > correct >

> > ldif-attrval-record = dn-spec SEP 1*attrval-spec > > > > The attributes itself are described in AttributeDescription > > followed by > > the value specification and ENDING with a SEP:

> > correct >

> > attrval-spec = AttributeDescription value-spec SEP > > > > That means that the file SHOULD be as followed: > > > > version-spec FILL version-number(CR LF / LF)

> > There can be more (CR CR/LF) in here >

> > dn-spec FILL distinguishedName(CR LF / LF) > > AttributeDescription FILL value-spec(CR LF / LF) > > > > As example: > > > > version: 1(CR LF / LF) > > dn: distinguishedName(CR LF / LF) > > attribute: value(CR LF / LF) > > attribute: value(CR LF / LF) > > > > dn: distinguishedName(CR LF / LF) > > attribute: value(CR LF / LF) > > attribute: value(CR LF / LF) > > > > dn: distinguishedName(CR LF / LF) > > attribute: value(CR LF / LF) > > attribute: value(CR LF / LF)

> > With the extra line after the version line, which is legal, that is > exactly what Net::LDAP::LDIF will output if you tell it you want > version 1 >

> > and so on. The same applies naturally for the change records. > > > > That means if You leave the first line with the version number > > blank the > > first line MUST contain an entry starting with a DN. And after each > > entry MUST be (CR LF / LF) eg. empty line.

> > No. Nowhere in the spec does it say that there MUST be an empty line > following each entry. The spec states that each entry is preceeded by > 1 or more SEP > > Graham. > >

Sat Apr 05 18:24:07 2008 gbarr [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Sat, 5 Apr 2008 17:22:41 -0500
To:	bug-perl-ldap [...] rt.cpan.org
From:	Graham Barr <gbarr [...] pobox.com>

On Apr 5, 2008, at 5:12 PM, Uwe Werler via RT wrote: Show quoted text

> I'm now confused in the interpretation of the RFC. Howard from the > OpenLDAP team yetserday answered me: > > "> The database backend "back_perl" expects LDIF entries beginning > with > "dn:" and

>> ending with an empty line. RFC2849 only describes that an entry is

> everything

>> except an empty line and a line not beginning (after a CR/LF) with a

> single

>> white space character.

> > Wrong. The grammar in RFC2849 quite explicitly states: > > ldif-file = ldif-content / ldif-changes > > ldif-content = version-spec 1*(1*SEP ldif-attrval-record) > > ldif-changes = version-spec 1*(1*SEP ldif-change-record) > > ldif-attrval-record = dn-spec SEP 1*attrval-spec > > ldif-change-record = dn-spec SEP *control changerecord > > That means an LDIF file must start with 0 or 1 version-specs, then a > dn-spec. > And, all records must end with LF or CR/LF.

He missed here that there can be any number of blank lines between the version-spec and the dn-spec But the issue seems to be you are expecting a blank line after the final entry, eg dn: foobar <SEP > attr: value <SEP > attr: value <SEP > attr: value <SEP > <SEP> There is nothing the the RFC that states that empty line needs to be there attrval-spec = AttributeDescription value-spec SEP And value-spec does not mentoin SEP at all. The SEP in attrval-spec is the SEP at the end of the line Just taking ldif-content as an example ldif-content = version-spec 1*(1*SEP ldif-attrval-record) it states you have a version spec, followed by 1 or more of what is inside the () Inside the () you have 1 or more SEP followed by ldif-attrval-record and the last thing in ldif-attrval-record is attrval-spec So nowhere does it say there must be a blank line *after* the entry If I am misunderstanding your problem then please re-explain Graham.

Sun Apr 06 12:37:12 2008 Uwe.Werler [...] o3si.de - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Sun, 06 Apr 2008 18:35:53 +0200
To:	bug-perl-ldap [...] rt.cpan.org
From:	Uwe Werler <Uwe.Werler [...] o3si.de>

Dear Graham, after some testing again I found the following behaviour in back_perl which I told Howard Chu from the OpenLDAP team: Show quoted text

> Dear Howard, > > after some testing again I determined that back_perl doesn't accept > ldif_entries which are starting with an empty line. Then slapd tells me > "str2entry: entry -1 has no dn". > > Is this behavior correct? If so it will be good to explain in the man > page or the example that an entry should start with a dn line and > shouldn't contain any empty lines nor the version information at the > first line. > > I think that my mistake was to use sample code I've found like this: > > sub search > { > > my $this = shift; > my($base, $scope, $deref, $sizeLim, $timeLim, $filterStr, $attrOnly, @attrs ) = @_; > if (! defined($this->{'LDAP'})) { > $ldap = Net::LDAP->new( 'localhost' ) ; > $this->{'LDAP'} = $ldap; > } > $mesg=$this->{'LDAP'}->search(base=>$base, > scope=>$scope, > deref=>$deref, > sizelimit =>$sizeLim, > timelimit =>$timeLim, > filter =>$filterStr, > attrs=> @attrs ); > > my @list = (); > > > foreach $entry ($mesg->all_entries) { > my $data; > $LDIF = new IO::Scalar \$data; > $dump=Net::LDAP::LDIF->new($LDIF,"w"); > $dump->write($entry); > $LDIF->close; > push @list,$data; > } > return ( 0 , @list); > > } > > Because the entries returned by Net::LDAP::LDIF are starting with a > leading SEP it won't work as is in back_perl. > > Thank You very much for Your attention. > > Regards Uwe

The problem with an empty line after the entries was my mistake because I used "^$" as field separator in reading the output file in my test code ;-) Your implementation of the RFC is quite correct. Sorry that this took some time before I understood the RFC. Because I used the sample code above I didn't notice that back_perl expects the entries only and not a ldif file. Thank You very much for Your help and advices! Regards Uwe

Mon Apr 07 07:48:55 2008 Uwe.Werler [...] o3si.de - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Mon, 07 Apr 2008 13:45:40 +0200
To:	bug-perl-ldap [...] rt.cpan.org
From:	Uwe Werler <Uwe.Werler [...] o3si.de>

Hello Graham, there is indeed a misbehavior in Net::LDAP::LDIF when the version line is not chosen to be printed (which is the default) because then the entries are starting with a SEP that should not occur. ldif-content = version-spec 1*(1*SEP ldif-attrval-record) This rule states that at least one SEP MUST be AFTER the version-spec. If You only want to print an entry without the version-spec then this rule applies: ldif-attrval-record = dn-spec SEP 1*attrval-spec That means that a ldif file (entry) MUST start with the dn-spec without any leading SEP (blank line). Regards Uwe

Mon Apr 07 11:13:03 2008 gbarr [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Mon, 7 Apr 2008 10:12:32 -0500
To:	bug-perl-ldap [...] rt.cpan.org
From:	Graham Barr <gbarr [...] pobox.com>

On Apr 7, 2008, at 6:48 AM, Uwe Werler via RT wrote: Show quoted text

> > Queue: perl-ldap > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > > > Hello Graham, > > there is indeed a misbehavior in Net::LDAP::LDIF when the version line > is not chosen to be printed (which is the default) because then the > entries are starting with a SEP that should not occur. > > ldif-content = version-spec 1*(1*SEP ldif-attrval-record) > > This rule states that at least one SEP MUST be AFTER the version-spec. > If You only want to print an entry without the version-spec then this > rule applies: > > ldif-attrval-record = dn-spec SEP 1*attrval-spec > > That means that a ldif file (entry) MUST start with the dn-spec > without > any leading SEP (blank line).

No. that RFC describes version 1 which must have the line. If the version 1 is not there is is not covered by that RFC. Graham.

Mon Apr 07 12:37:11 2008 Uwe.Werler [...] o3si.de - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Mon, 07 Apr 2008 18:36:46 +0200
To:	bug-perl-ldap [...] rt.cpan.org
From:	Uwe Werler <Uwe.Werler [...] o3si.de>

Hello Graham, but what is when You leave out the version-spec and You only want to print entries? Than You haven't a valid ldif? And a file starting with a blank line couldn't be standard. Regards Uwe Am Montag, den 07.04.2008, 11:13 -0400 schrieb Graham Barr via RT: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > > > On Apr 7, 2008, at 6:48 AM, Uwe Werler via RT wrote:

> > > > Queue: perl-ldap > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > > > > > Hello Graham, > > > > there is indeed a misbehavior in Net::LDAP::LDIF when the version line > > is not chosen to be printed (which is the default) because then the > > entries are starting with a SEP that should not occur. > > > > ldif-content = version-spec 1*(1*SEP ldif-attrval-record) > > > > This rule states that at least one SEP MUST be AFTER the version-spec. > > If You only want to print an entry without the version-spec then this > > rule applies: > > > > ldif-attrval-record = dn-spec SEP 1*attrval-spec > > > > That means that a ldif file (entry) MUST start with the dn-spec > > without > > any leading SEP (blank line).

> > No. that RFC describes version 1 which must have the line. If the > version 1 is not there is is not covered by that RFC. > > Graham. > >

Mon Apr 07 13:08:26 2008 gbarr [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Mon, 7 Apr 2008 11:42:44 -0500
To:	bug-perl-ldap [...] rt.cpan.org
From:	Graham Barr <gbarr [...] pobox.com>

On Apr 7, 2008, at 11:37 AM, Uwe Werler via RT wrote: Show quoted text

> > Queue: perl-ldap > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > > > Hello Graham, > > but what is when You leave out the version-spec and You only want to > print entries? Than You haven't a valid ldif? And a file starting > with a > blank line couldn't be standard.

No it is not standard to that RFC, that RFC describes version 1, and without the version line it is not version 1. Not having the version line is there for compatibility for old software that was written before that RFC. Graham. Show quoted text

> > Regards Uwe > > Am Montag, den 07.04.2008, 11:13 -0400 schrieb Graham Barr via RT:

>> <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > >> >> On Apr 7, 2008, at 6:48 AM, Uwe Werler via RT wrote:

>>> >>> Queue: perl-ldap >>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > >>> >>> Hello Graham, >>> >>> there is indeed a misbehavior in Net::LDAP::LDIF when the version >>> line >>> is not chosen to be printed (which is the default) because then the >>> entries are starting with a SEP that should not occur. >>> >>> ldif-content = version-spec 1*(1*SEP ldif-attrval- >>> record) >>> >>> This rule states that at least one SEP MUST be AFTER the version- >>> spec. >>> If You only want to print an entry without the version-spec then >>> this >>> rule applies: >>> >>> ldif-attrval-record = dn-spec SEP 1*attrval-spec >>> >>> That means that a ldif file (entry) MUST start with the dn-spec >>> without >>> any leading SEP (blank line).

>> >> No. that RFC describes version 1 which must have the line. If the >> version 1 is not there is is not covered by that RFC. >> >> Graham. >> >>

> >

Mon Apr 07 13:54:35 2008 Uwe.Werler [...] o3si.de - Correspondence added

Subject:	Re: [rt.cpan.org #34689] suggestion for the position of CR character in Net::LDAP::LDIF entry
Date:	Mon, 07 Apr 2008 19:54:15 +0200
To:	bug-perl-ldap [...] rt.cpan.org
From:	Uwe Werler <Uwe.Werler [...] o3si.de>

Hello Graham, thank You very much for Your help and advices. I solved my problem with simple deleting the leading SEP from the LDIF output. Yes, You are right! I think the problem is how the output without the version-spec is interpreted by an entry parser. The back_perl from OpenLDAP doesn't accept correct ldif stated by RFC because it's not producing correct output when the version-spec is returned too. It only accepts "ldif like" entries without a leading SEP. Sadly Howard from the OpenLDAP people ignores my suggestion to explain this clearly in the man page or at least example code shipped within the sources. The output from Net::LDAP::LDIF is correct because of RFC's rule: "version-spec 1*(1*SEP ldif-attrval-record)" which evidently describes the leading SEP. I thank You again for the time consuming discussion! Regards Uwe PS: At least I learnt how to interpret the RFC ;-) Am Montag, den 07.04.2008, 13:08 -0400 schrieb Graham Barr via RT: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > > > > On Apr 7, 2008, at 11:37 AM, Uwe Werler via RT wrote:

> > > > Queue: perl-ldap > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > > > > > Hello Graham, > > > > but what is when You leave out the version-spec and You only want to > > print entries? Than You haven't a valid ldif? And a file starting > > with a > > blank line couldn't be standard.

> > No it is not standard to that RFC, that RFC describes version 1, and > without the version line it is not version 1. > > Not having the version line is there for compatibility for old > software that was written before that RFC. > > Graham.

Thu Mar 11 21:38:33 2010 GBARR [...] CPAN.ORG - Status changed from 'open' to 'resolved'