rfc2969.txt

中、英文RFC文档大全打包下载完全版 .

      Bjorn Larsson
      [e-mail]














Eklof & Daigle               Informational                     [Page 13]

RFC 2969             Wide Area Directory Deployment         October 2000


8.0 Authors' Addresses

   Thommy Eklof
   Hotsip AB

   EMail: [e-mail]


   Leslie L. Daigle
   Thinking Cat Enterprises

   EMail:  [e-mail]

9.0 References

   Request For Comments (RFC) and Internet Draft documents are available
   from numerous mirror sites.

   [CIP1]     Allen, J. and M. Mealling, "The Architecture of the Common
              Indexing Protocol (CIP)", RFC 2651, August 1999.

   [CIP2]     Allen, J. and M. Mealling, "MIME Object Definitions for
              the Common Indexing Protocol (CIP)", RFC 2652, August
              1999.

   [CIP3]     Allen, J., Leach, P. and R. Hedberg, "CIP Transport
              Protocols", RFC 2653, August 1999.

   [DAG++]    Daigle, L. and T. Eklof, "An Architecture for Integrated
              Directory Services", RFC 2970, October 2000.

   [DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers:
              Meshes", RFC 2968, October 2000.

   [TISDAG]   Daigle, L. and R. Hedberg "Technical Infrastructure for
              Swedish Directory Access Gateways (TISDAG)," RFC 2967,
              October 2000.

   [centroid] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider,
              "Architecture of the WHOIS++ service", RFC 1835, August
              1995.

   [NDD]      Hedberg, R. and H. Alvestrand, "Technical Specification,
              The Norwegian Directory of Directories (NDD)", Work in
              Progress.






Eklof & Daigle               Informational                     [Page 14]

RFC 2969             Wide Area Directory Deployment         October 2000


   [TIO]      Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A
              Tagged Index Object for use in the Common Indexing
              Protocol", RFC 2654, August 1999.

   [complex]  P.  Panotzki, "Complexity of the Common Indexing Protocol:
              Predicting Search Times in Index Server Meshes",  Master's
              Thesis, KTH, September 1996.

   [WAP]      The Wireless Application Protocol, http://www.wapforum.org










































Eklof & Daigle               Informational                     [Page 15]

RFC 2969             Wide Area Directory Deployment         October 2000


Appendix -- Specific Software Issues and Deployment Experiences

   The following paragraphs outline practical deployment experiences in
   an anecdotal fashion.  This is not meant to be construed as an
   exhaustive, authoritative evaluation of existing client software, but
   rather an indication of the types of challenges the average
   implementation team may expect to encounter in a development and
   deployment effort.

   Character encoding
   ------------------
   One client's addressbook sends iso-8859 encoding (depending on the
   font configuration in the browser) when querying a directory server
   but the directory server responds with Unicode (UTF-8) encoding.
   This means that the LDAP CAP would have to handle different character
   set encodings for request and response.

   Referrals
   ---------
   Today there appears to be only one commercial addressbook supporting
   LDAPv3.  All the others support only LDAPv2.  However, this LDAPv3
   client software does not handle referrals correctly -- the client
   couldn't handle server the result contains "response code 10"
   (designated for referrals).  From what was observed, there was now
   way for the client or the end-user to decide if, or which, referrals
   to follow-up.   It is therefore not clear how the LDAP clients handle
   a combination of both referrals and results  -- but the supposition
   is that it doesn't work.

   Objectclasses in LDAP
   ---------------------
   No objectclass is defined in the query to the DAG-system from the
   LDAP-clients. This means that the DAG-system doesn't see any
   differences between "inetOrgPerson" and "organisationalRole" when
   attribute "cn" is representing both "name" and "role".  This is not
   so much a problem as that it has interesting side effects.  Namely,
   although most directory user interfaces (found in browsers, mail
   programs) claim only to support person-related queries, in practise a
   user of the client could use the interface to send a query with role
   in the name entry.

   Query with attribute Organisation
   ---------------------------------
   It is possible to send a query with attribute "organisation" but it
   would result in no hits because of that the organisation attribute is
   not included in the objectclass "inetOrgPerson".  Roland Hedberg has
   proposed a change for the latest release of the objectclass
   definition document.



Eklof & Daigle               Informational                     [Page 16]

RFC 2969             Wide Area Directory Deployment         October 2000


   To provide the desired ability to narrow search focus to some range
   of organization names (attribute values), there are three possible
   approaches with differing merits/detractions:

      Recommend the use of the "locality" attribute -- although a more
      standard definition would be required (locality is currently used
      for everything from organization to county to map coordinates).

      Recommend or require that the attribute organisation should be
      inherited in objectclass "inetOrgPerson".

      Build the LDAP DAG-SAP to submit 2 query to the WDSP. The second
      is the same as the first, with only cn filters if the entire query
      including "o" results in no hits (i.e., back off from the
      organization filtering if it doesn't seem to be supported).

   Configuration
   -------------
   It is not possible to see what character set a LDAP clients want to
   use.  The recommendation so far in he project has been to define a
   unique port for each character set.  This requires extra end-user
   configuration of client software, and proper advertising of the port
   number-charset mapping provided in the service.

   DN
   --
   When the user wants to look-up more information about a person found
   in a preliminary search, the  LDAP client uses the entry's DN
   together with host and port to the DAG system.  Not only does that
   mean that the client submits a non-compliant query to the DAG system,
   as DNs are not part of any of the defined queries for the service, it
   simply does not provide the desired effect of getting to the user's
   entry.

   Response Codes
   --------------
   The LDAPv3 client that was used does not support more than 2 response
   codes -- "success" and "size limit exceeded".  All the other response
   codes are translated to "size limit exceeded", although no results
   are returned.   That is, if the error was in fact that the size limit
   was exceeded, the results up to the size limit are presented.  If it
   was another response code mapped to that one, no results are
   presented.








Eklof & Daigle               Informational                     [Page 17]

RFC 2969             Wide Area Directory Deployment         October 2000


   Sending and loading CIP Index Objects
   -------------------------------------
   At least one server is quoting the CIP-object incorrectly for the
   Swedish characters A-Ring, A-Umlaut and O-Umlaut.  Sending quoted
   printable CIP-objects with PINE mail software works.

   Source - Labeled URI
   --------------------
   The original plan for the use of the labeled-URI attribute was to use
   it to return a pointer to the WDSP that provided the user
   information.  However, the standard use of the labeled-URI attribute,
   which may in fact be populated in the data returned by a WDSP, is to
   contain the URI for more private related homepages.






































Eklof & Daigle               Informational                     [Page 18]

RFC 2969             Wide Area Directory Deployment         October 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Eklof & Daigle               Informational                     [Page 19]