From yves@zioup.com Sat Mar 21 00:31:24 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886DD3A6AE6 for ; Sat, 21 Mar 2009 00:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbDBb+jj-hnt for ; Sat, 21 Mar 2009 00:31:23 -0700 (PDT) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by core3.amsl.com (Postfix) with ESMTP id 736F63A6ABA for ; Sat, 21 Mar 2009 00:31:23 -0700 (PDT) Received: from pd7ml1no-ssvc.prod.shaw.ca ([10.0.153.161]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 21 Mar 2009 01:32:10 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=J6b0bBEkAAAA:8 a=ka6OHc2Xp9yHgCD4J5cA:9 a=SYNMtFUqoGRPnw7ZjlMA:7 a=dM3bhYhE9GyoZPJdspamM5WkTmUA:4 a=xZWt0H8d2RIA:10 Received: from s0106003018a62844.cg.shawcable.net (HELO home.zioup.com) ([68.147.37.46]) by pd7ml1no-dmz.prod.shaw.ca with ESMTP; 21 Mar 2009 01:32:10 -0600 Received: from [192.168.2.51] (r51.zioup.net [192.168.2.51]) by home.zioup.com (Postfix) with ESMTP id 6790A350BF; Sat, 21 Mar 2009 01:32:10 -0600 (MDT) Message-ID: <49C497F9.7010200@zioup.com> Date: Sat, 21 Mar 2009 01:32:09 -0600 From: Yves Dorfsman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ldapext@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey.melnikov@isode.com Subject: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 07:31:24 -0000 Hi, I'd like to re-start this thread. I have been re-reading the earlier messages, and have put some thought into it as well. I have also been communicating with the RFC-editor and Alexey Melnikov (one of the Area Directors for LDAP). I have also taken a stab at the new text to jumpstart the discussion. Scope: I personally would prefer to address the UTF-8 support only, and possibly other minor issues, but no other major change. My reasoning is that: -the change is relatively simple -the lack of UTF-8 support is a problem that affects me directly -I understand the problem -adding other major functionalities will probably delay the RFC, while we could get this one out relatively fast, while working on the other functionalities for another version. Alexey said that he'd like to have all the options on the table. Version scheme: Last year I wrote that the version number is limited to one digit. That was a mistake, I re-read RFC 2234 (the specification of Backus-Naur Form), and what is in the current RFC is one digit or more, so this is a non-issue. Escaping UTF-8 characters: RFC 2253 (UTF-8 String Representation of Distinguished Names ) allows for escaping characters with backslashes and hex numbers. I can see the point when working from the command line, and say your terminal is not set properly, or you don't have the appropriate keyboard, but I am not sure about files... What do you guys think ? Authorship: I have tried to contact Gordon Good, the original author of RFC 2849, but have not heard from him yet (could be due to spam filters). The RFC-Editor and Alexey say there are procedures around that, and we can leave that as a last minute item. Example in UTF-8: The RFC-Editor is very clear on this, RFCs are ASCII only but we can add a postscript file with examples containing UTF-8 if we want. I am not sure there is much value, this is pretty trivial. Removing some paragraphs: Should we remove some paragraph that don't seem to be relevant any more, such as: " The application/directory MIME content-type [RFC2425] is a general framework and format for conveying directory information, and is independent of any particular directory service. The LDIF format is a simpler format which is perhaps easier to create, and may also be used, as noted, to describe a set of changes to be applied to a directory. " Expired draft: Refence [Armijo00] is a draft expired in 2001. It is used in example 7. Is this still relevant ? RFC4525: I noticed that RFC 4525 has updated the LDIF definition. Should this be included in this RFC ? I have created an extra file with its inclusion. Here are the two versions I have created: http://www.sollers.ca/hg/ldif-utf8/file/d307d875966f/proposal.txt#l1 and a side by side diff: http://www.sollers.ca/projects/ldif-utf8/files/proposal-diff.html and with the addition of rfc 4525: http://www.sollers.ca/hg/ldif-utf8/file/213f3b5dcd86/proposal.txt#l1 side by side diff: http://www.sollers.ca/projects/ldif-utf8/files/rfc4525addon.html -- Yves. http://www.sollers.ca/ From kurt.zeilenga@isode.com Sat Mar 21 13:29:45 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C629B3A6989 for ; Sat, 21 Mar 2009 13:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogf3toGQxqhE for ; Sat, 21 Mar 2009 13:29:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5ED533A68B0 for ; Sat, 21 Mar 2009 13:29:44 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 21 Mar 2009 20:30:30 +0000 X-SMTP-Protocol-Errors: NORDNS Message-Id: From: Kurt Zeilenga To: Yves Dorfsman In-Reply-To: <49C497F9.7010200@zioup.com> Date: Sat, 21 Mar 2009 13:30:27 -0700 References: <49C497F9.7010200@zioup.com> X-Mailer: Apple Mail (2.930.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: alexey.melnikov@isode.com, ldapext@ietf.org Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 20:29:45 -0000 On Mar 21, 2009, at 12:32 AM, Yves Dorfsman wrote: > > Hi, > > I'd like to re-start this thread. > > I have been re-reading the earlier messages, and have put some > thought into it as well. I have also been communicating with the RFC- > editor and Alexey Melnikov (one of the Area Directors for LDAP). I > have also taken a stab at the new text to jumpstart the discussion. > > > Scope: > I personally would prefer to address the UTF-8 support only, and > possibly other minor issues, but no other major change. My view is that I rather not suffer the pain of updating the LDIF format multiple times, and certainly rather not suffer significant pain for just minor change. Also, I might note that adding just UTF-8 is not totally a minor change, there are a few oddities to consider. For instance, what would be allows for end-of-line characters? Would we use Net-UTF8? (I hope not as Net-UTF8 implies normalization and that goes against interchanging arbitrary sequences of Unicode code points.) LDIF primary purpose is for interchange of directory data. Just adding UTF-8 support doesn't allow for any additional interchange of information. The UTF-8 change is for secondary purposes, to allow humans to more easily see what they are interchanging, to allow humans to directly modify the LDIF. I rather spend my time on adding features that do allow for the a interchange of more directory data. Also LDIF ought to have similar extensibility as LDAP itself has. > My reasoning is that: > -the change is relatively simple > -the lack of UTF-8 support is a problem that affects me directly > -I understand the problem > -adding other major functionalities will probably delay the RFC, > while we could get this one out relatively fast, while working on > the other functionalities for another version. > > Alexey said that he'd like to have all the options on the table. Other items include (this is not intended to be exhaustive, I suspect others have more items): Extending LDIF to support all LDAP requests, e.g., an LDAP Transaction Extending LDIF to support all LDAP responses, e.g., Entries, References, Intermediate Responses, and Result returned in response to an LDAP Search request. Extending LDIF to support XML values. There were also suggestions of adding a "charset" specification (yuk). > > > > Version scheme: > Last year I wrote that the version number is limited to one digit. > That was a mistake, I re-read RFC 2234 (the specification of Backus- > Naur Form), and what is in the current RFC is one digit or more, so > this is a non-issue. This, I think, is an error. Generally errors should be fixed when revising a document. > > > > Escaping UTF-8 characters: > RFC 2253 (UTF-8 String Representation of Distinguished Names > ) allows for escaping characters with backslashes and hex numbers. I > can see the point when working from the command line, and say your > terminal is not set properly, or you don't have the appropriate > keyboard, but I am not sure about files... What do you guys think ? I rather avoid adding escaping. > Authorship: > I have tried to contact Gordon Good, the original author of RFC 2849, > but have not heard from him yet (could be due to spam filters). The > RFC-Editor and Alexey say there are procedures around that, and we > can leave that as a last minute item. A non-issue. > Example in UTF-8: > The RFC-Editor is very clear on this, RFCs are ASCII only but we can > add a postscript file with examples containing UTF-8 if we want. I > am not sure there is much value, this is pretty trivial. (Though I rather the IETF would change the RFC format from ASCII to UTF-8, that's another fight.) There are various conventions for providing examples of UTF-8 protocols (and formats). IIRC, there's an RFC about how this (though I don't recall its number). And I think at least once such example ought to be included. > > > Removing some paragraphs: > Should we remove some paragraph that don't seem to be relevant any > more, such as: > " The application/directory MIME content-type [RFC2425] is a general > framework and format for conveying directory information, and is > independent of any particular directory service. The LDIF format is > a simpler format which is perhaps easier to create, and may also be > used, as noted, to describe a set of changes to be applied to a > directory. > " I would oppose removing this text. Any replacement of the LDIF specification needs to consider the impact on use of LDIF in MIME encoded contents of the application/directory type. > > > > Expired draft: > Refence [Armijo00] is a draft expired in 2001. It is used in example > 7. Is this still relevant ? The revised document should provide more relevant examples. In particular, examples should use standard track controls. So this (informative) reference ought to be replaced accordingly based upon which standard track controls are used in examples. > RFC4525: > I noticed that RFC 4525 has updated the LDIF definition. Should this > be included in this RFC ? Yes, as LDIFv1 is formally RFC 2829 as updated by RFC 4525 (that's what UPDATES means). > I have created an extra file with its inclusion. > > > Here are the two versions I have created: > http://www.sollers.ca/hg/ldif-utf8/file/d307d875966f/proposal.txt#l1 > and a side by side diff: > http://www.sollers.ca/projects/ldif-utf8/files/proposal-diff.html > > and with the addition of rfc 4525: > http://www.sollers.ca/hg/ldif-utf8/file/213f3b5dcd86/proposal.txt#l1 > side by side diff: > http://www.sollers.ca/projects/ldif-utf8/files/rfc4525addon.html > > > -- > Yves. > http://www.sollers.ca/ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From velo27@yahoo.com Sun Mar 22 22:04:18 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E853A67B5 for ; Sun, 22 Mar 2009 22:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kwwkiLatBUg for ; Sun, 22 Mar 2009 22:04:18 -0700 (PDT) Received: from web30806.mail.mud.yahoo.com (web30806.mail.mud.yahoo.com [68.142.200.149]) by core3.amsl.com (Postfix) with SMTP id EE59D3A67A7 for ; Sun, 22 Mar 2009 22:04:17 -0700 (PDT) Received: (qmail 53291 invoked by uid 60001); 23 Mar 2009 05:05:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237784707; bh=Ls0i0ieSYmyaiDv97uq+94LpLCNyz2o5bkHRaOAHmPU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=N55IR+nqC7PrObyYm2PtSbCweYttG4i5ml0+/S0X2q2HSPHR/IRg2WbaBP3Cou0C36Dbj0/0WsrCs89GNh3pSZijl7QnqB/4nciyDXN2r4125vtnNuDrmTJuwS9INLcrBa+8C45vKpfzbUjOPfMTFk1n6jVSSB7pxxJ2JUTafyM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=upG+KqPu3cZNG0lw1AYcAPZWGEvz7+W1eRql08mgZ75Rz7SZan5m0neQfGfgrWaHJVm+btOKOW3fi1SkzXlL5rlZMjwUn+NGKcyAk+tL9kgcCOaxQBqk9nz/vxPiRmevY7duP/JsUYhtLPhtGCINe2BhTqccQp+EsHKJmdk/zK0=; Message-ID: <500912.51493.qm@web30806.mail.mud.yahoo.com> X-YMail-OSG: JiNR2MgVM1lNzyBIjOgszs2yS9DZijs36ZD8xqhehWKmrjiPnpg3dGWVV_vgXBOwA.fRFLkkQHEWi7s2SN_J3FZ_ewOMq_lRFeSOgsy8rXWnD8ytwuRhoRJUsjlQYW7Fm4TezjRbc_XU2Yp_QVb9O6Dahve1aQCQyR_i01QGXMDuzfaMXyah1RhOFqRW6dim6NZZPK00.kCf4QT6o.IKa6G. Received: from [70.137.174.225] by web30806.mail.mud.yahoo.com via HTTP; Sun, 22 Mar 2009 22:05:07 PDT X-Mailer: YahooMailRC/1277.32 YahooMailWebService/0.7.289.1 References: Date: Sun, 22 Mar 2009 22:05:07 -0700 (PDT) From: Gordon Good To: ldapext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1310282398-1237784707=:51493" X-Mailman-Approved-At: Mon, 23 Mar 2009 06:47:20 -0700 Subject: Re: [ldapext] Ldapext Digest, Vol 51, Issue 2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 05:14:07 -0000 --0-1310282398-1237784707=:51493 Content-Type: text/plain; charset=us-ascii Apologies to anyone who has tried to contact me re: the LDIF RFC. The best way to contact me is at my new work email address: gordon.good@hp.com If someone is prepared to take over ownership of the LDIF RFC, I would appreciate that. Time allowing, I would like to remain involved in any discussions, but please don't make me a bottleneck for any further revisions. Thanks, -Gordon --0-1310282398-1237784707=:51493 Content-Type: text/html; charset=us-ascii

Apologies to anyone who has tried to contact me re: the LDIF RFC. The best way to contact me is at my new work email address:

gordon.good@hp.com

If someone is prepared to take over ownership of the LDIF RFC, I would appreciate that. Time allowing, I would like to remain involved in any discussions, but please don't make me a bottleneck for any further revisions.

Thanks,

-Gordon
--0-1310282398-1237784707=:51493-- From yves@zioup.com Mon Mar 23 22:33:10 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762C13A683E for ; Mon, 23 Mar 2009 22:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWFJxqgJUmN0 for ; Mon, 23 Mar 2009 22:33:09 -0700 (PDT) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by core3.amsl.com (Postfix) with ESMTP id 1A44C3A67D2 for ; Mon, 23 Mar 2009 22:33:08 -0700 (PDT) Received: from pd3ml1so-ssvc.prod.shaw.ca ([10.0.141.140]) by pd4mo1so-svcs.prod.shaw.ca with ESMTP; 23 Mar 2009 23:33:59 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=J6b0bBEkAAAA:8 a=brndo9mAWbQjJBi6OXUA:9 a=b_IxycpU_T4wLRPtb2EA:7 a=TZ9qtEM08FoO4x2Ltw7ELwrchjgA:4 a=WPV3hXSGBlIA:10 a=Cguc0gE-TcEA:10 Received: from s0106003018a62844.cg.shawcable.net (HELO home.zioup.com) ([68.147.37.46]) by pd3ml1so-dmz.prod.shaw.ca with ESMTP; 23 Mar 2009 23:33:59 -0600 Received: from [192.168.2.51] (r51.zioup.net [192.168.2.51]) by home.zioup.com (Postfix) with ESMTP id C9072350BF; Mon, 23 Mar 2009 23:33:58 -0600 (MDT) Message-ID: <49C870C6.4010803@zioup.com> Date: Mon, 23 Mar 2009 23:33:58 -0600 From: Yves Dorfsman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ldapext@ietf.org References: <49C497F9.7010200@zioup.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey.melnikov@isode.com Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 05:33:10 -0000 Kurt Zeilenga wrote: >> >> I personally would prefer to address the UTF-8 support only, and >> possibly other minor issues, but no other major change. > > > My view is that I rather not suffer the pain of updating the LDIF format > multiple times, and certainly rather not suffer significant pain for > just minor change. I like the idea of addressing one change at a time. You address that one, and spend all the time and energy on making sure you got it right, then when that's done, you move on to the next... > Also, I might note that adding just UTF-8 is not totally a minor change, > there are a few oddities to consider. For instance, what would be > allows for end-of-line characters? Would we use Net-UTF8? (I hope not > as Net-UTF8 implies normalization and that goes against interchanging > arbitrary sequences of Unicode code points.) Agreed, this is not minor, what I meant was I'd like to do UTF-8 + *possibly* other minor changes, but I would rather not do UTF-8 + other major changes. Sorry if I wasn't clear. Having said that, if we get to a consensus on other changes that we can add to my changes, or even if somebody wants to take my proposition and add other change to it, I'm fine with that. My issue is UTF-8, that's what drove me here, that's what I want to be fixed. > LDIF primary purpose is for interchange of directory data. Just adding > UTF-8 support doesn't allow for any additional interchange of > information. The UTF-8 change is for secondary purposes, to allow > humans to more easily see what they are interchanging, to allow humans > to directly modify the LDIF. Good point, but UTF-8 sure helps for debugging ! Diffing base64 is completely useless. Also you could argue that the beauty of LDIF is its simplicity for humans. If we don't care about that aspect, we could completely give up LDIF, and go with something more complex like an XML format, or even a binary one. > I rather spend my time on adding features that do allow for the a > interchange of more directory data. Also LDIF ought to have similar > extensibility as LDAP itself has. Let's start a list, and see who wants what in/out... > Extending LDIF to support all LDAP requests, e.g., an LDAP Transaction > Extending LDIF to support all LDAP responses, e.g., Entries, References, > Intermediate Responses, and Result returned in response to an LDAP > Search request. > Extending LDIF to support XML values. Really ? > There were also suggestions of adding a "charset" specification (yuk). Is there something we cannot do with Unicode ? I don't understand the advantage of a "charset" keyword. If anything, I'd rather look at an "encoding" keyword to support the different encodings of Unicode, for east asian scripts for example which apparently takes a lot less space when encoded in UTF-16. But, UTF-16 in itself is quite a bit more complex than UTF-8, requiring a byte order mark etc... I was thinking this could wait a future version. >> Version scheme: >> Last year I wrote that the version number is limited to one digit. >> That was a mistake, I re-read RFC 2234 (the specification of >> Backus-Naur Form), and what is in the current RFC is one digit or >> more, so this is a non-issue. > > This, I think, is an error. Generally errors should be fixed when > revising a document. No, *I* am the one who made a mistake, there is nothing wrong with the current spec. for the version number, back in december, I thought there was, but I was wrong. It's a non-issue. >> >> Escaping UTF-8 characters: >> RFC 2253 (UTF-8 String Representation of Distinguished Names >> ) allows for escaping characters with backslashes and hex numbers. I >> can see the point when working from the command line, and say your >> terminal is not set properly, or you don't have the appropriate >> keyboard, but I am not sure about files... What do you guys think ? > > I rather avoid adding escaping. Agreed, I'd just like to confirm this isn't a personal bias. > A non-issue. > >> Example in UTF-8: >> The RFC-Editor is very clear on this, RFCs are ASCII only but we can >> add a postscript file with examples containing UTF-8 if we want. I am >> not sure there is much value, this is pretty trivial. > > (Though I rather the IETF would change the RFC format from ASCII to > UTF-8, that's another fight.) No kidding. > > There are various conventions for providing examples of UTF-8 protocols > (and formats). IIRC, there's an RFC about how this (though I don't > recall its number). And I think at least once such example ought to be > included. Yes, I believe you need to add a PDF or PS version to the original. I can look at that. Is there a tradition on how to pick the names for the example, or is it completely random ? >> Removing some paragraphs: >> Should we remove some paragraph that don't seem to be relevant any >> more, such as: >> " The application/directory MIME content-type [RFC2425] is a general >> framework and format for conveying directory information, and is >> independent of any particular directory service. The LDIF format is >> a simpler format which is perhaps easier to create, and may also be >> used, as noted, to describe a set of changes to be applied to a >> directory. >> " > > I would oppose removing this text. Any replacement of the LDIF > specification needs to consider the impact on use of LDIF in MIME > encoded contents of the application/directory type. It seems to me that this paragraph is giving historical information and justifying some of the reasons behind LDIF... Am I wrong here. If I am making an error and it's worth keeping, than that's fine. >> Expired draft: >> Refence [Armijo00] is a draft expired in 2001. It is used in example >> 7. Is this still relevant ? > > The revised document should provide more relevant examples. In > particular, examples should use standard track controls. So this > (informative) reference ought to be replaced accordingly based upon > which standard track controls are used in examples. I could not find any new version of this document, of a replacement for it. As this just become standard practice ? Or is there a written standard for it ? >> RFC4525: >> I noticed that RFC 4525 has updated the LDIF definition. Should this >> be included in this RFC ? > > Yes, as LDIFv1 is formally RFC 2829 as updated by RFC 4525 (that's what > UPDATES means). > >> I have created an extra file with its inclusion. Ok. I'll just merge the two files an drepost then. -- Yves. http://www.sollers.ca/ From alexey.melnikov@isode.com Tue Mar 24 16:03:51 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A243A6CEA for ; Tue, 24 Mar 2009 16:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM-9MOBz2Tay for ; Tue, 24 Mar 2009 16:03:50 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2A6D33A6D44 for ; Tue, 24 Mar 2009 16:03:13 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 24 Mar 2009 23:04:03 +0000 Message-ID: <49C966C7.6060200@isode.com> Date: Tue, 24 Mar 2009 16:03:35 -0700 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Yves Dorfsman References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> In-Reply-To: <49C870C6.4010803@zioup.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:03:51 -0000 Yves Dorfsman wrote: > Kurt Zeilenga wrote: [...] >> There were also suggestions of adding a "charset" specification (yuk). > > Is there something we cannot do with Unicode ? I don't understand the > advantage of a "charset" keyword. If anything, I'd rather look at an > "encoding" keyword to support the different encodings of Unicode, for > east asian scripts for example which apparently takes a lot less space > when encoded in UTF-16. But, UTF-16 in itself is quite a bit more > complex than UTF-8, requiring a byte order mark etc... I was thinking > this could wait a future version. I think Unicode is pretty much won the charset war and UTF-8 would be the best thing to use. But I think Kurt was just mentioning this as an idea that was suggested. Just my 2p (as an individual contributor). [...] >>> Example in UTF-8: >>> The RFC-Editor is very clear on this, RFCs are ASCII only but we can >>> add a postscript file with examples containing UTF-8 if we want. I >>> am not sure there is much value, this is pretty trivial. >> >> (Though I rather the IETF would change the RFC format from ASCII to >> UTF-8, that's another fight.) > > No kidding. Another debate for another place and time ;-) >> There are various conventions for providing examples of UTF-8 >> protocols (and formats). IIRC, there's an RFC about how this (though >> I don't recall its number). And I think at least once such example >> ought to be included. > > Yes, I believe you need to add a PDF or PS version to the original. I > can look at that. Is there a tradition on how to pick the names for > the example, or is it completely random ? There is no tradition, you are free to use whatever you like. [...] From Kurt.Zeilenga@Isode.com Tue Mar 24 17:04:08 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8092828C143 for ; Tue, 24 Mar 2009 17:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JHulxOj4OzY for ; Tue, 24 Mar 2009 17:04:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CE6F83A695D for ; Tue, 24 Mar 2009 17:04:06 -0700 (PDT) Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 25 Mar 2009 00:04:57 +0000 Message-Id: From: Kurt Zeilenga To: Yves Dorfsman In-Reply-To: <49C870C6.4010803@zioup.com> Date: Tue, 24 Mar 2009 17:04:51 -0700 References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> X-Mailer: Apple Mail (2.930.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: alexey.melnikov@isode.com, ldapext@ietf.org Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:04:08 -0000 On Mar 23, 2009, at 10:33 PM, Yves Dorfsman wrote: >> LDIF primary purpose is for interchange of directory data. Just >> adding UTF-8 support doesn't allow for any additional interchange >> of information. The UTF-8 change is for secondary purposes, to >> allow humans to more easily see what they are interchanging, to >> allow humans to directly modify the LDIF. > > Good point, but UTF-8 sure helps for debugging ! Diffing base64 is > completely useless. > > Also you could argue that the beauty of LDIF is its simplicity for > humans. If we don't care about that aspect, we could completely give > up LDIF, and go with something more complex like an XML format, or > even a binary one. One of the problems with using UTF-8 directly is that the UTF-8 form used within the human's editor might be quite different that the UTF-8 form the human desires to store in the directory. Or the human's editor cannot display any and all sequences of UTF-8 characters, some of which might not even be well-formed text, as stored in the directory. There are other issues, such as how to deal with BIDI values. While I am sure there are persons in the IETF that have the expertise to get a UTF-8 LDIF right, I am quite unsure of time/energy/ willingness to contribute to this effort. > >> I rather spend my time on adding features that do allow for the a >> interchange of more directory data. Also LDIF ought to have >> similar extensibility as LDAP itself has. > > Let's start a list, and see who wants what in/out... > > > >> Extending LDIF to support all LDAP requests, e.g., an LDAP >> Transaction > >> Extending LDIF to support all LDAP responses, e.g., Entries, >> References, Intermediate Responses, and Result returned in response >> to an LDAP Search request. > >> Extending LDIF to support XML values. > > Really ? See http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt > > > >> There were also suggestions of adding a "charset" specification >> (yuk). > > Is there something we cannot do with Unicode ? I don't understand > the advantage of a "charset" keyword. If anything, I'd rather look > at an "encoding" keyword to support the different encodings of > Unicode, for east asian scripts for example which apparently takes a > lot less space when encoded in UTF-16. But, UTF-16 in itself is > quite a bit more complex than UTF-8, requiring a byte order mark > etc... I was thinking this could wait a future version. As Alexey noted, I was only listing what someone else suggesting. I don't support adding a charset option. > > Yes, I believe you need to add a PDF or PS version to the original. > I can look at that. Is there a tradition on how to pick the names > for the example, or is it completely random ? I think the ASCII I-D/RFC needs to have examples that use some sort of escaping mechanism (for the purposes of the example) value: \C3\BC where C3 BC is the 2 octet UTF-8 encoding of the Unicode LATIN SMALL LETTER U WITH DIAERESIS (U+00FC) codepoint. value: \75\CC\88 where 75 is the 1 octet UTF-8 encoding of Unicode LATIN SMALL LETTER U (0075) codepoint and CC 88 is the 2 octet UTF-8 encoding of the Unicode COMBINING DIAERESIS (0308) codepoint. Note: The hex escaping above is used only for illustration purposes. The LDIF content should contain the actual UTF-8 encoded Unicode codepoints. The PDF/PS version would not use the escaping. > > >>> Removing some paragraphs: >>> Should we remove some paragraph that don't seem to be relevant any >>> more, such as: >>> " The application/directory MIME content-type [RFC2425] is a >>> general >>> framework and format for conveying directory information, and is >>> independent of any particular directory service. The LDIF format >>> is >>> a simpler format which is perhaps easier to create, and may also be >>> used, as noted, to describe a set of changes to be applied to a >>> directory. >>> " >> I would oppose removing this text. Any replacement of the LDIF >> specification needs to consider the impact on use of LDIF in MIME >> encoded contents of the application/directory type. > > It seems to me that this paragraph is giving historical information > and justifying some of the reasons behind LDIF... Am I wrong here. > > If I am making an error and it's worth keeping, than that's fine. > >>> Expired draft: >>> Refence [Armijo00] is a draft expired in 2001. It is used in >>> example 7. Is this still relevant ? >> The revised document should provide more relevant examples. In >> particular, examples should use standard track controls. So this >> (informative) reference ought to be replaced accordingly based upon >> which standard track controls are used in examples. > > I could not find any new version of this document, of a replacement > for it. As this just become standard practice ? Or is there a > written standard for it ? My point is that this example should be replaced with one that uses a standard track control, such as the LDAP Assertion Control [RFC4528]. > > > >>> RFC4525: >>> I noticed that RFC 4525 has updated the LDIF definition. Should >>> this be included in this RFC ? >> Yes, as LDIFv1 is formally RFC 2829 as updated by RFC 4525 (that's >> what UPDATES means). >>> I have created an extra file with its inclusion. > > Ok. I'll just merge the two files an drepost then. > > > > > -- > Yves. > http://www.sollers.ca/ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From Kurt.Zeilenga@Isode.com Tue Mar 24 18:58:12 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678813A6A31 for ; Tue, 24 Mar 2009 18:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qyoa-jy+q0Tw for ; Tue, 24 Mar 2009 18:58:11 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EBCDE3A6984 for ; Tue, 24 Mar 2009 18:57:54 -0700 (PDT) Received: from dhcp-55e7.meeting.ietf.org ((unknown) [130.129.85.231]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 25 Mar 2009 01:58:45 +0000 X-SMTP-Protocol-Errors: NORDNS Message-Id: <742B8D74-4CA4-4905-9A75-689BD07B7F59@Isode.com> From: Kurt Zeilenga To: Yves Dorfsman In-Reply-To: <49C870C6.4010803@zioup.com> Date: Tue, 24 Mar 2009 18:58:42 -0700 References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> X-Mailer: Apple Mail (2.930.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: alexey.melnikov@isode.com, ldapext@ietf.org Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:58:12 -0000 After thinking about this some more I've come to the conclusion that the best one could do with UTF-8 and LDIF is to allow the value to contain any (but a few) code points. The file might not be always well-formed text, and hence may not always be displayable. I do not think it feasible to create an LDIF representing arbitrary Unicode attribute values using a off-the-shelf Unicode-aware text editor. For instance, you could have one value that requires composed characters but the editor only produces decomposed characters, or vice versa. I note my intent is not to discourage you from putting a draft together. I'm just concerned that the result might not adequately address the issue of concern. I suggest you be try to describe the problem you are trying to solve in the I-D. Regards, Kurt From yves@zioup.com Wed Mar 25 22:13:20 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E803A68FC for ; Wed, 25 Mar 2009 22:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iEXXG2CLtW6 for ; Wed, 25 Mar 2009 22:13:19 -0700 (PDT) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by core3.amsl.com (Postfix) with ESMTP id 59DD43A68ED for ; Wed, 25 Mar 2009 22:13:19 -0700 (PDT) Received: from pd2ml2so-ssvc.prod.shaw.ca ([10.0.141.134]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 25 Mar 2009 23:14:12 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=J6b0bBEkAAAA:8 a=h2DjcvEd9-YcQElFRisA:9 a=5F6ssnTe-G0ayOLhg_6A88cgdEIA:4 a=WPV3hXSGBlIA:10 a=Cguc0gE-TcEA:10 Received: from s0106003018a62844.cg.shawcable.net (HELO home.zioup.com) ([68.147.37.46]) by pd2ml2so-dmz.prod.shaw.ca with ESMTP; 25 Mar 2009 23:14:12 -0600 Received: from [192.168.2.51] (r51.zioup.net [192.168.2.51]) by home.zioup.com (Postfix) with ESMTP id 01868350BF for ; Wed, 25 Mar 2009 23:14:11 -0600 (MDT) Message-ID: <49CB0F22.6090902@zioup.com> Date: Wed, 25 Mar 2009 23:14:10 -0600 From: Yves Dorfsman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ldapext@ietf.org References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49C966C7.6060200@isode.com> In-Reply-To: <49C966C7.6060200@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:13:20 -0000 Alexey Melnikov wrote: > >>> There were also suggestions of adding a "charset" specification (yuk). >> >> Is there something we cannot do with Unicode ? I don't understand the >> advantage of a "charset" keyword. If anything, I'd rather look at an > > I think Unicode is pretty much won the charset war and UTF-8 would be > the best thing to use. > But I think Kurt was just mentioning this as an idea that was suggested. I went back through the mailing list archive, "charset" came up, but I can't make sense of who started with it. Assuming we go ahead with UTF-8, does anybody here have a problem with NOT implementing "charset", to use Unicode / UTF-8 only ? >> Yes, I believe you need to add a PDF or PS version to the original. I >> can look at that. Is there a tradition on how to pick the names for >> the example, or is it completely random ? > > There is no tradition, you are free to use whatever you like. Thanks. -- Yves. http://www.sollers.ca/ From yves@zioup.com Wed Mar 25 22:48:12 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A233A6DEA for ; Wed, 25 Mar 2009 22:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb6zufykz2qO for ; Wed, 25 Mar 2009 22:48:11 -0700 (PDT) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by core3.amsl.com (Postfix) with ESMTP id 6E6D43A67D4 for ; Wed, 25 Mar 2009 22:47:49 -0700 (PDT) Received: from pd2ml2so-ssvc.prod.shaw.ca ([10.0.141.134]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 25 Mar 2009 23:48:42 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=J6b0bBEkAAAA:8 a=tU1zZqpQVwfR6sU-CDoA:9 a=T14sn68se_Ys1IReiKzeH8LDYgEA:4 a=fE8fE_rqo-4A:10 a=WPV3hXSGBlIA:10 a=Cguc0gE-TcEA:10 Received: from s0106003018a62844.cg.shawcable.net (HELO home.zioup.com) ([68.147.37.46]) by pd2ml2so-dmz.prod.shaw.ca with ESMTP; 25 Mar 2009 23:48:42 -0600 Received: from [192.168.2.51] (r51.zioup.net [192.168.2.51]) by home.zioup.com (Postfix) with ESMTP id CF31B350BF for ; Wed, 25 Mar 2009 23:48:41 -0600 (MDT) Message-ID: <49CB1739.5040807@zioup.com> Date: Wed, 25 Mar 2009 23:48:41 -0600 From: Yves Dorfsman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ldapext@ietf.org References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <742B8D74-4CA4-4905-9A75-689BD07B7F59@Isode.com> In-Reply-To: <742B8D74-4CA4-4905-9A75-689BD07B7F59@Isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:48:12 -0000 Kurt Zeilenga wrote: > I note my intent is not to discourage you from putting a draft > together. I'm just concerned that the result might not adequately > address the issue of concern. I suggest you be try to describe the > problem you are trying to solve in the I-D. Thanks Kurt, I actually appreciate that you come up with these issues, as I had not thought of them all. This also makes me think that we should really focus on UTF-8 only for this revision, and make sure we look at all the angles. > After thinking about this some more I've come to the conclusion that the > best one could do with UTF-8 and LDIF is to allow the value to contain > any (but a few) code points. The file might not be always well-formed > text, and hence may not always be displayable. I do not think it > feasible to create an LDIF representing arbitrary Unicode attribute > values using a off-the-shelf Unicode-aware text editor. For instance, > you could have one value that requires composed characters but the > editor only produces decomposed characters, or vice versa. I really do think the issue here has to do with editors, and to a certain extent, ldap client. But then, I expect the people who have a need for these characters will be equiped with the right software. I have just tried to import these two LDIF entries (at separate time) into openldap: ################################################################## ## Ali Baba dn:: Y2492LnZhNmKINio2KfYqNinLG91PVBlb3BsZSxkYz16aW91cCxkYz1jb20= cn:: 2LnZhNmKINio2KfYqNin givenName:: 2KjYp9io2Kc= objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson rfc822Mailbox: Ali.Baba@zioup.com sn:: 2LnZhNmK ################################################################## dn: cn=علي بابا,ou=People,dc=zioup,dc=com cn: علي بابا givenName: علي objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson rfc822Mailbox: Ali.Baba@zioup.com sn: بابا ################################################################## I then accessed openldap with Mozilla Thunderbird, and in both cases, Thunderbird displayed the name properly, from right to left. Note that the vim editor displays the arabic characters from left to right (wrong, there might be a way to make vim work, but it's not the issue here), and the gnome editor gedit displays them from right to left, so properly (openldap is happy to import non base64 encoded characters, but it follows the RFC in a strict manner when exporting and base64 encode those). I have not looked at composed characters yet, but will. If we leave the editor issue on the side, is there any reason why UTF-8 would give us problems ? LDAP itself supports UTF-8, has there be any problem with it ? If anybody has a more practical experience with bidirectional and composed characters in LDAP, I'd appreciate their help to do some more testing. -- Yves. http://www.sollers.ca/ From yves@zioup.com Wed Mar 25 22:56:11 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43DC3A6DE7 for ; Wed, 25 Mar 2009 22:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=1.232, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJYUephpYjRe for ; Wed, 25 Mar 2009 22:56:11 -0700 (PDT) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by core3.amsl.com (Postfix) with ESMTP id D7C913A6DE6 for ; Wed, 25 Mar 2009 22:56:10 -0700 (PDT) Received: from pd7ml1no-ssvc.prod.shaw.ca ([10.0.153.161]) by pd6mo1no-svcs.prod.shaw.ca with ESMTP; 25 Mar 2009 23:57:03 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=563Ur-DeAAAA:8 a=J6b0bBEkAAAA:8 a=UZIawXk5JxOnzc5kEoYA:9 a=IIeROlvXLyjyMKGuljvZuEky4u0A:4 a=WPV3hXSGBlIA:10 a=Cguc0gE-TcEA:10 Received: from s0106003018a62844.cg.shawcable.net (HELO home.zioup.com) ([68.147.37.46]) by pd7ml1no-dmz.prod.shaw.ca with ESMTP; 25 Mar 2009 23:57:03 -0600 Received: from [192.168.2.51] (r51.zioup.net [192.168.2.51]) by home.zioup.com (Postfix) with ESMTP id 02FCE350BF for ; Wed, 25 Mar 2009 23:57:02 -0600 (MDT) Message-ID: <49CB192E.5050105@zioup.com> Date: Wed, 25 Mar 2009 23:57:02 -0600 From: Yves Dorfsman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ldapext@ietf.org References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:56:11 -0000 Kurt Zeilenga wrote: >> >>> Extending LDIF to support XML values. >> >> Really ? > > See http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt > Interesting, I think this is a valid issue, although I think XML is the wrong solution. Any reason why the draft never made it to an RFC ? What other solutions could be used to make multi-line entries ? Would quoting a la python work, or would that add too much complexity, too much of a change from the current LDIF ? > I think the ASCII I-D/RFC needs to have examples that use some sort of > escaping mechanism (for the purposes of the example) > > value: \C3\BC > > where C3 BC is the 2 octet UTF-8 encoding of the Unicode LATIN SMALL > LETTER U WITH DIAERESIS (U+00FC) codepoint. > > value: \75\CC\88 > Thanks, I'll look at that. Anybody knows of an RFC that use something like this in their example, from the top of your head ? -- Yves. http://www.sollers.ca/ From steven.legg@eb2bcom.com Wed Mar 25 23:30:05 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388E63A6DF2 for ; Wed, 25 Mar 2009 23:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HOST_EQ_STATIC=1.172, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TbMaoYWwp5f for ; Wed, 25 Mar 2009 23:30:04 -0700 (PDT) Received: from eb2bcom.com (165.203.232.72.static.reverse.ltdomains.com [72.232.203.165]) by core3.amsl.com (Postfix) with ESMTP id 35BB33A6DEF for ; Wed, 25 Mar 2009 23:30:04 -0700 (PDT) Received: from eth3065.vic.adsl.internode.on.net ([150.101.156.248] helo=[192.168.1.182]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lmj7C-0006sS-8F; Thu, 26 Mar 2009 17:30:58 +1100 Message-ID: <49CB211C.6070108@eb2bcom.com> Date: Thu, 26 Mar 2009 17:30:52 +1100 From: Steven Legg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Yves Dorfsman References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49CB192E.5050105@zioup.com> In-Reply-To: <49CB192E.5050105@zioup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Cc: ldapext@ietf.org Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 06:30:05 -0000 Hi Yves, Yves Dorfsman wrote: > Kurt Zeilenga wrote: > >>> >>>> Extending LDIF to support XML values. >>> >>> Really ? >> >> See http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt >> > > Interesting, I think this is a valid issue, although I think XML is the > wrong solution. We created a solution for presenting directory attribute values that are arbitrary UTF-8 character strings including line breaks. That accommodates UTF-8 encoded XML documents, but would also be useful for GSER encodings if the whitespace separator is extended to include line breaks. > Any reason why the draft never made it to an RFC ? It may yet. We've just been busy with other things and there hasn't been external pressure to move it along. > > What other solutions could be used to make multi-line entries ? Escaping the line break characters in the value and using the existing LDIF line folding method would work. The output function can optionally fold lines immediately after an escaped line break so that the number of lines in the value matches the number of lines in the LDIF output. Another solution is to drop into a literal mode until a special character sequence is encountered (e.g., END-OF-VALUE). One must then take care to escape the special sequence if it happens to occur in the attribute value. Both of the above solutions require messing about with escape sequences, whereas the simple prefix method we settled on doesn't need to. > Would quoting a la python work, or would that add too much complexity, > too much of a change from the current LDIF ? Can you present an example of what you mean ? Regards, Steven > > > >> I think the ASCII I-D/RFC needs to have examples that use some sort of >> escaping mechanism (for the purposes of the example) >> >> value: \C3\BC >> >> where C3 BC is the 2 octet UTF-8 encoding of the Unicode LATIN >> SMALL LETTER U WITH DIAERESIS (U+00FC) codepoint. >> >> value: \75\CC\88 >> > > Thanks, I'll look at that. Anybody knows of an RFC that use something > like this in their example, from the top of your head ? > From Ludovic.Poitou@Sun.COM Thu Mar 26 03:03:12 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC363A6BB0 for ; Thu, 26 Mar 2009 03:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7NuNIOsXVD8 for ; Thu, 26 Mar 2009 03:03:11 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id AA7D03A6BC8 for ; Thu, 26 Mar 2009 03:02:54 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2QA3ebm007248 for ; Thu, 26 Mar 2009 10:03:44 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cvBIQ9qKZL4jJ2JhJqtG0w)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH300G00W0K5J00@fe-emea-09.sun.com> for ldapext@ietf.org; Thu, 26 Mar 2009 10:03:40 +0000 (GMT) Received: from dhcp-egnb07-211-59.France.Sun.COM ([unknown] [129.157.211.59]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH3001MEYM30VG0@fe-emea-09.sun.com>; Thu, 26 Mar 2009 10:03:39 +0000 (GMT) Date: Thu, 26 Mar 2009 11:03:39 +0100 From: Ludovic Poitou In-reply-to: <49CB0F22.6090902@zioup.com> Sender: Ludovic.Poitou@Sun.COM To: Yves Dorfsman Message-id: X-Mailer: Apple Mail (2.930.3) References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49C966C7.6060200@isode.com> <49CB0F22.6090902@zioup.com> Cc: ldapext@ietf.org Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 10:03:12 -0000 --Boundary_(ID_cvBIQ9qKZL4jJ2JhJqtG0w) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT On Mar 26, 2009, at 6:14 AM, Yves Dorfsman wrote: > Alexey Melnikov wrote: >>>> There were also suggestions of adding a "charset" specification >>>> (yuk). >>> >>> Is there something we cannot do with Unicode ? I don't understand >>> the advantage of a "charset" keyword. If anything, I'd rather look >>> at an >> I think Unicode is pretty much won the charset war and UTF-8 would >> be the best thing to use. >> But I think Kurt was just mentioning this as an idea that was >> suggested. > > I went back through the mailing list archive, "charset" came up, but > I can't make sense of who started with it. I probably did. In europe there are lots of directory users and administrators that have non ascii data they need to transform to LDIF. With simple scripts, turning the data to UTF-8 and then to base64 encoded is a pain. Allowing to specify a charset and then letting the tools doing the conversion to UTF-8 automatically could simplify their life. I think this is getting less of an issue with modern desktops and OS, even though UTF-8 is not the default setting for a machine in French or German. > Assuming we go ahead with UTF-8, does anybody here have a problem > with NOT implementing "charset", to use Unicode / UTF-8 only ? No problem. Ludovic. > > >>> Yes, I believe you need to add a PDF or PS version to the >>> original. I can look at that. Is there a tradition on how to pick >>> the names for the example, or is it completely random ? >> There is no tradition, you are free to use whatever you like. > > Thanks. > > -- > Yves. > http://www.sollers.ca/ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext --- Ludovic Poitou Sun Microsystems Inc. OpenDS Community Lead Directory Services http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --Boundary_(ID_cvBIQ9qKZL4jJ2JhJqtG0w) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE
On Mar 26, 20= 09, at 6:14 AM, Yves Dorfsman wrote:

Alexey Melnikov wrote:
There were also suggestions of adding a "charset" specifica= tion (yuk).

Is there something = we cannot do with Unicode ? I don't understand the advantage of a "ch= arset" keyword. If anything, I'd rather look at an
<= /blockquote>
I think Unicode is pretty much = won the charset war and UTF-8 would be the best thing to use.
But I think Kurt was just mentioni= ng this as an idea that was suggested.

I went bac= k through the mailing list archive, "charset" came up, but I can't ma= ke sense of who started with it.

I probably did.
In europe there are lots of directory us= ers and administrators that have non ascii data they need to transfor= m to LDIF.
With simple scripts, turning the data to UTF-8 a= nd then to base64 encoded is a pain.
Allowing to specify a = charset and then letting the tools doing the conversion to UTF-8 auto= matically could simplify their life.

I think= this is getting less of an issue with modern desktops and OS, even t= hough UTF-8 is not the default setting for a machine in French or Ger= man.

Assuming we g= o ahead with UTF-8, does anybody here have a problem with NOT impleme= nting "charset", to use Unicode / UTF-8 only ?
No problem.

Ludovic.



Yes, I believe you need to add a PDF or PS version to the o= riginal. I can look at that. Is there a tradition on how to pick the = names for the example, or is it completely random ?
<= /blockquote>
There is no tradition, you are = free to use whatever you like.

Thanks.

-- =
Yves.
http://www.sollers.ca= /

_______________________________________________
Ldape= xt mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/l= istinfo/ldapext

---
Ludovic Poitou        &n= bsp;                   &= nbsp;       Sun Microsystems Inc.
OpenDS Community Lead           &= nbsp;   Directory Services         &nbs= p;
h= ttp://blogs.sun.com/Ludo/&n= bsp;        Grenoble Engineering Center - France

Sun Microsystems requ= ires the following notice:
~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  = ;This email message is for the sole use of the intended
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">recipient(s) and may contain confidential and pri= vileged information.
Any unauthorized revie= w, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the = sender by
reply email and destroy all copie= s of the original message.
~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





=
--Boundary_(ID_cvBIQ9qKZL4jJ2JhJqtG0w)-- From jim@willeke.com Thu Mar 26 04:35:00 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD9B3A67F9 for ; Thu, 26 Mar 2009 04:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hRZy613M9RB for ; Thu, 26 Mar 2009 04:34:59 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 9E67F3A6403 for ; Thu, 26 Mar 2009 04:34:59 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so474861qwb.31 for ; Thu, 26 Mar 2009 04:35:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.94.148 with SMTP id z20mr84275qcm.106.1238067352564; Thu, 26 Mar 2009 04:35:52 -0700 (PDT) In-Reply-To: References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49C966C7.6060200@isode.com> <49CB0F22.6090902@zioup.com> Date: Thu, 26 Mar 2009 07:35:52 -0400 Message-ID: From: Jim Willeke To: ldapext@ietf.org Content-Type: multipart/alternative; boundary=001636426b39c2045f046604043f Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 11:35:00 -0000 --001636426b39c2045f046604043f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Is the suggestion to utilize and indicator similar to the HTTP charset parameter (Content-Type: text/html; charset=utf-8) ? -jim Jim Willeke 2009/3/26 Ludovic Poitou > > On Mar 26, 2009, at 6:14 AM, Yves Dorfsman wrote: > > Alexey Melnikov wrote: > > There were also suggestions of adding a "charset" specification (yuk). > > > Is there something we cannot do with Unicode ? I don't understand the > advantage of a "charset" keyword. If anything, I'd rather look at an > > I think Unicode is pretty much won the charset war and UTF-8 would be the > best thing to use. > > But I think Kurt was just mentioning this as an idea that was suggested. > > > I went back through the mailing list archive, "charset" came up, but I > can't make sense of who started with it. > > > I probably did. > In europe there are lots of directory users and administrators that have > non ascii data they need to transform to LDIF. > With simple scripts, turning the data to UTF-8 and then to base64 encoded > is a pain. > Allowing to specify a charset and then letting the tools doing the > conversion to UTF-8 automatically could simplify their life. > > I think this is getting less of an issue with modern desktops and OS, even > though UTF-8 is not the default setting for a machine in French or German. > > Assuming we go ahead with UTF-8, does anybody here have a problem with NOT > implementing "charset", to use Unicode / UTF-8 only ? > > No problem. > > Ludovic. > > > > Yes, I believe you need to add a PDF or PS version to the original. I can > look at that. Is there a tradition on how to pick the names for the example, > or is it completely random ? > > There is no tradition, you are free to use whatever you like. > > > Thanks. > > -- > Yves. > http://www.sollers.ca/ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > > > --- > Ludovic Poitou Sun Microsystems Inc. > OpenDS Community Lead Directory Services > http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France > > Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest > > Sun Microsystems requires the following notice: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > > --001636426b39c2045f046604043f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is the suggestion to utilize and indicator similar to the HTTP charset para= meter (Content-Type: text/html; charset=3Dutf-8) ?

-ji= m
Jim Willeke


2009/3/26 Ludovic Poitou <Ludovic.Poitou@sun.com= >

On Mar 26, 2009, at 6:14 AM, Yves Dorfsman wr= ote:

Alexey Melnikov wrote:
T= here were also suggestions of adding a "charset" specification (y= uk).

Is there something we cannot do with Unicode ? I don= 't understand the advantage of a "charset" keyword. If anythi= ng, I'd rather look at an
I think Unicode is pret= ty much won the charset war and UTF-8 would be the best thing to use.
But I think Kurt was just mentioning t= his as an idea that was suggested.

I went back through the mailing list archive, "charse= t" came up, but I can't make sense of who started with it.
<= /blockquote>

I probably did.
In europe there a= re lots of directory users and administrators that have non ascii data they= need to transform to LDIF.
With simple scripts, turning the data to UTF-8 and then to base64 enco= ded is a pain.
Allowing to specify a charset and then letting the= tools doing the conversion to UTF-8 automatically could simplify their lif= e.

I think this is getting less of an issue with modern de= sktops and OS, even though UTF-8 is not the default setting for a machine i= n French or German.

Assu= ming we go ahead with UTF-8, does anybody here have a problem with NOT impl= ementing "charset", to use Unicode / UTF-8 only ?
No problem.

Ludovic.



Yes, I believe you need to add a PDF or PS version to the ori= ginal. I can look at that. Is there a tradition on how to pick the names fo= r the example, or is it completely random ?
There is no tradition, = you are free to use whatever you like.

Thanks.

-= -
Yves.
http://= www.sollers.ca/

_______________________________________________
Ldapext mailing list=
Ldapext@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/ldapext

---
Ludovic Po= itou=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0Sun Microsystems Inc.
OpenDS Community = Lead =A0 =A0 =A0 =A0 =A0 =A0 =A0 Directory Services=A0=A0 =A0 =A0 =A0 =A0
http://blogs.sun.com/Ludo/=A0=A0 =A0 =A0 =A0=A0Grenoble Engineering Center - France

Sun= Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<= /div>
NOTICE:=A0=A0This email message is= for the sole use of the intended
recipien= t(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please= contact the sender by
reply email and des= troy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~

<= br>





_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext


--001636426b39c2045f046604043f-- From yves@zioup.com Thu Mar 26 06:37:12 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E68A3A6A37 for ; Thu, 26 Mar 2009 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaaSKQ64n-NF for ; Thu, 26 Mar 2009 06:37:11 -0700 (PDT) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by core3.amsl.com (Postfix) with ESMTP id C8AC53A6842 for ; Thu, 26 Mar 2009 06:37:11 -0700 (PDT) Received: from pd2ml1so-ssvc.prod.shaw.ca ([10.0.141.139]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 26 Mar 2009 07:38:04 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=J6b0bBEkAAAA:8 a=gr555eMo7Z_d0NxxiRoA:9 a=W6PQfhsllSYVJUJ8DQ99hRAoDlcA:4 a=WPV3hXSGBlIA:10 a=Cguc0gE-TcEA:10 Received: from s0106003018a62844.cg.shawcable.net (HELO home.zioup.com) ([68.147.37.46]) by pd2ml1so-dmz.prod.shaw.ca with ESMTP; 26 Mar 2009 07:38:04 -0600 Received: from [192.168.2.51] (r51.zioup.net [192.168.2.51]) by home.zioup.com (Postfix) with ESMTP id A2739350BF for ; Thu, 26 Mar 2009 07:38:04 -0600 (MDT) Message-ID: <49CB853C.10108@zioup.com> Date: Thu, 26 Mar 2009 07:38:04 -0600 From: Yves Dorfsman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ldapext@ietf.org References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49C966C7.6060200@isode.com> <49CB0F22.6090902@zioup.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 13:37:12 -0000 Jim Willeke wrote: > Is the suggestion to utilize and indicator similar to the HTTP charset > parameter (Content-Type: text/html; charset=utf-8) ? I don't think we ever got it that well defined, but I guess, yes this would be one way of doing it. I still think it is a bad idea. It make sense for http, because most html out there, even today, is not UTF-8, the migration is happening, but it has not happened. On the other hand, UTF-8 has been supported by LDAP for a long time, and is typically the default. As a matter of fact, LDIF already uses UTF-8 by default today, but the issue is that it has to be base64 encoded. Jim: Do you have specific cases where using non-Unicode charsets would be an asset ? PS: As mentioned earlier, I could see value in adding "encoding:" if it means an encoding of Unicode, but we need to keep in mind that the other encodings are more complicated to implement. -- Yves. http://www.sollers.ca/ From yves@zioup.com Thu Mar 26 06:48:58 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45C43A68E6 for ; Thu, 26 Mar 2009 06:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b1ViTCyMXYW for ; Thu, 26 Mar 2009 06:48:58 -0700 (PDT) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by core3.amsl.com (Postfix) with ESMTP id 176603A6842 for ; Thu, 26 Mar 2009 06:48:57 -0700 (PDT) Received: from pd7ml1no-ssvc.prod.shaw.ca ([10.0.153.161]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 26 Mar 2009 07:49:51 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=563Ur-DeAAAA:8 a=J6b0bBEkAAAA:8 a=LyQ_CXbeES_JHIjd4vEA:9 a=_pGSHbZ_mZ3ipyxWtjEA:7 a=o9lkeXWfDoJypzSDH5eebLTs2GUA:4 a=WPV3hXSGBlIA:10 a=Cguc0gE-TcEA:10 Received: from s0106003018a62844.cg.shawcable.net (HELO home.zioup.com) ([68.147.37.46]) by pd7ml1no-dmz.prod.shaw.ca with ESMTP; 26 Mar 2009 07:49:51 -0600 Received: from [192.168.2.51] (r51.zioup.net [192.168.2.51]) by home.zioup.com (Postfix) with ESMTP id 0655A350BF for ; Thu, 26 Mar 2009 07:49:51 -0600 (MDT) Message-ID: <49CB87FE.1050809@zioup.com> Date: Thu, 26 Mar 2009 07:49:50 -0600 From: Yves Dorfsman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ldapext@ietf.org References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49CB192E.5050105@zioup.com> <49CB211C.6070108@eb2bcom.com> In-Reply-To: <49CB211C.6070108@eb2bcom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 13:48:59 -0000 Steven Legg wrote: >>> See http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt > We created a solution for presenting directory attribute values that are > arbitrary UTF-8 character strings including line breaks. That accommodates > UTF-8 encoded XML documents, but would also be useful for GSER encodings > if the whitespace separator is extended to include line breaks. > >> Any reason why the draft never made it to an RFC ? > > It may yet. We've just been busy with other things and there hasn't been > external pressure to move it along. Yes I was wondering about that, do we need multi-line values as work around because schemas aren't precise enough ? > Escaping the line break characters in the value and using the existing > LDIF line folding method would work. The output function can optionally > fold lines immediately after an escaped line break so that the number > of lines in the value matches the number of lines in the LDIF output. > > Another solution is to drop into a literal mode until a special character > sequence is encountered (e.g., END-OF-VALUE). One must then take care to > escape the special sequence if it happens to occur in the attribute value. > > Both of the above solutions require messing about with escape sequences, > whereas the simple prefix method we settled on doesn't need to. > >> Would quoting a la python work, or would that add too much complexity, >> too much of a change from the current LDIF ? > > Can you present an example of what you mean ? Python style would be usint a special character that then needs to be escaped, something like: ##################################### organizationName: Smith, Smith & Smith givenName: John ##################################### or ##################################### organizationName: 'Smith, Smith & Smith' givenName: John ##################################### But now that I think of it, it does look messy in the middle of an LDIF file. What about a mix, like: ##################################### organizationName: 'Smith, Smith\' \ '&\' \ 'Smith' givenName: John ##################################### I find it a lot more LDIFic... Again, before we get into something like that, I'd like to have a better feeling for how much of a need we have for it ? -- Yves. http://www.sollers.ca/ From jim@willeke.com Thu Mar 26 07:24:45 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD303A685C for ; Thu, 26 Mar 2009 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkh-yRIYm9me for ; Thu, 26 Mar 2009 07:24:44 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 2F6DE3A6856 for ; Thu, 26 Mar 2009 07:24:43 -0700 (PDT) Received: by qyk36 with SMTP id 36so1066861qyk.29 for ; Thu, 26 Mar 2009 07:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.98.195 with SMTP id r3mr186409qcn.88.1238077535957; Thu, 26 Mar 2009 07:25:35 -0700 (PDT) In-Reply-To: <49CB87FE.1050809@zioup.com> References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49CB192E.5050105@zioup.com> <49CB211C.6070108@eb2bcom.com> <49CB87FE.1050809@zioup.com> Date: Thu, 26 Mar 2009 10:25:35 -0400 Message-ID: From: Jim Willeke To: ldapext@ietf.org Content-Type: multipart/alternative; boundary=0016364eed54bc3462046606635a Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 14:24:45 -0000 --0016364eed54bc3462046606635a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We, doing LDAP consulting, often run into these type of issues, but I believe they could be covered utilizing UTF8. Although I love the discussions, regardless of how individuals feel, these discussions have already been and the decision was unicode. The decision of the today's environment was also to use XML. Not saying that either is right or wrong, but this is today's reality. Why not use DSML or perhaps go wild and use protocol buffers. ( http://code.google.com/p/protobuf/) I believe DSML would also handle the concern for LDAP transactions as is or with some minor tweaks. -jim Jim Willeke On Thu, Mar 26, 2009 at 9:49 AM, Yves Dorfsman wrote: > Steven Legg wrote: > >> See http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt >>>> >>> > We created a solution for presenting directory attribute values that are >> arbitrary UTF-8 character strings including line breaks. That accommodates >> UTF-8 encoded XML documents, but would also be useful for GSER encodings >> if the whitespace separator is extended to include line breaks. >> >> Any reason why the draft never made it to an RFC ? >>> >> >> It may yet. We've just been busy with other things and there hasn't been >> external pressure to move it along. >> > > Yes I was wondering about that, do we need multi-line values as work around > because schemas aren't precise enough ? > > > Escaping the line break characters in the value and using the existing >> LDIF line folding method would work. The output function can optionally >> fold lines immediately after an escaped line break so that the number >> of lines in the value matches the number of lines in the LDIF output. >> > > > >> Another solution is to drop into a literal mode until a special character >> sequence is encountered (e.g., END-OF-VALUE). One must then take care to >> escape the special sequence if it happens to occur in the attribute value. >> >> Both of the above solutions require messing about with escape sequences, >> whereas the simple prefix method we settled on doesn't need to. >> >> Would quoting a la python work, or would that add too much complexity, >>> too much of a change from the current LDIF ? >>> >> >> Can you present an example of what you mean ? >> > > Python style would be usint a special character that then needs to be > escaped, something like: > ##################################### > organizationName: Smith, Smith > & > Smith > givenName: John > ##################################### > > or > ##################################### > organizationName: 'Smith, Smith > & > Smith' > givenName: John > ##################################### > > > But now that I think of it, it does look messy in the middle of an LDIF > file. What about a mix, like: > ##################################### > organizationName: 'Smith, Smith\' \ > '&\' \ > 'Smith' > givenName: John > ##################################### > > > I find it a lot more LDIFic... > > Again, before we get into something like that, I'd like to have a better > feeling for how much of a need we have for it ? > > -- > Yves. > http://www.sollers.ca/ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > --0016364eed54bc3462046606635a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We, doing LDAP consulting, often run into these type of issues, but I belie= ve they could be covered utilizing UTF8.

Although I love the discuss= ions, regardless of how individuals feel, these discussions have already be= en and the decision was unicode.

The decision of the today's environment was also to use XML.
Not saying that either is right or wrong, but this is today's reality.=

Why not use DSML or perhaps go wild and use protocol buffers. (http://code.google.com/p/protobu= f/)
I believe DSML would also handle the concern for LDAP transactions as is or= with some minor tweaks.

-jim
Jim Willeke


On Thu, Mar 26, 2009 at 9:49 AM, Yves Do= rfsman <yves@zioup.c= om> wrote:
Steven Legg wrote:
See http://www.xmled.info/drafts/draft-sciberras-xed-eldif= -05.txt

We created a solution for presenting directory attribute values that are arbitrary UTF-8 character strings including line breaks. That accommodates<= br> UTF-8 encoded XML documents, but would also be useful for GSER encodings if the whitespace separator is extended to include line breaks.

Any reason why the draft never made it to an RFC ?

It may yet. We've just been busy with other things and there hasn't= been
external pressure to move it along.

Yes I was wondering about that, do we need multi-line values as work around= because schemas aren't precise enough ?


Escaping the line break characters in the value and using the existing
LDIF line folding method would work. The output function can optionally
fold lines immediately after an escaped line break so that the number
of lines in the value matches the number of lines in the LDIF output.
>
Another solution is to drop into a literal mode until a special character sequence is encountered (e.g., END-OF-VALUE). One must then take care to escape the special sequence if it happens to occur in the attribute value.<= br>
Both of the above solutions require messing about with escape sequences, whereas the simple prefix method we settled on doesn't need to.

Would quoting a la python work, or would that add too much complexity, too = much of a change from the current LDIF ?

Can you present an example of what you mean ?

Python style would be usint a special character that then needs to be escap= ed, something like:
#####################################
organizationName: Smith, Smith
&
Smith
givenName: John
#####################################

or
#####################################
organizationName: 'Smith, Smith
&
Smith'
givenName: John
#####################################


But now that I think of it, it does look messy in the middle of an LDIF fil= e. What about a mix, like:
#####################################
organizationName: 'Smith, Smith\' \
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'&\' \
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'Smith'
givenName: John
#####################################


I find it a lot more LDIFic...

Again, before we get into something like that, I'd like to have a bette= r feeling for how much of a need we have for it ?

--
Yves.
http://www.sollers.ca/=

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/ldapext

--0016364eed54bc3462046606635a-- From steven.legg@eb2bcom.com Thu Mar 26 15:29:03 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1711B3A68D6 for ; Thu, 26 Mar 2009 15:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.378 X-Spam-Level: X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XjsGqc8yuHr for ; Thu, 26 Mar 2009 15:29:02 -0700 (PDT) Received: from eb2bcom.com (165.203.232.72.static.reverse.ltdomains.com [72.232.203.165]) by core3.amsl.com (Postfix) with ESMTP id 0A4B33A687D for ; Thu, 26 Mar 2009 15:29:01 -0700 (PDT) Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lmy5C-0004su-Ne; Fri, 27 Mar 2009 09:29:55 +1100 Message-ID: <49CC01DE.6040506@eb2bcom.com> Date: Fri, 27 Mar 2009 09:29:50 +1100 From: Steven Legg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Yves Dorfsman References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49CB192E.5050105@zioup.com> <49CB211C.6070108@eb2bcom.com> <49CB87FE.1050809@zioup.com> In-Reply-To: <49CB87FE.1050809@zioup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Cc: ldapext@ietf.org Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:29:03 -0000 Hi Yves, Yves Dorfsman wrote: > Steven Legg wrote: >>>> See http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt > >> We created a solution for presenting directory attribute values that are >> arbitrary UTF-8 character strings including line breaks. That >> accommodates >> UTF-8 encoded XML documents, but would also be useful for GSER encodings >> if the whitespace separator is extended to include line breaks. >> >>> Any reason why the draft never made it to an RFC ? >> >> It may yet. We've just been busy with other things and there hasn't been >> external pressure to move it along. > > Yes I was wondering about that, do we need multi-line values as work > around because schemas aren't precise enough ? No, we need them because sheets of paper, computer screens and RFCs are not infinitely wide. :-) Human-readability, line breaks and indenting tend to go hand-in-hand. > > >> Escaping the line break characters in the value and using the existing >> LDIF line folding method would work. The output function can optionally >> fold lines immediately after an escaped line break so that the number >> of lines in the value matches the number of lines in the LDIF output. > > >> Another solution is to drop into a literal mode until a special character >> sequence is encountered (e.g., END-OF-VALUE). One must then take care to >> escape the special sequence if it happens to occur in the attribute >> value. >> >> Both of the above solutions require messing about with escape sequences, >> whereas the simple prefix method we settled on doesn't need to. >> >>> Would quoting a la python work, or would that add too much >>> complexity, too much of a change from the current LDIF ? >> >> Can you present an example of what you mean ? > > Python style would be usint a special character that then needs to be > escaped, something like: > ##################################### > organizationName: Smith, Smith > & > Smith > givenName: John > ##################################### > > or > ##################################### > organizationName: 'Smith, Smith > & > Smith' > givenName: John > ##################################### > > > But now that I think of it, it does look messy in the middle of an LDIF > file. What about a mix, like: > ##################################### > organizationName: 'Smith, Smith\' \ > '&\' \ > 'Smith' > givenName: John > ##################################### > > > I find it a lot more LDIFic... And is starting to obscure what the value actually is, which any scheme using escapes will do to greater or lesser degrees. The method Andrew and I chose puts a '>' down the first column, but everything to the right of that is literally the attribute value. It's easy to hand edit correctly, and easy to process on input and output. > > Again, before we get into something like that, I'd like to have a better > feeling for how much of a need we have for it ? We defined an extended LDIF because we need it, even if for now we are only talking to ourselves. We are already storing XML documents in directory attribute values so we need a convenient way to dump, edit and load such values. Regards, Steven > From steven.legg@eb2bcom.com Thu Mar 26 15:54:21 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8716B3A67CC for ; Thu, 26 Mar 2009 15:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.378 X-Spam-Level: X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDTeeolfDADP for ; Thu, 26 Mar 2009 15:54:20 -0700 (PDT) Received: from eb2bcom.com (165.203.232.72.static.reverse.ltdomains.com [72.232.203.165]) by core3.amsl.com (Postfix) with ESMTP id 739BD3A676A for ; Thu, 26 Mar 2009 15:54:20 -0700 (PDT) Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from ) id 1LmyTh-0007sn-5e; Fri, 27 Mar 2009 09:55:14 +1100 Message-ID: <49CC07CD.9000508@eb2bcom.com> Date: Fri, 27 Mar 2009 09:55:09 +1100 From: Steven Legg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jim Willeke References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49CB192E.5050105@zioup.com> <49CB211C.6070108@eb2bcom.com> <49CB87FE.1050809@zioup.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Cc: ldapext@ietf.org Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:54:21 -0000 Hi Jim, Jim Willeke wrote: > We, doing LDAP consulting, often run into these type of issues, but I > believe they could be covered utilizing UTF8. > > Although I love the discussions, regardless of how individuals feel, > these discussions have already been and the decision was unicode. > > The decision of the today's environment was also to use XML. > > Not saying that either is right or wrong, but this is today's reality. Yep. > > Why not use DSML The problem with DSML is that controls and extended operations have to appear as the base64 encoding of the BER encoding, and directory attribute values that contain XML have to have the markup escaped. I invented XLDAP (http://www.xmled.info/drafts/draft-legg-xed-protocols-05.txt) so that controls, extended operations and directory attribute values would all appear as markup, without fiddly escaping and obscuring encodings. > or perhaps go wild and use protocol buffers. > (http://code.google.com/p/protobuf/) It seems to be doing much the same thing as what we can already do with ASN.1 and GSER encodings. > I believe DSML would also handle the concern for LDAP transactions as is > or with some minor tweaks. If you don't mind base64 encodings of BER encodings. XLDAP does it better. Regards, Steven > > -jim > Jim Willeke > > > On Thu, Mar 26, 2009 at 9:49 AM, Yves Dorfsman > wrote: > > Steven Legg wrote: > > See > http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt > > > We created a solution for presenting directory attribute values > that are > arbitrary UTF-8 character strings including line breaks. That > accommodates > UTF-8 encoded XML documents, but would also be useful for GSER > encodings > if the whitespace separator is extended to include line breaks. > > Any reason why the draft never made it to an RFC ? > > > It may yet. We've just been busy with other things and there > hasn't been > external pressure to move it along. > > > Yes I was wondering about that, do we need multi-line values as work > around because schemas aren't precise enough ? > > > Escaping the line break characters in the value and using the > existing > LDIF line folding method would work. The output function can > optionally > fold lines immediately after an escaped line break so that the > number > of lines in the value matches the number of lines in the LDIF > output. > > > > > Another solution is to drop into a literal mode until a special > character > sequence is encountered (e.g., END-OF-VALUE). One must then take > care to > escape the special sequence if it happens to occur in the > attribute value. > > Both of the above solutions require messing about with escape > sequences, > whereas the simple prefix method we settled on doesn't need to. > > Would quoting a la python work, or would that add too much > complexity, too much of a change from the current LDIF ? > > > Can you present an example of what you mean ? > > > Python style would be usint a special character that then needs to > be escaped, something like: > ##################################### > organizationName: Smith, Smith > & > Smith > givenName: John > ##################################### > > or > ##################################### > organizationName: 'Smith, Smith > & > Smith' > givenName: John > ##################################### > > > But now that I think of it, it does look messy in the middle of an > LDIF file. What about a mix, like: > ##################################### > organizationName: 'Smith, Smith\' \ > '&\' \ > 'Smith' > givenName: John > ##################################### > > > I find it a lot more LDIFic... > > Again, before we get into something like that, I'd like to have a > better feeling for how much of a need we have for it ? > > -- > Yves. > http://www.sollers.ca/ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext