idnits 2.17.1 draft-ietf-svrloc-wpyp-03.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-03-28) 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 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 6 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 9569 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) == Unused Reference: '7' is defined on line 199, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1959 (ref. '3') (Obsoleted by RFC 2255) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 1777 (ref. '8') (Obsoleted by RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '9') ** Obsolete normative reference: RFC 2068 (ref. '10') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Historic RFC: RFC 1835 (ref. '11') -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Ryan Moats 3 draft-ietf-svrloc-wpyp-03.txt AT&T 4 Expires in six months January 1998 6 The 'wp' and 'yp' Abstract Service Types 7 Filename: draft-ietf-svrloc-wpyp-03.txt 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as ``work 20 in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 This document presents definitions for the ''wp'' and ''yp'' abstract 31 services. The ''wp'' service is for finding people, while the ''yp'' 32 service if for finding general things (including people). 34 1. Introduction 36 In "Advertising Services" [1], several abstract services are 37 proposed. As specified in [2], the "wp" and "yp" abstract services 38 are documented here. The "wp" service is intended for finding 39 people, while the "yp" service is a superset that is intended for 40 finding objects. 42 2. The "wp" Abstract Service 44 The "wp" abstract service is for locating people via a directory. 45 Version 0.0 of this service specifies four protocols for accessing 46 such services: LDAP, WHOIS++, CCSO/Ph and HTTP. 48 ---------------------------template begins here----------------------- 49 type = wp 51 version = 0.0 53 language = EN 55 description = 56 The WP Abstract Service is for locating people using either LDAP, WHOIS, CCSO/Ph or HTTP 58 url-syntax = 59 url-path = ldapurl / whoisppurl / phurl / httpurl 60 ldapurl = url as defined in [3] 61 whoisppurl = url as defined in [4] 62 httpurl = url as defined in [5] 63 phurl = "ph://" hostport 64 hostport = host [ ":" port ] 65 host = hostname / hostnumber 66 hostname = *( domainlavel "." ) toplabel 67 domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum 68 toplabel = alpha / alpha * [alphanum / "-"] alphanum 69 hostnumber = ipv4-number / ipv6-number 70 ipv4-number = 1*3digit 3*3("." 1*3digit) 71 ipv6-number = 32*hex 72 3digit = digit digit digit 73 port = 1*digit 74 ; A port number must be included if the 75 ; protocol field does not have an IANA 76 ; assigned port number. 77 alphanum = alpha / digit 78 alpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / 79 "h" / "i" / "j" / "k" / "l" / "m" / "n" / 80 "o" / "p" / "q" / "r" / "s" / "t" / "u" / 81 "v" / "w" / "x" / "y" / "z" / 82 "A" / "B" / "C" / "D" / "E" / "F" / "G" / 83 "H" / "I" / "J" / "K" / "L" / "M" / "N" / 84 "O" / "P" / "Q" / "R" / "S" / "T" / "U" / 85 "V" / "W" / "X" / "Y" / "Z" 86 digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / 87 "7" / "8" / "9" 88 ---------------------------template ends here------------------------- 90 3. The "yp" Abstract Service 92 The "yp" abstract service is for locating resources on the Internet 93 and is a superset of the "wp" abstract service. Version 0.0 94 specifies the following protocols for accessing such services in 95 addition to those specified for the "wp" abstract service: Z39.50 and 96 WHOIS++. 98 ---------------------------template begins here----------------------- 99 type = yp 101 version = 0.0 103 language = EN 105 description = 106 The yp Abstract Service is for locating general resources on the internet 108 url-syntax = 109 url-path = z3950url / httpurl / whoisppurl / ldapurl 110 phurl 111 z3950url = url as defined in [6] 112 httpurl = url as defined in [5] 113 whoisppurl = url as defined in [4] 114 ldapurl = url as defined in [3] 115 phurl = "ph://" hostport 116 hostport = host [ ":" port ] 117 host = hostname / hostnumber 118 hostname = *( domainlavel "." ) toplabel 119 domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum 120 toplabel = alpha / alpha * [alphanum / "-"] alphanum 121 hostnumber = ipv4-number / ipv6-number 122 ipv4-number = 1*3digit 3*3("." 1*3digit) 123 ipv6-number = 32*hex 124 3digit = digit digit digit 125 port = 1*digit 126 ; A port number must be included if the 127 ; protocol field does not have an IANA 128 ; assigned port number. 129 alphanum = alpha / digit 130 alpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / 131 "h" / "i" / "j" / "k" / "l" / "m" / "n" / 132 "o" / "p" / "q" / "r" / "s" / "t" / "u" / 133 "v" / "w" / "x" / "y" / "z" / 134 "A" / "B" / "C" / "D" / "E" / "F" / "G" / 135 "H" / "I" / "J" / "K" / "L" / "M" / "N" / 136 "O" / "P" / "Q" / "R" / "S" / "T" / "U" / 137 "V" / "W" / "X" / "Y" / "Z" 139 digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / 140 "7" / "8" / "9" 141 ---------------------------template ends here------------------------- 143 4. Contact Information 145 The contact point for version 0.0 of both of these templates is the 146 author. 148 5. Security Considerations 150 Both of these abstract services inherit the security considerations 151 of the "service:" URL scheme as specified in [2]. As these services 152 are both abstract, they further inherit considerations from the 153 protocol used to provide the underlying concrete services as 154 discussed below. 156 5.1 Considerations for the "wp" service 158 Since the "wp" abstract service can use any of LDAP, HTTP, WHOIS or 159 CCSO/Ph, it inherits the security considerations for each of these 160 protocols. See [3] and [8] for LDAP, [9] and [10] for HTTP, [4] and 161 [11] for WHOIS, and [12] for CCSO/Ph. 163 5.2 Considerations for the "yp" service Since the "yp" abstract service 164 is a superset of the "wp" service, it inherits all the considerations 165 from the above section. In addition, it inherits the security 166 considerations from [6] for Z39.50. 168 6. Acknowledgments 170 This work described in this document is partially supported by the 171 National Science Foundation, Cooperative Agreement NCR-9218179. 173 7. References 175 Request For Comments (RFC) and Internet Drafts documents are 176 available from and numerous mirror sites 178 [1] R. Moats, M. Hamilton, "Advertising Services," Internet 179 Draft (work in progress), February 1997. 181 [2] C. Perkins, E. Guttman, J. Kempf, "Service Templates and 182 'service:' Schemes," Internet Draft (work in progress), 183 October 1997. 185 [3] T. Howes, M. Smith, "An LDAP URL Format," RFC 1959, June 186 1996. 188 [4] M. Hamilton, "WHOIS++ URL Specification," Internet Draft 189 (work in progress), May 1997. 191 [5] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform 192 Resource Locators (URL): Generic Syntax and Semantics," 193 RFC1738 as amended by RFC1808 and updated by draft-fielding- 194 url-syntax-09.txt, May 1997. (work in progress). 196 [6] R. Denenberg, J. Kunze, D. Lynch, "Uniform Resource Locators 197 for Z39.50," RFC 2056, November 1996. 199 [7] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service 200 Location Protocol," RFC 2165, June 1997. 202 [8] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access 203 Protocol", RFC 1777, March 1995. 205 [9] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer 206 Protocol -- HTTP/1.0", RFC 1945, May 1996. 208 [10] R. Fielding (et.al.), "Hypertext Transfer Protocol -- 209 HTTP/1.1", RFC 2068, January 1997. 211 [11] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, "Architec- 212 ture of the WHOIS++ Service", RFC 1835, August 1995. 214 [12] P. Pomes, R. Hedberg, "The CCSO Nameserver (Ph) Architec- 215 ture", Internet Draft (work in progress), May 1997. 217 8. Author's addresses 219 Ryan Moats 220 AT&T 221 15621 Drexel Circle 222 Omaha, NE 68135-2358 223 USA 225 Phone: +1 402 894-9456 226 EMail: jayhawk@att.com