summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2958.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2958.txt')
-rw-r--r--doc/rfc/rfc2958.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2958.txt b/doc/rfc/rfc2958.txt
new file mode 100644
index 0000000..a6c616c
--- /dev/null
+++ b/doc/rfc/rfc2958.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group L. Daigle
+Request for Comments: 2958 Thinking Cat Enterprises
+Category: Informational P. Faltstrom
+ Cisco Systems Inc.
+ October 2000
+
+
+ The application/whoispp-response Content-type
+
+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 (2000). All Rights Reserved.
+
+Abstract
+
+ This document defines the expression of Whois++ protocol (RFC1835)
+ responses within MIME (Multipurpose Internet Mail Extensions)
+ (RFC2046) media types. The intention of this document, in
+ conjunction with RFC 2957 is to enable MIME-enabled mail software,
+ and other systems using Internet media types, to carry out Whois++
+ transactions.
+
+1. MIME Registration Information
+
+ To: iana@isi.edu Subject: Registration of MIME media type
+ application/whoispp-response
+
+ MIME Type name: Application
+
+ MIME subtype name: whoispp-response
+
+ Required parameters: none
+
+ Optional parameters: none
+
+ Encoding considerations: Any valid MIME encodings may be used
+
+ Security considerations: This content-type contains purely
+ descriptive information (i.e., no directives). There are security
+ considerations with regards to the appropriateness (privacy) of
+
+
+
+
+
+Daigle & Faltstrom Informational [Page 1]
+
+RFC 2958 application/whoispp-response Content-Type October 2000
+
+
+ information provided through the use of this content-type, and the
+ authenticity of the information so-provided. This content-type
+ provides no native mechanisms for authentication.
+
+ Published specification: this document
+
+ Person & email address to contact for further information:
+
+ Leslie L. Daigle
+ leslie@thinkingcat.com
+
+ Intended usage: common
+
+2. whoispp-response Syntax
+
+ The following grammar, which uses ABNF-like notation as defined in
+ [RFC2234], defines a subset of responses expected from a Whois++
+ server upon receipt of a valid Whois++ query. As such, it describes
+ the expected structure of a whoispp-response media type object.
+
+ N.B.: As outlined in the ABNF definition, rule names and string
+ literals are in the US-ASCII character set, and are case-insensitive.
+
+ server = goodmessage mnl output mnl endmessage nl
+ / badmessage nl endmessage nl
+
+ output = full / abridged / summary / handle
+
+ full = 0*(full-record / server-to-ask)
+
+ abridged = 0*(abridged-record / server-to-ask)
+
+ summary = summary-record
+
+ handle = 0*(handle-record / server-to-ask)
+
+ full-record = "# FULL " template serverhandle localhandle
+ system-nl
+ 1*(fulldata system-nl)
+ "# END" system-nl
+
+ abridged-record = "# ABRIDGED " template serverhandle localhandle
+ system-nl
+ abridgeddata
+ "# END" system-nl
+
+
+
+
+
+
+Daigle & Faltstrom Informational [Page 2]
+
+RFC 2958 application/whoispp-response Content-Type October 2000
+
+
+ summary-record = "# SUMMARY " serverhandle system-nl
+ summarydata
+ "# END" system-nl
+
+ handle-record = "# HANDLE " template serverhandle localhandle
+ system-nl
+
+ server-to-ask = "# SERVER-TO-ASK " serverhandle system-nl
+ server-to-askdata
+ "# END" system-nl
+
+ fulldata = " " attributename ": " attributevalue
+
+ abridgeddata = " " 0*( attributevalue / tab )
+
+ summarydata = " Matches: " number system-nl
+ [" Referrals: " number system-nl]
+ " Templates: " template 0*( system-nl "-"
+ template)
+
+ server-to-ask-data = " Server-Handle:" serverhandle system-nl
+ " Host-Name: " hostname system-nl
+ " Host-Port: " number system-nl
+ [" Protocol: " prot system-nl]
+ 0*(" " labelstring ": " labelstring system-nl)
+
+ attributename = 1*attrbyte
+
+ attrbyte = <%d33-127 except specialbyte>
+
+ attributevalue = longstring
+
+ template = labelstring
+
+ serverhandle = labelstring
+
+ localhandle = labelstring
+
+ hostname = labelstring
+
+ prot = labelstring
+
+ longstring = bytestring 0*( nl ( "+" / "-" ) bytestring )
+
+ bytestring = 0*charbyte
+
+ labelstring = 0*restrictedbyte
+
+
+
+
+Daigle & Faltstrom Informational [Page 3]
+
+RFC 2958 application/whoispp-response Content-Type October 2000
+
+
+ restrictedbyte = <%d32-%d255 except specialbyte>
+
+ charbyte = <%d32-%d255 except nl>
+
+ specialbyte = ":" / " " / tab / nl
+
+ tab = %d09
+
+ mnl = 1*system-nl
+
+ system-nl = nl [ 1*(message nl) ]
+
+ nl = %d13 %d10
+
+ message = [1*( messagestart "-" bytestring nl)]
+ messagestart " " bytestring nl
+
+ messagestart = "% " digit digit digit
+
+ goodmessage = [1*( goodmessagestart "-" bytestring nl)]
+ goodmessagestart " " bytestring nl
+
+ goodmessagestart= "% 200"
+
+ messagestart = "% " digit digit digit
+
+ badmessage = [1*( badmessagestart "-" bytestring nl)]
+ badmessagestart " " bytestring nl
+
+ badmessagestart = "% 5" digit digit
+
+ endmessage = endmessageclose
+
+ endmessageclose = [endmessagestart " " bytestring nl]
+ byemessage
+
+ endmessagestart = "% 226"
+
+ byemessage = byemessagestart " " bytestring nl
+
+ endmessagestart = "% 203"
+
+ number = 1*( digit )
+
+ digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
+ / "8" / "9"
+
+
+
+
+
+Daigle & Faltstrom Informational [Page 4]
+
+RFC 2958 application/whoispp-response Content-Type October 2000
+
+
+3. Security Considerations
+
+ Security issues are discussed in section 1.
+
+4. References
+
+ [ALVE95] Alvestrand H., "Tags for the Identification of Languages",
+ RFC 1766, March 1995.
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2957] Daigle, L. and P. Faltstrom, "The application/whoispp-query
+ Content-Type", RFC 2957, October 2000.
+
+ [RFC1835] Deutsch, P., Schoultz R., Faltstrom P. and C. Weider,
+ "Architecture of the WHOIS++ service", RFC 1835, August
+ 1995.
+
+ [HARR85] Harrenstein, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS",
+ RFC 954, October 1985.
+
+ [POST82] Postel J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+ [IIIR] Weider C. and P. Deutsch, "A Vision of an Integrated
+ Internet Information Service", RFC 1727, December 1994.
+
+ [WINDX] Weider, C., Fullton J. and S. Spero, "Architecture of the
+ Whois++ Index Service", RFC 1913, February 1996.
+
+5. Authors' Addresses
+
+ Leslie L. Daigle
+ Thinking Cat Enterprises
+
+ Email: leslie@thinkingcat.com
+
+
+ Patrik Faltstrom
+ Cisco Systems Inc
+ 170 W Tasman Drive SJ-13/2
+ San Jose CA 95134
+ USA
+
+ EMail: paf@cisco.com
+ URL: http://www.cisco.com
+
+
+
+
+Daigle & Faltstrom Informational [Page 5]
+
+RFC 2958 application/whoispp-response Content-Type October 2000
+
+
+6. 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 & Faltstrom Informational [Page 6]
+