rfc2970.txt

RFC 的详细文档！

         a specific lookup, but rather will be set to allow the
         user to see the list of publicized medical conditions.
         Depending on the query type, the next step will be to
         contact the referral index to determine what records
         exist, and then track down information at the remote sources.

   Data architecture:
           [Out of scope for the purposes of this illustration]

   Pictorially, the example can be rendered as follows:

         +-------------------------------------------+
     "a" |         |                +--------+       |
   <----->  CAP a  |                | SAP A  |       |
         |         |                |        |       |
         |---------+                +-+------+---+   |
         |                            |(Internal)|   |
         |           "DAG/IP"         | Server i |   |
         |                            +----------+   |
         |                                           |
         |                                           |
         |                          +--------+       | "B"
         |---------+                | SAP B  <-------------->
     "b" |         |                |        |       |
   <----->  CAP b  |                +--------+       |
         |         |                                 |
         |---------+                +--------+       |
         |                          | SAP C  |       |
         |                          |        |       |
         |                          +-+------+---+   |
         |                            |(Internal)|   |
         |                            | Server j |   |
         |                            +----------+   |
         +-------------------------------------------+

   where

      CAP a           CAP for proprietary protocol, secure clients
      CAP b           WAP CAP, for roaming access
      SAP A           authentication and ACL lookup interface
      Server i        authentication and ACL lookup server
      SAP B           remote service SAP -- probably LDAPv3
      SAP C           Referral Index interface
      Server j        Referral Index







Daigle & Eklof               Informational                     [Page 13]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


6. Requirements for the future DAG/IP

   The role of the DAG/IP is less as a query protocol, and more as a
   framework or structure for carrying basic query-response transactions
   of different (configurable) types.

   Whatever the syntax or grammar, the basic requirements for the DAG/IP
   include that it be:

      - lightweight; CAPs, SAPs should be able to be quite small
      - flexible enough to carry queries of different paradigms, results
        of different types
      - able to support authentication, authorization, accounting and
        audit mechanisms -- not necessarily native to the protocol
      - able to support encryption and end-to-end security within the
        DAG system
      - sophisticated enough to allow negotiation of  capabilities --
        querying & identifying application type supported (e.g.,
        whitepages vs. service location vs. URN resolution), query types
        supported, results types supported

      This also means:

   Better support for query-passing/other query semantics (need to
   balance that against the fact that you don't want DAG-CAPs/SAPs to
   have to know a multiplicity of semantic possibilities.

   Security infrastructure -- ability to establish security credentials,
   maintain a secure transaction, and propagate the security information
   forward in the transaction (don't want to reinvent the wheel, just
   want to be able to use it!).

   Ability to do lookups, instead of searches -- might mean connecting
   to different services than the RI and/or presenting things in a
   slightly different light -- e.g., lookup <blat> in the <foo> space,
   as opposed to search for all things concerning <blat>.

   Ability to access other services -- e.g., Norwegian Directory of
   Directories [NDD] -- beyond just for specific characteristics of the
   service (e.g., security).

   In short, the model that seems to stand out from these requirements
   one of a protocol framework that looks after establishing secure and
   authenticated (authorized, accountable, auditable...) connections,
   with transaction negotiation facilities.  Within that framework, it
   must be possible to identify transaction types, provide suitable
   input information (negotiation?) for those transactions, and accept
   transaction result objects back.



Daigle & Eklof               Informational                     [Page 14]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


7. Revisiting TISDAG -- for the future

   In the light of the above proposals, we can revisit the way the
   TISDAG CAPs would be defined.

   The whitepages-application service known as TISDAG could have SAPs
   that supported 2 types of query, and 2 types of result sets:

           query types:
                   . token-based
                   . phrase-based

           result types:
                   . result data
                   . referrals

   The Whois++ CAP would be configured to contact LDAPv2 and LDAPv3 SAPs
   because they are identified as providing that kind of service (i.e.,
   if referral protocol == LDAPv2 connect to a particular service).  The
   query paradigm will be phrase-oriented -- NOT because the Whois++ CAP
   understands LDAP, but because that is one of the defined query types.

8. Applicability Limitations

   As it stands, this type of service architecture is limited to query-
   response type transactions.  This does account for a broad range of
   applications and services, although it would be interesting to
   consider broadening the concept to make it applicable to tunneling
   other protocols (e.g., to connect a call through a SAP, in the number
   portability example above).

9. Security Considerations

   This document takes a high-level perspective on service architecture,
   and as such it neither introduces nor addresses security concerns at
   an implementation level.

   A distributed service built following this approach must address
   issues of authentication of users, authorization for access to
   material/components of the system, and encryption of links between
   them, as befits the nature of the information and service provided.










Daigle & Eklof               Informational                     [Page 15]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


10. Acknowledgements

   In discussing this perspective on the evolution of DAG/IP, it seemed
   to us that the requirements for DAG/IP are falling into line with the
   proposed text-based directory access protocol that has variously been
   discussed.  Whether it survives in a recognizable form or not :-)
   some of the above has been drawn from discussions of that protocol
   with Michael Mealling and Patrik Faltstrom.

   The work described in this document was carried out as part of an on-
   going project of Ericsson.  For further information regarding that
   project, contact:

      Bjorn Larsson
      [e-mail]

11. Authors' Addresses

   Leslie L. Daigle
   Thinking Cat Enterprises

   EMail:  [e-mail]


   Thommy Eklof
   Hotsip AB

   EMail: [e-mail]

12. References

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

   [ALVE]     Alvestrand, H., "Definitions for Talking about
              Directories", Work in Progress.

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

   [DAGEXP]   Eklof, T. and L. Daigle, "Wide Area Directory Deployment
              Experiences", RFC 2969, September 2000.

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





Daigle & Eklof               Informational                     [Page 16]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


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

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














































Daigle & Eklof               Informational                     [Page 17]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


13.  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.



















Daigle & Eklof               Informational                     [Page 18]