idnits 2.17.1 draft-ietf-asid-x500-url-02.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-26) 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 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. ** The abstract seems to contain references ([4], [2,3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (11 October 1995) is 10425 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) ** Obsolete normative reference: RFC 1738 (ref. '1') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational draft: draft-howes-x500-schema (ref. '4') Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 X.500 URI Attribute Types and Object Class Mark Smith 2 INTERNET-DRAFT University of Michigan 3 11 October 1995 5 Definition of X.500 Attribute Types and an Object Class to Hold 6 Uniform Resource Identifiers (URIs) 7 Filename: draft-ietf-asid-x500-url-02.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 20 ``work 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 ds.internic.net (US East Coast), 25 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 26 munnari.oz.au (Pacific Rim). 28 Distribution of this memo is unlimited. Editorial comments should be 29 sent to the author (mcs@umich.edu). Technical discussion will take 30 place on the IETF ASID mailing list (ietf-asid@umich.edu). 32 This Internet Draft expires April 11, 1995. 34 Abstract 36 Uniform Resource Locators (URLs) are being widely used to specify the 37 location of Internet resources. There is an urgent need to be able 38 to include URLs in the X.500 directory, and a desire to include other 39 types of Uniform Resource Identifiers (URIs) as they are defined. A 40 number of independent groups are already experimenting with the 41 inclusion of URLs in the X.500 directory. This document builds on 42 the experimentation to date and defines two new attribute types and 43 an auxiliary object class to allow URIs, including URLs, to be stored 44 in directory entries in a standard way. 46 Background and Intended Usage 48 Uniform Resource Locators (URLs) as defined by [1] are the first of 49 several types of Uniform Resource Identifiers (URIs) being defined by 50 the IETF. This document defines two X.500 [2,3] attribute types 51 (labeledURI and labeledURL) and an auxiliary object class 52 (labeledURIObject) to hold all types of URIs, including URLs. It is 53 assumed that as other kinds of URIs are defined, additional attribute 54 types may be created to support storing them in directory entries. 56 The rationale for adding separate attribute types for the different 57 kinds of URIs is to support efficient programmatic access to specific 58 types of URIs. For example, if an indexing service is only 59 interested in URLs, having them available in their own attribute 60 makes pulling them out of a directory entry straightforward and 61 efficient. 63 It is intended that the schema elements defined in this document will 64 be progressed according to the process defined by the Internet X.500 65 Schema Working Group [4]. 67 Schema Definition of the labeledURL Attribute Type 69 Name: labeledURL 70 ShortName: None 71 Description: Uniform Resource Locator with optional label 72 OID: umichAttributeType.41 (1.3.6.1.4.1.250.1.41) 73 Syntax: caseExactString 74 SizeRestriction: None 75 SingleValued: False 77 Discussion of the labeledURL Attribute Type 79 The labeledURL attribute type has the caseExactString syntax (since 80 URLs are case-sensitive) and it is multivalued. Values placed in the 81 attribute should consist of a URL as defined in [1] optionally 82 followed by one or more space characters and a label. Since space 83 characters are not allowed to appear un-encoded in URLs, there is no 84 ambiguity about where the label begins. Multiple labeledURL values 85 will generally indicate different resources that are all related to 86 the X.500 object, but may indicate different locations for the same 87 resource. 89 The label is used to describe the resource to which the URL points, 90 and is intended as a friendly name fit for human consumption. This 91 document does not propose any specific syntax for the label part. 92 Note that in some cases it may be helpful to include in the label 93 some indication of the kind and/or size of the resource referenced by 94 the URL. 96 Note that the label may include any characters allowed by the 97 caseExactString syntax, but that the use of non-IA5 (non-ASCII) 98 characters is discouraged as not all directory clients may handle 99 them in the same manner. 101 Some examples of valid labeledURL values (the first does not have a 102 label): 104 ftp://ds.internic.net/rfc/rfc822.txt 106 http://www.umich.edu/ University of Michigan Home Page 108 http://champagne.inria.fr/Unites/rennes.gif Rennes [photo] 110 Schema Definition of the labeledURI Attribute Type 112 Name: labeledURI 113 ShortName: None 114 Description: Uniform Resource Identifier with optional label 115 OID: umichAttributeType.57 (1.3.6.1.4.1.250.1.57) 116 Syntax: caseExactString 117 SizeRestriction: None 118 SingleValued: False 120 Discussion of the labeledURI Attribute Type 122 The labeledURI attribute type has the caseExactString syntax (since 123 URIs are case-sensitive) and it is multivalued. Values placed in the 124 attribute should consist of a URI (at the present time, a URL) 125 optionally followed by one or more space characters and a label. 126 Since space characters are not allowed to appear un-encoded in URIs, 127 there is no ambiguity about where the label begins. At the present 128 time, the URI portion must comply with the URL specification [1]. 129 Multiple labeledURI values will generally indicate different 130 resources that are all related to the X.500 object, but may indicate 131 different locations for the same resource. 133 The label is used to describe the resource to which the URI points, 134 and is intended as a friendly name fit for human consumption. This 135 document does not propose any specific syntax for the label part. 136 Note that in some cases it may be helpful to include in the label 137 some indication of the kind and/or size of the resource referenced by 138 the URI. 140 Note that the label may include any characters allowed by the 141 caseExactString syntax, but that the use of non-IA5 (non-ASCII) 142 characters is discouraged as not all directory clients may handle 143 them in the same manner. 145 Schema Definition of the labeledURIObject Object Class 147 Name: labeledURIObject 148 Description: object that contains the URI attribute types 149 OID: umichObjectClass.15 (1.3.6.1.4.1.250.3.15) 150 SubclassOf: top 151 MustContain: 152 MayContain: labeledURI, labeledURL 154 Discussion of the labeledURIObject Object Class 156 The labeledURIObject class is a subclass of top and may contain the 157 labeledURI and labeledURL attributes. The intent is that this object 158 class can be added to existing directory objects to allow for 159 inclusion of URI values. This approach does not preclude including 160 the labeledURI and labeledURL attribute types directly in other 161 object classes as appropriate. 163 References 165 [1] Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform 166 Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, 167 University of Minnesota, December 1994, 168 170 [2] The Directory: Overview of Concepts, Models and Service. CCITT 171 Recommendation X.500, 1988. 173 [3] Information Processing Systems -- Open Systems Interconnection -- 174 The Directory: Overview of Concepts, Models and Service. ISO/IEC JTC 175 1/SC21; International Standard 9594-1, 1988. 177 [4] Howes, T., Rossen, K., Sataluri, S., and Wright, R., "Procedures 178 for Formalizing, Evolving, and Maintaining the Internet X.500 179 Directory Schema", Internet Draft (Work In Progress) of the Schema 180 Working Group, 183 Security Considerations 185 Security considerations are not discussed in this memo. 187 Acknowledgments 189 Paul-Andre Pays, Martijn Koster, Tim Howes, Rakesh Patel, and Russ 190 Wright provided invaluable assistance in the creation of this 191 document. 193 This material is based upon work supported by the National Science 194 Foundation under Grant No. NCR-9416667. 196 Author's Address 198 Mark Smith 199 University of Michigan 200 Information Technology Division 201 535 W. William St. 202 Ann Arbor, MI 48103-4943, USA 203 Phone: +1 313 764-2277 204 Fax: +1 313 765-5140 205 EMail: mcs@umich.edu 207 This Internet Draft expires April 11, 1995.