From ldapext-bounces@ietf.org Sun Jun 03 14:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuvBs-0003bX-Cy; Sun, 03 Jun 2007 14:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuvBq-0003bQ-OY for ldapext@ietf.org; Sun, 03 Jun 2007 14:52:34 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuvBp-00049n-Ex for ldapext@ietf.org; Sun, 03 Jun 2007 14:52:34 -0400 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HuvBo-0003RM-Jc for ldapext@ietf.org; Sun, 03 Jun 2007 20:52:32 +0200 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx2.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HuvBo-0003oM-6U for ldapext@ietf.org; Sun, 03 Jun 2007 20:52:32 +0200 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HuvBo-0005kL-1l for ldapext@ietf.org; Sun, 03 Jun 2007 20:52:32 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Sun, 03 Jun 2007 20:52:32 +0200 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.2, required=12.0, autolearn=disabled, AWL=0.756, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 8CDFDCD2A8CB82D52412F5537CA1552DC86D7E4D X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -41 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 321 max/h 5 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [ldapext] OS-dependent LDIF 'attr:< file://filename' handling X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org How do LDAP implementations handle "attr:< file:///foo/bar" on non-Unix filesystems? If the file is opened in binary mode, the value may get zero-padded at the end (to fill a complete block in the filesystem). But if it is opened in text mode, end-of-line markers in the file will be replaced with LF, a byte which is handled like an end-of-file marker (like ^Z on windows) will truncate the file, and on some types of filesystems spaces at the end of lines may be removed. I suppose servers could ignore trailing zero-bytes in attribute values if that would fix a syntax error when parsing the value... Or we could define 'attr:<< URL' or something to mean the URL provides base64-encoded data. -- Regards, Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Jun 03 17:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huy3R-0003Je-AK; Sun, 03 Jun 2007 17:56:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huy3P-0003Dy-FW for ldapext@ietf.org; Sun, 03 Jun 2007 17:56:03 -0400 Received: from 36-9-124-83.dsl.3u.net ([83.124.9.36] helo=mstroeder.homeip.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huy3O-0006Lx-4o for ldapext@ietf.org; Sun, 03 Jun 2007 17:56:03 -0400 Received: from localhost (localhost [127.0.0.1]) by mstroeder.homeip.net (Postfix) with ESMTP id 6D67C6E91; Sun, 3 Jun 2007 23:56:00 +0200 (CEST) Received: from mstroeder.homeip.net ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29517-02; Sun, 3 Jun 2007 23:55:55 +0200 (CEST) Received: from mstroeder.homeip.net (localhost [127.0.0.1]) by mstroeder.homeip.net (Postfix) with SMTP id 084BE65C2; Sun, 3 Jun 2007 23:55:54 +0200 (CEST) Message-ID: <6754bb7b8c9cc44e66b246d6f93a9f84@stroeder.com> Date: Sun, 3 Jun 2007 23:55:55 +0200 From: =?UTF-8?B?Ik1pY2hhZWwgU3Ryw7ZkZXIi?= Subject: Re: [ldapext] OS-dependent LDIF 'attr:< file://filename' handling To: Hallvard B Furuseth In-Reply-To: References: X-Mailer: hastymail 1.5 x-priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: amavisd-new at int.stroeder.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michael@stroeder.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On 8:52:32 pm 2007-06-03 Hallvard B Furuseth wrote: > How do LDAP implementations handle "attr:< file:///foo/bar" on > non-Unix filesystems? > > If the file is opened in binary mode, the value may get zero-padded at > the end (to fill a complete block in the filesystem). I don't understand the problem. The OS takes care of it. Could you please give an example of an OS which returns zero-padded data to an application when opening a file in binary mode? > But if it is opened in text mode, I'd never do this. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Jun 03 23:30:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv3Gs-0003gQ-Lp; Sun, 03 Jun 2007 23:30:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv3Gr-0003gI-6R for ldapext@ietf.org; Sun, 03 Jun 2007 23:30:17 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv3Gp-0005mn-Tl for ldapext@ietf.org; Sun, 03 Jun 2007 23:30:17 -0400 Received: from [192.168.1.100] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 4 Jun 2007 04:30:13 +0100 X-SMTP-Protocol-Errors: NORDNS In-Reply-To: References: Message-Id: <12DB2B1D-C75C-40AE-9672-ECFB5191A236@Isode.com> From: Kurt Zeilenga Subject: Re: [ldapext] OS-dependent LDIF 'attr:< file://filename' handling Date: Sun, 3 Jun 2007 20:30:06 -0700 To: Hallvard B Furuseth X-Mailer: Apple Mail (2.752.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Jun 3, 2007, at 11:52 AM, Hallvard B Furuseth wrote: > How do LDAP implementations handle "attr:< file:///foo/bar" on non- > Unix > filesystems? RFC 2849 says: The contents of the referenced file are to be included verbatim in the interpreted output of the LDIF file. > If the file is opened in binary mode If by "binary mode", you mean some mode in causes the content to be processed without translation, then that would seem like the right thing for an LDIF parser to do. -- Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 04 07:22:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvAdc-0006f2-7i; Mon, 04 Jun 2007 07:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvAda-0006Uw-H6 for ldapext@ietf.org; Mon, 04 Jun 2007 07:22:14 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvAdZ-00083n-71 for ldapext@ietf.org; Mon, 04 Jun 2007 07:22:14 -0400 Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HvAdY-0000ev-HL; Mon, 04 Jun 2007 13:22:12 +0200 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx9.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HvAdX-00053s-R5; Mon, 04 Jun 2007 13:22:12 +0200 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HvAdT-00041K-GS; Mon, 04 Jun 2007 13:22:07 +0200 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: Date: Mon, 4 Jun 2007 13:22:07 +0200 To: Subject: Re: [ldapext] OS-dependent LDIF 'attr:< file://filename' handling In-Reply-To: <6754bb7b8c9cc44e66b246d6f93a9f84@stroeder.com> References: <6754bb7b8c9cc44e66b246d6f93a9f84@stroeder.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.2, required=12.0, autolearn=disabled, AWL=0.776, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 9C22F4EFC67933B112225F8481F5E56B894F1252 X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -41 maxlevel 200 minaction 0 bait 0 mail/h: 1 total 322 max/h 5 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Michael Str=F6der writes: >On 8:52:32 pm 2007-06-03 Hallvard B Furuseth >wrote: >> How do LDAP implementations handle "attr:< file:///foo/bar" on >> non-Unix filesystems=3F >> >> If the file is opened in binary mode, the value may get zero-padded >> at the end (to fill a complete block in the filesystem). > > I don't understand the problem. The OS takes care of it. If it can. There are or have been filesystems where file sizes are not stored in number of bytes but number of blocks. That's why ^Z was needed in text files on DOS or whatever - to get better granularity than blocks it needed a character to work like an EOF mark. (There are other kinds of filesystems or file types - e.g. files with fixed-length records instead of streams of bytes. When used for text files, they might use one record per line and space-pad it, hence the "space may be removed at the end of lines in text files".) > Could you please give an example of an OS which returns zero-padded > data to an application when opening a file in binary mode=3F Me=3F No. Well, DOS if I remember that example correctly. But I'm a Unix person, which is why I asked about non-Unix. >> But if it is opened in text mode, > > I'd never do this. That's a relief:-) --=20 Regards, Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 04 07:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBAU-0004dn-Qb; Mon, 04 Jun 2007 07:56:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBAS-0004dO-KB for ldapext@ietf.org; Mon, 04 Jun 2007 07:56:12 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvBAQ-0004qC-74 for ldapext@ietf.org; Mon, 04 Jun 2007 07:56:12 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l54Bv6KV002710; Mon, 4 Jun 2007 06:57:06 -0500 Message-ID: <4663FDD8.1030208@highlandsun.com> Date: Mon, 04 Jun 2007 04:56:08 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.9a5pre) Gecko/20070530 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: Hallvard B Furuseth Subject: Re: [ldapext] OS-dependent LDIF 'attr:< file://filename' handling References: <6754bb7b8c9cc44e66b246d6f93a9f84@stroeder.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by highlandsun.propagation.net id l54Bv6KV002710 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ldapext@ietf.org, michael@stroeder.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Hallvard B Furuseth wrote: > Michael Str=F6der writes: >> On 8:52:32 pm 2007-06-03 Hallvard B Furuseth >> wrote: >>> How do LDAP implementations handle "attr:< file:///foo/bar" on >>> non-Unix filesystems? >>> >>> If the file is opened in binary mode, the value may get zero-padded >>> at the end (to fill a complete block in the filesystem). >> I don't understand the problem. The OS takes care of it. >=20 > If it can. There are or have been filesystems where file sizes are > not stored in number of bytes but number of blocks. That's why ^Z was > needed in text files on DOS or whatever - to get better granularity > than blocks it needed a character to work like an EOF mark. >=20 > (There are other kinds of filesystems or file types - e.g. files with > fixed-length records instead of streams of bytes. When used for text > files, they might use one record per line and space-pad it, hence > the "space may be removed at the end of lines in text files".) >=20 >> Could you please give an example of an OS which returns zero-padded >> data to an application when opening a file in binary mode? >=20 > Me? No. Well, DOS if I remember that example correctly. But I'm a > Unix person, which is why I asked about non-Unix. >=20 >>> But if it is opened in text mode, >> I'd never do this. >=20 > That's a relief:-) >=20 Well, there's two possibilities here - on those oddball systems, either=20 a solution exists, or it doesn't. Any system that can't provide binary=20 byte-stream file semantics is going to have trouble with all kinds of=20 URLs in all kinds of software, not just LDAP. As for DOS - that EOF marker isn't actually needed, since the directory=20 structure records file sizes in bytes. Just a holdover from DOS 1.x or=20 somesuch (CP/M perhaps?). re: record-oriented files - mainframes have a great variety of these. It=20 seems the file: URL syntax doesn't accommodate these details, so anyone=20 trying to use those files as anything other than a byte-stream is SOL. A=20 bit of a shame, but then again, they have other utilities available for=20 repacking a structured file into a byte-stream if necessary. Having=20 implemented structured file support in FTP for our mainframes a couple=20 decades ago, and seeing how few other systems cared, I'd say it's no=20 great loss. re: fixed-length records for text - that would be pretty unusual since=20 OS's with record-oriented files always provide both variable and fixed=20 options. Anybody who deliberately chose to use a fixed-length format for=20 text already knows there will be pad bytes, and probably expects them to=20 be propagated. Really it doesn't seem that any of this is worth worrying=20 about. --=20 -- 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/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 04 10:05:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDBA-0004xE-Tq; Mon, 04 Jun 2007 10:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDB9-0004x3-ED for ldapext@ietf.org; Mon, 04 Jun 2007 10:05:03 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvDB8-0001U9-3f for ldapext@ietf.org; Mon, 04 Jun 2007 10:05:03 -0400 Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HvDB6-0006tj-Ja; Mon, 04 Jun 2007 16:05:00 +0200 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx5.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HvDB5-0000xw-NS; Mon, 04 Jun 2007 16:05:00 +0200 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HvDB5-000533-CM; Mon, 04 Jun 2007 16:04:59 +0200 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Mon, 4 Jun 2007 16:04:59 +0200 To: Howard Chu Subject: Re: [ldapext] OS-dependent LDIF 'attr:< file://filename' handling In-Reply-To: <4663FDD8.1030208@highlandsun.com> References: <6754bb7b8c9cc44e66b246d6f93a9f84@stroeder.com> <4663FDD8.1030208@highlandsun.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.6, required=12.0, autolearn=disabled, AWL=0.433, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 94E4995D33EC48AFA0EB36A9F8791E8A88A98BAE X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -45 maxlevel 200 minaction 0 bait 0 mail/h: 1 total 323 max/h 5 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ldapext@ietf.org, michael@stroeder.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Howard Chu writes: > Well, there's two possibilities here - on those oddball systems, > either a solution exists, or it doesn't. Any system that can't provide > binary byte-stream file semantics is going to have trouble with all > kinds of URLs in all kinds of software, not just LDAP. Well, they'd need to maintain such info about their URLs in separate files instead of having the filesystem take care of it. And a local fix could be to implement some other URL scheme than file:// - one which knows of those separate files. > As for DOS - that EOF marker isn't actually needed, since the directory > structure records file sizes in bytes. Just a holdover from DOS 1.x or > somesuch (CP/M perhaps?). I guss I'll survive without porting full LDIF to CP/M:-) > re: record-oriented files - mainframes have a great variety of > these. (...) Having implemented structured file support in FTP for our > mainframes a couple decades ago, and seeing how few other systems > cared, I'd say it's no great loss. That's good. For me this is all mostly a theoretical concern. Living almost purely in a Unix word I didn't know how much it was a practical concern somewhere as well. -- Regards, Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext