Jump to content

Talk:LDAP Data Interchange Format

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Navur (talk | contribs) at 16:59, 1 April 2010 (Undid revision 353151764 by 115.242.212.140 (talk)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputing Unassessed
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
???This article has not yet received a rating on Wikipedia's content assessment scale.
???This article has not yet received a rating on the project's importance scale.

LDIF content v. change records

The article should discuss the two subformats providing examples of both. Kdz 00:06, 11 June 2006 (UTC)[reply]

mis-handled non-alphanumeric characters

Would someone of some authority in the LDIF standards community please provide specific instructions or a chart on how to handle non-alphanumeric characters (eg, ampersand, single quote, etc.). For example, Yahoo! still insists on encoding all ampersands as extended HTML characters (ie, "&" --> "&") which, of course, fails to decode properly when an LDIF-compliant application tries to read the file. They've been contacted several times over the years but apparently are unable to understand the technical nature of the problem. I routinely import my Yahoo! address list into Thunderbird and if we could just get this one issue defined clearly enough for them to understand and act accordingly, it would save me literally hours of editing each time. The problem has been compounded now that they have discovered Base64 encoding finally but it means I have to edit twice; once before importing and then again after importing to catch the errant translations in the data that were Base64 encoded. Thank you ever so much. JimScott (talk) 16:35, 12 June 2009 (UTC)[reply]