idnits 2.17.1 draft-daigle-wppresp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 262 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2046], [RFC1835]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1998) is 9595 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2046' is mentioned on line 35, but not defined == Unused Reference: 'ALVE95' is defined on line 198, but no explicit reference was found in the text == Unused Reference: 'HARR85' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'POST82' is defined on line 210, but no explicit reference was found in the text == Unused Reference: 'IIIR' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'WINDX' is defined on line 218, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1766 (ref. 'ALVE95') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Downref: Normative reference to an Historic RFC: RFC 1835 ** Obsolete normative reference: RFC 954 (ref. 'HARR85') (Obsoleted by RFC 3912) ** Obsolete normative reference: RFC 821 (ref. 'POST82') (Obsoleted by RFC 2821) ** Downref: Normative reference to an Informational RFC: RFC 1727 (ref. 'IIIR') ** Downref: Normative reference to an Historic RFC: RFC 1913 (ref. 'WINDX') Summary: 19 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Leslie L. Daigle 3 Expires: September 11, 1998 Bunyip Information Systems Inc. 4 draft-daigle-wppresp-00.txt Patrik Faltstrom 5 Tele2/Swipnet 6 January 1998 8 The application/whoispp-response Content-type 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other docu- 19 ments at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. 31 Abstract 33 This document defines the expression of Whois++ protocol (originally 34 defined in [RFC1835], updated in [draft-asid-whoispp-02.txt]) 35 responses within MIME [RFC2046] media types. The intention of this 36 document, in conjunction with [draft-daigle-wppresp-00.txt] is 37 to enable MIME-enabled mail software, and other systems using 38 Internet media types, to carry out Whois++ transactions. 40 1. MIME Registration Information 42 To: iana@isi.edu 43 Subject: Registration of MIME media type application/whoispp-response 45 MIME Type name: Application 47 MIME subtype name: whoispp-response 49 Required parameters: none 51 Optional parameters: none 53 Encoding considerations: Any valid MIME encodings may be used 55 Security considerations: This content-type contains purely descriptive 56 information (i.e., no directives). There are security considerations 57 with regards to the appropriateness (privacy) of information provided 58 through the use of this content-type, and the authenticity of the 59 information so-provided. This content-type provides no native 60 mechanisms for authentication. 62 Published specification: this document 64 Person & email address to contact for further information: 66 Leslie L. Daigle 67 leslie@bunyip.com 69 Intended usage: common 71 2. whoispp-response Syntax 73 The following grammar, which uses ABNF-like notation as defined in 74 [RFC2234], defines a subset of responses expected from a Whois++ server 75 upon receipt of a valid Whois++ query. As such, it describes the 76 expected structure of a whoispp-response media type object. 78 N.B.: As outlined in the ABNF definition, rule names and string 79 literals are in the US-ASCII character set, and are case-insensitive. 81 server = goodmessage mnl output mnl endmessage nl 82 / badmessage nl endmessage nl 84 output = full / abridged / summary / handle 86 full = 0*(full-record / server-to-ask) 88 abridged = 0*(abridged-record / server-to-ask) 90 summary = summary-record 92 handle = 0*(handle-record / server-to-ask) 94 full-record = "# FULL " template serverhandle localhandle 95 system-nl 96 1*(fulldata system-nl) 97 "# END" system-nl 99 abridged-record = "# ABRIDGED " template serverhandle localhandle system-nl 100 abridgeddata 101 "# END" system-nl 103 summary-record = "# SUMMARY " serverhandle system-nl 104 summarydata 105 "# END" system-nl 107 handle-record = "# HANDLE " template serverhandle localhandle system-nl 109 server-to-ask = "# SERVER-TO-ASK " serverhandle system-nl 110 server-to-askdata 111 "# END" system-nl 113 fulldata = " " attributename ": " attributevalue 115 abridgeddata = " " 0*( attributevalue / tab ) 117 summarydata = " Matches: " number system-nl 118 [" Referrals: " number system-nl] 119 " Templates: " template 0*( system-nl "-" 120 template) 122 server-to-ask-data = " Server-Handle:" serverhandle system-nl 123 " Host-Name: " hostname system-nl 124 " Host-Port: " number system-nl 125 [" Protocol: " prot system-nl] 126 0*(" " labelstring ": " labelstring system-nl) 128 attributename = 1*attrbyte 130 attrbyte = <%d33-127 except specialbyte> 132 attributevalue = longstring 134 template = labelstring 136 serverhandle = labelstring 138 localhandle = labelstring 140 hostname = labelstring 142 prot = labelstring 144 longstring = bytestring 0*( nl ( "+" / "-" ) bytestring ) 146 bytestring = 0*charbyte 148 labelstring = 0*restrictedbyte 150 restrictedbyte = <%d32-%d255 except specialbyte> 152 charbyte = <%d32-%d255 except nl> 154 specialbyte = ":" / " " / tab / nl 156 tab = %d09 158 mnl = 1*system-nl 160 system-nl = nl [ 1*(message nl) ] 162 nl = %d13 %d10 164 message = [1*( messagestart "-" bytestring nl)] 165 messagestart " " bytestring nl 167 messagestart = "% " digit digit digit 169 goodmessage = [1*( goodmessagestart "-" bytestring nl)] 170 goodmessagestart " " bytestring nl 172 goodmessagestart= "% 200" 174 messagestart = "% " digit digit digit 176 badmessage = [1*( badmessagestart "-" bytestring nl)] 177 badmessagestart " " bytestring nl 179 badmessagestart = "% 5" digit digit 181 endmessage = endmessageclose 183 endmessageclose = [endmessagestart " " bytestring nl] 184 byemessage 186 endmessagestart = "% 226" 188 byemessage = byemessagestart " " bytestring nl 190 endmessagestart = "% 203" 192 number = 1*( digit ) 194 digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 196 3. References 198 [ALVE95] Alvestrand H., "Tags for the Identification of 199 Languages", RFC 1766, UNINETT, March 1995. 201 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for 202 Syntax Specifications: ABNF", RFC 2234, November 1997. 203 [RFC1835] Deutsch, P., R. Schoultz, P. Faltstrom and C. 204 Weider. "Architecture of the WHOIS++ service", 205 RFC 1835. August 1995. 207 [HARR85] Harrenstein K., Stahl M., and E. Feinler, 208 "NICNAME/WHOIS", RFC 954, SRI, October 1985. 210 [POST82] Postel J., "Simple Mail Transfer Protocol", STD 10, 211 RFC 821, USC/Information Sciences Institute, 212 August 1982. 214 [IIIR] Weider C., and P. Deutsch, "A Vision of an 215 Integrated Internet Information Service", RFC 1727 216 Bunyip Information Systems, Inc., December 1994. 218 [WINDX] Weider, C., J. Fullton, and S. Spero, "Architecture 219 of the Whois++ Index Service", RFC 1913, February 220 1996. 222 4. Authors Addresses 224 Leslie L. Daigle 225 Bunyip Information Systems Inc. 226 310 Ste. Catherine St. W 227 Suite 300 228 Montreal, Quebec, CANADA 229 H2X 2A1 231 Email: leslie@bunyip.com 233 Patrik Faltstrom 234 Tele2 235 Borgarfjordsgatan 16 236 BOX 62 237 194 64 Kista 238 SWEDEN 240 Email: paf@swip.net