Le 14/10/15 21:26, Radovan Semancik a écrit : > Hi, > > Sounds good. Just note that "user provided" value is in fact the one > that is decoded from the protocol in case that a value is received in > LDAP message. It's what the user gives on the clien side, before it get encoded to be sent to a LDAP server. In a sense, it's really what the user has provided. Bottom line, if a user inject an entry with something like 'cn: My Name', then when someone query the entry containing this value, they will get 'My Name' as a result, and yes, this is what is being transmitted through the network.
> And in that case the "user provided" value is always binary, even for > string values. The distinction between 'binary' and 'Strung' is a bit artificial, and based on a flag that can be found in RFC 2252, the H-R flag : The following table lists some of the syntaxes that have been defined for LDAP thus far. The H-R column suggests whether a value in that syntax would likely be a human readable string. Clients and servers need not implement all the syntaxes listed here, and MAY implement other syntaxes. > If you remember our conversation some time ago the re-coding of string > value by current implementation caused quite nasty problem if the > receiver cannot reliably distinguish string and binary values. > Therefore I really like the idea to store the original value and > record on demand. If that is done well then the originally-received > binary values can be retrieved even from StringValue class. And that > will improve usability of the API. That does not solve the problem of dealing with Value that have a String Syntax (IA5String, DirectoryString, etc). We have to follow the rules specified in RFC 4517 and RFC 4518. What is important here is that we will have at some point to go from a byte[] representation to a String format, because we need to be able to compara a vlaue with other values, either to check if the candidate matches a filter, or to store the value into an index. In other words, we must keep both a byte[] and a String representation of a value...
