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

📄 rfc1835.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 5 页
字号:
   generate any output as a formatted response, although it must still   generate system messages.Deutsch, et al              Standards Track                    [Page 25]RFC 1835          Architecture of the WHOIS++ service        August 1995   For information about the format for system messages, see Appendix E.2.4.3.  Syntax of a Formatted Response   All formatted responses except for the HANDLE response, consists of a   response-specific START line, followed by an optional response-   specific data section, followed by a TERMINATION line.  The HANDLE   response is different in that it only consists of a START line.  It   is permissible to insert any number of lines consisting solely of   newlines within a formatted response to improve readibility.   Each line shall be limited to no more than 81 characters, including   the terminating newline.  If a line (including the required leading   single space) would exceed 81 characters, it is to be broken into   lines of no more than 81 characters, with each continuation line   beginning with a "+" character in the first column instead of the   leading character.   If an attribute value in a data section includes a line break, the   line break must be replaced by a CR/LF pair and the following line   begin with a "-" character in the first column, instead of the   leading character. The attribute name is not repeated on consecutive   lines.   A TERMINATION line consists of a line with a '#' in the first column,   followed by one white space character (SPACE or TAB), followed by the   keyword END, followed by zero or more characters, followed by a   newline.   A response-specific section will be one of the following:       1) FULL Format Response       2) ABRIDGED Format Response       3) HANDLE Format Response       4) SUMMARY Format Response       5) SERVER-TO-ASK Format Response        The details of each are specified in the following sections:2.4.3.1.  A FULL format response   A FULL format response consists of a series of responses, each   consisting of a START line, followed by the complete template   information for the matching record and a TERMINATION line.   Each START line consists of a '#' in the first column, followed by   one white space character, the word "FULL", a white space character,   the name of the corresponding template type, one white spaceDeutsch, et al              Standards Track                    [Page 26]RFC 1835          Architecture of the WHOIS++ service        August 1995   character, the server handle, a white space character, an optional   handle for the record, and a terminating newline.   The template information for the record will be returned as a series   of lines consisting of a single space, followed by the corresponding   line of the record.   The line of the record shall consist of a single space and the   attribute name followed by a ':', a single space, the value of that   attribute, and a newline.2.4.3.2.  ABRIDGED Format Response   Each ABRIDGED format response consists of a START line, a single line   excerpt of the template information from each matching record and a   TERMINATION line. The excerpt information shall include information   that is relevant to the template type.   The START line consists of a '#' in the first column, followed by one   white space character, the word "ABRIDGED", a white space character,   the name of the corresponding template type, a white space character,   the server handle, a white space character, the handle for the   record, and a terminating newline.   The abridged template information will be returned as a line,   consisting of a single space, followed by the abridged line of the   record and a newline pair.2.4.3.3.  HANDLE Format Response   A HANDLE response consists of a single START line, which shall start   with a '#' in the first column, followed by one white space   character, the word "HANDLE", a white space character, the name of   the corresponding template, a white space character, the handle for   the server, a white space character, the handle for that record, and   a terminating newline.2.4.3.4.  SUMMARY Format Response   A SUMMARY format response consists of a single set of responses,   consisting of a line listing the number of matches to the specified   query, followed by a list of all template types which satisfied the   query at least once.   The START line shall begin with a '#' in the first column, be   followed by one white space character, the word "SUMMARY", a white   space character, the handle for the server, and a terminating   newline.Deutsch, et al              Standards Track                    [Page 27]RFC 1835          Architecture of the WHOIS++ service        August 1995   All following lines until the TERMINATION line starts with a leading   space.  The first line shall begin with the string "matches: ", be   followed by a space and the number of responses to the query and   terminated by a newline.  The second line shall begin with the string   "templates: ", be followed by a newline separated list of the name of   the template types which matched the query.  Each line following the   first which include the text "templates:" must begin with a '-'   instead of a space.2.4.3.5.  SERVER-TO-ASK Response   A SERVER-TO-ASK response consists of information to the client about   a server to contact next to resolve a query.  If the server has   pointers to more than one server, it will present additional SERVER-   TO-ASK responses.   The SERVER-TO-ASK response will consist of a START line and a number   of lines with attribute-value pairs, separated by CRLF. Each line is   indented with one space. The end of a SERVER-TO-ASK response is   indicated with a TERMINATION line.   Each START line consists of a '#' in the first column, followed by   one white space character, the word "SERVER-TO-ASK", a white space   character, the handle of the server and a terminating newline.   1. "Server-Handle" - The server handle of the server pointed at.      (req.)   2. "Host-Name" - A cached host named for the server pointed at. (opt.)   3. "Host-Port" - A cached port number for the server pointed at.      (opt.)   Other attributes may be present, depending on the index server.2.4.4.  System Generated Messages   All system generated messages must begin with a '%' as the first   character, a space as the second one, followed by a three digit   number, a space and an optional text message. The total length of the   line must be no more than 81 characters long, including the   terminating CR LF pair. There is no limit to the number of system   messages that may be generated.   The format for multiline replies requires that every line, except the   last, begin with "%", followed by space, the reply code, a hyphen,   and an optional text.  The last line will begin with "%", followed by   space, the reply code, a space and some optional text.Deutsch, et al              Standards Track                    [Page 28]RFC 1835          Architecture of the WHOIS++ service        August 1995   System generated messages displayed before or after the formatted   response section are expected to refer to operation of the system or   refer to the entire query. System generated messages within the   output of an individual record during a FULL reponse are expected to   refer to that record only, and could (for example) be used to   indicate problems with that record of the response. See Appendix E   for a description of system messages.2.5.  Compatibility with Older WHOIS Servers   Note that this format, although potentially more verbose, is still in   a human readible form. Responses from older systems that do not   follow this format are still conformant, since their responses would   be interpreted as being equivalent to optional text messages, without   a formatted response.  Clients written to this specification would   display the responses as a advisory text message, where it would   still be readible by the user.3.  Miscellaneous3.1.  Acknowledgements   The WHOIS++ effort began as an intensive brainstorming session at the   24th IETF, in Boston Massachusetts.  Present at the birth, and   contributing ideas through this early phase, were (alphabetically)   Peter Deutsch, Alan Emtage, Jim Fullton, Joan Gargano, Brad   Passwaters, Simon Spero, and Chris Weider. Others who have since   helped shape this document with feedback and suggestions include   Roxana Bradescu, Patrik Faltstrom, Kevin Gamiel, Dan Kegel, Michael   Mealling, Mark Prior and Rickard Schoultz.3.2  References   [ALVE95]        Alvestrand H., "Tags for the Identification of                   Languages", RFC 1766, UNINETT, March 1995.   [HARR85]        Harrenstein K., Stahl M., and E. Feinler,                   "NICNAME/WHOIS", RFC 954, SRI, October 1985.   [IIIR]          Weider C., and P. Deutsch, "A Vision of an                   Integrated Internet Information Service", RFC 1727                   Bunyip Information Systems, Inc., December 1994.   [POST82]        Postel J., "Simple Mail Transfer Protocol", STD 10,                   RFC 821, USC/Information Sciences Institute,                   August 1982.Deutsch, et al              Standards Track                    [Page 29]RFC 1835          Architecture of the WHOIS++ service        August 19953.3.  Authors' Addresses   Peter Deutsch   BUNYIP INFORMATION SYSTEMS, Inc.   310 St-Catherine St West,   Suite 202,   Montreal, Quebec H2X 2A1   CANADA   EMail: peterd@bunyip.com   Rickard Schoultz   KTHNOC, SUNET/NORDUnet/Ebone Operations Centre   100 44 STOCKHOLM   SWEDEN   EMail: schoultz@sunet.se   Patrik Faltstrom   BUNYIP INFORMATION SYSTEMS, Inc.   310 St-Catherine St West,   Suite 202,   Montreal, Quebec H2X 2A1   CANADA   EMail: paf@bunyip.com   Chris Weider   BUNYIP INFORMATION SYSTEMS, Inc.   2001 S. Huron Parkway, #12   Ann Arbor, MI 48104   USA   EMail: clw@bunyip.comDeutsch, et al              Standards Track                    [Page 30]RFC 1835          Architecture of the WHOIS++ service        August 1995Appendix A - Some Sample Queries       author=chris and template=user   The result will consist of all records where attribute "author"   matches "chris" with case ignored. Only USER templates will be   searched. An example of a matching record is "Author=Chris Weider".   This is the typical case of search.       schoultz and rick;search=lstring   The result will consist of all records which have one attribute value   matching "schoultz" exactly and one having "rick" as leading   substring, both with case ignored. One example is "Name=Rickard   choultz".       value=phone;search=substring   The result will consist of all records which have attribute values   matching *phone*, for example the record "Name=Acme telephone inc.",   but will not match the attribute name "phone". (Since "value" term   specifier is the default, the search term could be "phone" as well as   "value=phone".)       search-all=Peter ; search=substring;case=consider   The result will consist of all records which have attribute names,   template names or attribute values matching "Peter" with respect to   case. One example is "Friend-Of-Peter: Yes".      ucdavis;search=substring and (gargano or joan):include=name,email   This search command will find records which have records containing   the words "gargano" or "joan" somewhere in the record, and has the   word "ucdavis" somewhere in a word. The result will only show the   "name" and "email" fields.Appendix B - Some sample responses      1) FULL format responses:      # FULL USER SERVERHANDLE1 PD45       Name: Peter Deutsch       email: peterd@bunyip.com      # END      # FULL USER SERVERHANDLE1 AE1       Name: Alan Emtage       email: bajan@bunyip.comDeutsch, et al              Standards Track                    [Page 31]RFC 1835          Architecture of the WHOIS++ service        August 1995      # END      # FULL USER SERVERHANDLE1 NW1       Name: 

⌨️ 快捷键说明

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