⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2594.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 5 页
字号:
Network Working Group                                      H. HazewinkelRequest for Comments: 2594             Joint Research Centre of the E.C.Category: Standards Track                                 C. Kalbfleisch                                                             Verio, Inc.                                                        J. Schoenwaelder                                                         TU Braunschweig                                                                May 1999            Definitions of Managed Objects for WWW ServicesStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1999).  All Rights Reserved.Abstract   This memo defines a portion of the Management Information Base (MIB)   for use with network management protocols in the Internet Community.   In particular it describes a set of objects for managing World Wide   Web (WWW) services.Table of Contents   1 Introduction .................................................    1   2 The SNMP Management Framework ................................    2   3 Terminology ..................................................    3   4 Overview .....................................................    4   4.1 Purpose and Requirements ...................................    4   4.2 Relationship to other Standards Efforts ....................    5   4.3 WWW Services ...............................................    5   4.4 Document Transfer Protocol .................................    6   5 Structure of the MIB .........................................    7   5.1 Service Information Group ..................................    7   5.2 Protocol Statistics Group ..................................    7   5.3 Document Statistics Group ..................................    8   6 Definitions ..................................................   10   7 Document Transfer Protocol Mappings ..........................   36   7.1 The HyperText Transfer Protocol ............................   36   7.2 The File Transfer Protocol .................................   37   8 Security Considerations ......................................   38   9 Intellectual Property ........................................   39   10 Acknowledgments .............................................   39Hazewinkel, et al.          Standards Track                     [Page 1]RFC 2594                    WWW Service MIB                     May 1999   11 Editors' Addresses ..........................................   39   12 References ..................................................   40   13 Full Copyright Statement ....................................   431.  Introduction   This memo defines a set of objects for managing World Wide Web (WWW)   services. This MIB extends the application management framework   defined by the System Application Management MIB (SYSAPPL-MIB) [23]   and the Application Management MIB (APPLICATION-MIB) [24]. The MIB is   also self-contained so that it can be implemented and used without   having to implement or install the APPLICATION-MIB or the SYSAPPL-   MIB.   The protocol statistics defined in the WWW Service MIB are based on   an abstract document transfer protocol (DTP). This memo also defines   a mapping of the abstract DTP to HTTP and FTP.  Additional mappings   may be defined in the future in order to use this MIB with other   document transfer protocols. It is anticipated that such future   mappings will be defined in separate RFCs.   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in RFC 2119 [17].2.  The SNMP Management Framework   The SNMP Management Framework presently consists of five major   components:    o   An overall architecture, described in RFC 2571 [1].    o   Mechanisms for describing and naming objects and events for the        purpose of management. The first version of this Structure of        Management Information (SMI) is called SMIv1 and described in        STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The        second version, called SMIv2, is described in STD 58, RFC 2578        [5], RFC 2579 [6] and RFC 2580 [7].    o   Message protocols for transferring management information. The        first version of the SNMP message protocol is called SNMPv1 and        described in STD 15, RFC 1157 [8]. A second version of the SNMP        message protocol, which is not an Internet standards track        protocol, is called SNMPv2c and described in RFC 1901 [9] and        RFC 1906 [10]. The third version of the message protocol is        called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and        RFC 2574 [12].Hazewinkel, et al.          Standards Track                     [Page 2]RFC 2594                    WWW Service MIB                     May 1999    o   Protocol operations for accessing management information. The        first set of protocol operations and associated PDU formats is        described in RFC 1157 [8]. A second set of protocol operations        and associated PDU formats is described in RFC 1905 [13].    o   A set of fundamental applications described in RFC 2573 [14] and        the view-based access control mechanism described in RFC 2575        [15].   Managed objects are accessed via a virtual information store, termed   the Management Information Base or MIB.  Objects in the MIB are   defined using the mechanisms defined in the SMI.   This memo specifies a MIB module that is compliant to the SMIv2. A   MIB conforming to the SMIv1 can be produced through the appropriate   translations. The resulting translated MIB must be semantically   equivalent, except where objects or events are omitted because no   translation is possible (use of Counter64). Some machine readable   information in SMIv2 will be converted into textual descriptions in   SMIv1 during the translation process. However, this loss of machine   readable information is not considered to change the semantics of the   MIB.3.  Terminology   This section defines the terminology used throughout this document.   o    The 'World Wide Web' (WWW) is a world wide information system        which is based on the concept of documents that are linked        together by embedding references (links) to other local or        remote documents.   o    A 'document' is a coherent piece of data which is accessible in        the World Wide Web. No assumptions are made about the content or        the type of a document.   o    A 'Uniform Resource Locator' (URL) is a formatted string        representation for a document available via the Internet. URLs        are used to express references between documents. For the syntax        and semantics of the URL string representation refer to RFC 2396        [18]   o    A 'Document Transfer Protocol' (DTP) is a protocol used within        the World Wide Web to invoke actions on documents. The DTP is an        abstraction from real protocols, such as HTTP [19,20] or FTP        [21].Hazewinkel, et al.          Standards Track                     [Page 3]RFC 2594                    WWW Service MIB                     May 1999   o    A 'request' is a DTP protocol operation which is targeted to a        'document' and invokes an action on the target document.  The        request type specifies the action that should be performed. A        request can have a document associated with it.   o    A 'response' is a DTP protocol operation which is returned as a        result of a previous (and associated) request. The response        status indicates if the requested action was successful or if        errors occurred. A response can have a document associated with        it.   o    A 'WWW service' is a set of actions that can be invoked on a        document. Typical actions are the transfer of documents or the        retrieval of administrative information about documents. WWW        services are provided by means of a DTP. A WWW service can be        identified by the DTP protocol used to invoke services and the        transport endpoint used by that protocol.   o    A 'client' is a program which establishes connections for the        purpose of sending requests and receiving responses.   o    A 'server' is a program that accepts connections in order to        service requests by sending back responses.   o    A 'proxy' is an intermediary program which acts as both a server        and a client for the purpose of making requests on behalf of        other clients.  Requests are serviced internally or by passing        them on, with possible translation, to other servers.   o    A 'caching proxy' is a proxy with the capability of locally        storing responses to associated requests. A caching proxy can        respond to similar requests with a previously stored response.4.  Overview   The World Wide Web (WWW) is a global network of information.   Information is stored in documents, which can have various formats,   including hyper-text and multi-media documents. Access to these   documents is provided by servers which are located all around the   world and are linked to each other via hyper-links embedded in   documents.   The usability of the World Wide Web depends largely on the   performance of the services realized by these servers. The services   are typically monitored through log files. This becomes a difficult   task when a single organization is responsible for a large number of   services. It is therefore desirable to treat WWW services as objects   that can be managed by using the Internet network management   framework [22].Hazewinkel, et al.          Standards Track                     [Page 4]RFC 2594                    WWW Service MIB                     May 19994.1.  Purpose and Requirements   The goal of this MIB is to define a standardized set of objects which   lead to integrated and improved performance and fault management in a   heterogeneous environment of WWW services. This MIB focuses on the   service-oriented view. It does not deal with the process oriented   view, which is covered by the System Application MIB [23] and the   Application MIB [24].   This document defines a set of managed objects to monitor WWW   services for short-term operational purposes, such as problem   detection and troubleshooting. No attempts are made here to cover   accounting or hit metering issues.   The scope of the MIB is further limited by the requirement that an   implementation conforming to this MIB must be possible without   putting a huge CPU or memory burden on the WWW server implementation.   In addition, this MIB does not cover WWW service configuration.   Server software has become an open market where competing vendors   constantly invent new features in order to shape their products. It   is therefore not possible to reach consensus on a common way to   configure WWW services at this point in time.4.2.  Relationship to other Standards Efforts   The WWW Service MIB fits into the application management architecture   defined in the System Application MIB [23]. The System Application   MIB and the Application MIB [24] use a process-oriented view, where   an application is viewed as a collection of processes. The WWW   Service MIB described in this memo uses a service-oriented view,   which looks at the services provided by a set of processes.   The relationship between the process-oriented view and the service-   oriented view is a many-to-many relationship, because one process can   implement multiple services and multiple services can be implemented   by a single set of processes. The Application Management MIB [24]   contains generic mapping tables, which map back and forth between   both views.   The WWW Service MIB interfaces to the Application MIB [24] by using   the service instance identifier (applSrvIndex) for wwwServiceIndex if   an applicable instance of applSrvIndex is available. The WWW Service   MIB is self-contained and can be implemented as a stand-alone module   if the service-level tables in the Application MIB are not available.Hazewinkel, et al.          Standards Track                     [Page 5]RFC 2594                    WWW Service MIB                     May 19994.3.  WWW Services   The MIB is organized around the concept of WWW services. WWW services   are a set of actions that can be invoked on a document. A WWW service   is provided or used by either a client, a server or a proxy. Clients   send out requests for information to server or proxy server. Servers   receive, process and respond to requests received from clients.   Servers usually have access to local documents, which can be   transferred to clients.   A proxy is a special server, who acts as both a server and a client   for the purpose of making requests on behalf of other clients. A   proxy is able to translate between the client and the origin server.   A proxy might also interact with other information retrieval system,   like for example databases.   The MIB defined in this memo distinguishes between outgoing and   incoming requests and responses. This makes it possible to obtain   statistics for clients, servers and proxies with a single set of   objects.   A special proxy server is the caching proxy, which maintains a cache   of previously received documents in order to reduce the bandwidth   used by World Wide Web clients. One interesting piece of management   information is the percentage of requests that were served from the   cache of the caching proxy (hits/miss-ratio). This ratio is not   contained explicitly in this MIB. Instead, the ratio can be derived   from the objects that count incoming and outgoing requests and   responses.4.4.  Document Transfer Protocol   The MIB is based on the concept of an abstract document transfer   protocol (DTP). The purpose of the abstract document transfer   protocol is to make the MIB definitions independent from concrete   protocols, like the Hypertext Transfer Protocol (HTTP) [19,20] or the   File Transfer Protocol (FTP) [21].   The abstract document transfer protocol makes the following   assumptions about a concrete transfer protocol:   o    The transfer protocol uses a request/response style of        interactions.   o    Every request contains a request type, which defines the        operations performed by the receiving server. The request type        is represented by an OCTET STRING. It might be necessary to        define a translation into an OCTET STRING value for protocols        that use numbers to identify request types.Hazewinkel, et al.          Standards Track                     [Page 6]RFC 2594                    WWW Service MIB                     May 1999   o    A response contains a status code, which indicates if the        request was processed successfully or which error occurred. The        status code is represented as an INTEGER value. It might be        necessary to define a mapping for protocols that do not use an        INTEGER status code.   o    A transfer protocol can send multiple responses for a single        request.  Multiple responses are counted separately in the        protocol statistics group.        A primary response has to be identified for the document        statistics. The primary response is the response that indicates        whether the request was successful.

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -