client
Click on the red underlined text to get to the source
... encoding rules for attribute syntaxes
defining non-binary values should produce strings that can be
displayed with little or no translation by clients implementing LDAP.
There are a few cases (e.g. audio ...
... There are a few cases (e.g. audio) however, when it is not sensible
to produce a printable representation, and clients MUST NOT assume
that an unrecognized syntax is a string representation.
...
... This encoding format is used if the binary encoding is requested by
the client for an attribute, or if the attribute syntax name is
"1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP
...
... search responses, and parsing attribute values in add,
compare and modify requests, if the attribute type is recognized and
the attribute syntax name is that of Binary. Clients which request
that all attributes be returned from entries MUST be prepared to
receive values in binary (e.g. userCertificate;binary), and SHOULD
...
... 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.
...
... definition of additional arbitrary syntaxes is strongly deprecated
since it will hinder interoperability: today's client and server
implementations generally do not have the ability to dynamically
recognize new syntaxes. In most cases attributes will be defined
...
... DN of the
root). This attribute will allow a client to choose suitable base
objects for searching when it has contacted a server.
...
... unavailable. If the server does
not know of any other servers which could be used this attribute will
be absent. Clients may cache this information in case their preferred
LDAP server ...
... ISO 10646 (a
superset of Unicode). Servers and clients MUST be prepared to
receive encodings of arbitrary Unicode characters ...
...
Servers which allow subschema entries to be modified by clients MUST
support the following matching rules, as they are the equality
...
