rfc2259.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,684 行 · 第 1/4 页
TXT
1,684 行
Network Working Group J. ElliottRequest for Comments: 2259 Epic Systems CorporationCategory: Informational J. Ordille Bell Labs, Lucent Technologies January 1998 Simple Nomenclator Query Protocol (SNQP)Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved.Abstract The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. The protocol is useful to services that search many data repositories for query responses. Clients can pose queries on relations, list descriptions of relations, and obtain advice on reducing the search time and cost of their queries. Clients are informed of the age of information in caches, and may request more recent information. SNQP provides support for graphical user interfaces. It also supports different types of comparison operators, so services can use SNQP with a variety of back-end servers, e.g. relational database servers, CCSO servers, and servers providing relational views of X.500. SNQP is an ASCII protocol in the request-reply style of SMTP. It was specifically designed for use with the Nomenclator name and information service, and has been useful elsewhere.1. Introduction The Simple Nomenclator Query Protocol (SNQP) is a protocol for querying servers that search collections of data repositories. Users retrieve information from an SNQP server by describing attributes of the information. SNQP servers contact one or many data repositories to retrieve the response to a user query. If the data repositoriesElliott & Ordille Informational [Page 1] RFC 2259 SNQP January 1998 differ in protocol or data format, it is responsibility of the SNQP server to translate protocols and data formats to provide one, integrated answer to the user's query. SNQP servers share the protocol needs of centralized data repositories that answer queries with locally stored data. SNQP servers also require specialized protocol features due to their distributed search characteristics. In highly distributed environments, it is unreasonable to expect all data repositories that need to be searched to be available when queries are posed. SNQP servers require facilities for returning partial results in the presence of communications errors with data repositories. The partial results must indicate how to resubmit the query only to those data repositories that are unavailable. In addition, users may pose queries without realizing the cost of the search for query responses. SNQP provides facilities for informing users of query costs and advising them on limiting that cost. Costs and advice are returned before queries are executed. Finally, SNQP servers may cache data and meta-data to speed query responses. Servers can inform users of the t-bound for their query response. A t-bound is the time after which changes may have occurred to the data that are not reflected in the query response [6,2]. A t-bound is the time of the oldest cache entry used to calculate the response. Users can request that query responses are more current then a particular t-bound. Making such a request flushes older items from the cache. SNQP provides support for graphical user interfaces. It also supports different types of comparison operators, so SNQP servers can query a variety of back-end data repositories, e.g. relational databases, CCSO servers [3], and servers providing relational views of X.500 [10]. SNQP is a connection-oriented protocol. A client initiates a query session with an SNQP server by making a TCP connection to a well- known port. The client then executes a series of SNQP commands. These commands are listed briefly in Table 1. Section 2 provides some typical scenarios for using these commands, and Section 3 describes the commands fully. The server replies to each command using the theory of reply codes described for the Simple Mail Transfer Protocol (SMTP) [9]. The theory of reply codes and the defined reply codes are described in Section 4.Elliott & Ordille Informational [Page 2] RFC 2259 SNQP January 1998 --------------------------------------------------------------------- Command Description --------------------------------------------------------------------- advice Provide advice on query costs without executing query. attributes List the attributes for a relation. compare Set type of comparison operation. help Explain the SNQP commands. imagui Format replies for a graphical user interface. next Stop processing current query, continue with next query in block. noadvice Provide responses to queries. Do not advise on costs. noimagui Format replies for people. query Submit a block of one or more SQL query statements. relations List the relations available through the SNQP server. stop End processing of current query, and cancel any queries remaining in block. quit Terminate the query session. Table 1: SNQP Commands --------------------------------------------------------------------- SNQP queries are posed in SQL, a standard relational database query language [4,12]. Information that is obtained through SNQP servers is organized by type into database relations. SQL queries may often have more functionality then a server supports or an application demands. Moreover, advice on query costs, some types of comparison operations or t-bounds may not be supported by a particular server. SNQP defines a minimal subset of functionality for a working SNQP protocol. Functionality beyond this subset is optional. Servers that do not support optional functionality must return replies that indicate this to the user. The required and optional features of SNQP are summarized in Section 5. SNQP was specifically designed for use with the Nomenclator name and information service [8,7,5]. Nomenclator produces query responses by integrating information from data repositories with different protocols and data formats. It constrains the searches for query responses through a variety of distributed indexing techniques. SNQP has also been found useful elsewhere, even as a query language for a single data repository. SNQP is defined for US-ASCII only, and use with other character sets will require further work.Elliott & Ordille Informational [Page 3] RFC 2259 SNQP January 1998 Section 6 concludes this document with a description of security considerations.2. Scenarios This section illustrates the basic SNQP commands by presenting several client scenarios. The scenarios include a new user, a user who prefers CCSO style comparisons and more current responses, a graphical user interface program, a user with a change of mind, and a user worried about costs. Although SNQP will work for a human client on a bare connection (like one provided by telnet), it also works for client programs. Several of these programs have been written and provide enhanced interfaces.2.1 New User A new SNQP user will first make a tcp connection to an SNQP server. For purposes of illustration, we will assume that the user makes the connection with the Unix telnet command, and that the server is located at nomen.research.bell-labs.com on port 4224. The user enters a relation command to discover what relations are available, and an attributes command to discover the attributes for a particular relation. The user eventually asks for people with a given name of "J*" and a surname of "Ordille" who work for "Lucent Tech*". The response is current through June 11, 1996 at 11 p.m. EDT. Figure 1a and Figure 1b provide this scenario.Elliott & Ordille Informational [Page 4] RFC 2259 SNQP January 1998 --------------------------------------------------------------------- > telnet nomen.research.bell-labs.com 4224 Trying 135.104.70.9... Connected to nomen.research.bell-labs.com. Escape character is '^]'. 220 nomen.research.bell-labs.com Nomenclator Query Service ready relations 211-There is 1 relation defined: 211 People attributes People 212-There are 20 attributes in relation "People": 212-Given_Name 212-Middle_Name 212-Surname 212-Name_Suffix 212-Title 212-Organization 212-Division 212-Department 212-Building 212-Street 212-City 212-State_or_Province 212-Postal_Code 212-Country 212-Phone 212-Fax 212-Email 212-MHSmail 212-Last_Modified 212 Source Figure 1a: New User Queries Server ---------------------------------------------------------------------Elliott & Ordille Informational [Page 5] RFC 2259 SNQP January 1998 --------------------------------------------------------------------- query 350 Send the query text, end with . select * from People where given_name = "J*" and surname = "Ordille" and organization = "Lucent Tech*"; . 351 Partial response follows, ended with . Given_Name: Joann Middle_Name: J. Surname: Ordille Title: MTS Organization: Lucent Technologies Division: Bell Laboratories Department: Computing Sciences Research Center Building: 2C-301 Street: 700 Mountain Avenue City: Murray Hill State_or_Province: New Jersey Postal_Code: 07974 Country: United States Phone: +1 908 582 7114 Email: joann@bell-labs.com Source: nomen://bell-labs.com:17036/email=joann@bell-labs.com . 250 All queries processed. Current through 11-Jun-1996 23:00 EDT. quit 221 nomen.research.bell-labs.com closing transmission channel Connection closed by foreign host. Figure 1b: New User Queries Server (continued) ---------------------------------------------------------------------2.2 User with CCSO and Currentness Preferences A user who is accustomed to CCSO name servers prefers CCSO word-based matching within attribute strings. Each word in the query string for an attribute must appear in some order in the response string. The wildcard "*" matches any substring within a word. The defaultElliott & Ordille Informational [Page 6] RFC 2259 SNQP January 1998 matching, illustrated in Figure 1b, is exact matching of a query string. The query string may include "*" wildcards which match any substring within the response string. Both types of matching are case insensitive. In Figure 2, the CCSO-style user connects to the SNQP server, enables csso matching, and requests some information about Ordille who works in research at a lab division of some company. The request asks for information that is more current than June 11, 1996 at 11 p.m. if it is available. --------------------------------------------------------------------- compare ccso 213 Performing ccso equality comparisons query 11-Jun-1996 23:00 350 Send the query text, end with . select given_name, surname, organization, division, department, email from People where surname = "Ordille" and department = "research" and division = "lab*"; . 351 Partial response follows, ended with . Given_Name: Joann Surname: Ordille Organization: Lucent Technologies Division: Bell Laboratories Department: Computing Sciences Research Center Email: joann@bell-labs.com . 250 All queries processed. Current through 12-Jun-1996 22:35 EDT. Figure 2: User with CCSO Preferences Queries Server ---------------------------------------------------------------------2.3 Graphical User Interface Program A user designs a Windows program as a front end to the SNQP server. In Figure 3, the program requests replies formatted for a graphical user interface program. The program submits two SQL queries, andElliott & Ordille Informational [Page 7] RFC 2259 SNQP January 1998 receives detailed responses that indicate the type and position of errors. The error messages are discussed in more detail in Section 3. --------------------------------------------------------------------- imagui 214 GUI responses enabled query 350 Send the query text, end with . select * from Peple where name = "Elliott"; . 735 00000001a000015 e Unknown relation, "Peple" 735 00000001a000027 e Attribute "name" not found in any relation used. 250 All queries processed. Current through 12-Jun-1996 22:35 EDT. query 350 Send the query text, end with .⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?