最近在做一个Ldap Client，确切的说是JNDI的Ldap Service Provider，目前主要还是在实现Ldap协议，
很少涉及到 JNDI API 的东西（个人认为这部分才是最麻烦的），所以题目就暂且就用了Ldap Client。
“系列”的意思就是会有很多篇了，这只是代表了某人美好的愿望，也算是督促自己把项目中一些有价值
的东西写出来。那么废话少说，进入正题吧。
    JNDI的Ldap Service Provider主要包括两个部分：Ldap 客户端协议的实现和JNDI API的实现。后者以后再
谈，先来看前者。关于Ldap的协议这里就不介绍了，不是很复杂，参照 RFC 2251 ,显然一个RFC是远远不够的，2251
针对的是v3，RFC 1777是v2，当你通读了2251准备着手编程的时候发现，2251除了告诉你什么是Ldap，有哪些request和
response之外毫无用处，随后你会发现一些，准确的说是一堆RFC规范需要去阅读，跟客户端相关的主要有：

Main
RFC 1777: v2, RFC 2251: v3

Control
RFC 2696, RFC 3296, RFC 2891

Security
RFC 2829, RFC 2830

Attribute and Schema
RFC 2713, RFC 2252, RFC 2256

Representation and Format
RFC 2253, RFC 2254, RFC 2255

    大概就这些吧，弄不好其中又会牵涉到什么规范就与我无关了。各位看官不要被这么多的RFC吓倒了，毛爷爷说的好
帝国主义的RFC都是纸老虎，待我一一道来：
Main 是Ldap的核心规范，1777和2251分别对应v2和v3，主要定义了client和server的交互方式和内容
Control 是Ldap协议中与Control相关的规范，定义了一些必须实现的Control
Security 是与安全相关的规范，包括支持的认证方式和安全相关的操作
Attribute and Schema 是Attribute的syntax和schema以及存储java object需要的schema定义
Representation and Format 定义了DN、URL、Filter的string表达方式

    看来RFC的同志工作还是非常认真的，这些规范从不同的层次和方面对Ldap的协议进行了描述和完善。核心规范2251对协议
的消息交互机制以及消息的格式进行了严格的定义，并指定使用ASN.1 Basic Encoding Rules对消息编码传输，那么client和
server沟通的语言问题就解决了。Control 和 Attribute and Schema 提升了Ldap的可扩展性，Representation and Format
提高了协议表达的准确性。尽管如此，规范中还是有很多地方表达不是很清楚，貌似也没有提供一个参考实现可以把玩。这一点
JSR做的就很好，每个规范在指定的过程中就会同步开发参考实现，参考实现实际上就是对规范的验证，同时也能暴露出制定初期
不完善的地方。
    瞌睡了，写不动了，先这样吧。
    预告：下一篇写Ldap消息的编码和解码