最近在做一個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消息的編碼和解碼