idnits 2.17.1 draft-smith-rfc2079bis-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 138: '... SUP top AUXILIARY MAY labeledURI )...' -- The abstract seems to indicate that this document obsoletes RFC2079, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 247 has weird spacing: '...for the purpo...' -- 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 (22 February 2002) is 8098 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 section? 'RFC2396' on line 181 looks like a reference -- Missing reference section? 'RFC2854' on line 185 looks like a reference -- Missing reference section? 'RFC2251' on line 172 looks like a reference -- Missing reference section? 'X500' on line 189 looks like a reference -- Missing reference section? 'RFC2252' on line 176 looks like a reference -- Missing reference section? 'ISO-10646' on line 81 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Smith 3 INTERNET-DRAFT Netscape Communications Corp. 4 Intended Category: Standards Track 22 February 2002 5 Expires: August 2002 7 Definition of an Attribute Type and an Object Class to Hold 8 Uniform Resource Identifiers (URIs) 9 11 1. Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. Internet-Drafts are working documents of 15 the Internet Engineering Task Force (IETF), its areas, and its work- 16 ing groups. Note that other groups may also distribute working docu- 17 ments as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. Technical discussion of this 31 document should take place on the IETF LDAP Extension Working Group 32 mailing list . Please send editorial com- 33 ments directly to the author . After appropriate 34 review and discussion, this document will be submitted as a Standards 35 Track replacement for RFC 2079. 37 Copyright (C) The Internet Society (1997-2002). All Rights Reserved. 39 Please see the Full Copyright Statement section near the end of this 40 document for more information. 42 2. Abstract 44 Uniform Resource Identifiers (URIs) are widely used to specify the 45 location of Internet resources. This document defines an attribute 46 type and an auxiliary object class to allow URIs, including URLs, to 47 be stored in LDAP and X.500 directory entries in a standard way. 49 This document replaces RFC 2079. See Appendix A for a list of 50 changes relative to RFC 2079. 52 3. Background and Intended Usage 54 Uniform Resource Identifiers (URIs) as defined by [RFC2396] are 55 widely used on the Internet, most notably within Hypertext Markup 56 Language [RFC2854] documents. This document defines an attribute type 57 called labeledURI and an auxiliary object class called labeledURIOb- 58 ject to hold all types of URIs, including URLs. These definitions 59 are designed for use in LDAP[RFC2251] and X.500[X500] directories, 60 and may be used in other contexts as well. 62 The attribute type and object class definitions in this document are 63 written using the BNF form of AttributeTypeDescription and 64 ObjectClassDescription given in [RFC2252]. Lines have been folded 65 for readability. 67 4. Schema Definition of the labeledURI Attribute Type 69 ( 1.3.6.1.4.1.250.1.57 70 NAME 'labeledURI' 71 EQUALITY caseExactMatch 72 SUBSTR caseExactSubstringsMatch 73 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 75 5. Discussion of the labeledURI Attribute Type 77 The labeledURI attribute type has DirectoryString syntax, uses 78 caseExact matching rules (since URIs are case-sensitive) and it is 79 multivalued. Values placed in the attribute should consist of a URI 80 (typically, a URL) optionally followed by one or more ASCII space 81 characters (code U+00020 in ISO/IEC 10646-1[ISO-10646]) and a label. 82 Since ASCII space characters are not allowed to appear in URIs, there 83 is no ambiguity about where the label begins. The URI portion must 84 comply with the URI syntax specification [RFC2396]. Multiple 85 labeledURI values will generally indicate different resources that 86 are all related to the directory entry, but may indicate different 87 locations for the same resource. 89 The label is used to describe the resource to which the URI 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. In 92 some cases it may be helpful to include in the label some indication 93 of the kind and/or size of the resource referenced by the URI. 95 Note that the EQUALITY matching rule matches against the entire 96 value, so labeledURI attribute values that differ only in label are 97 not equivalent. For example, the asserted value: 99 ftp://ftp.ietf.org/rfc/rfc2251.txt 101 does not match the attribute value: 103 ftp://ftp.ietf.org/rfc/rfc2251.txt LDAPv3 Protocol RFC 105 Also, the label is not restricted by the rules that govern the syntax 106 of URIs; in particular, any character supported by the Directory- 107 String syntax can be used in the label portion of the value. HTML 108 conventions should not be used to represent non-ASCII characters in 109 the label portion of a labeledURI value, e.g., the ISO 10646-1 LATIN 110 CAPITAL LETTER A WITH RING ABOVE (U+000C5) character should be 111 represented using the UTF-8 encoding of the character (the octet 112 sequence C3 85) and not the HTML escape sequence "å". 114 6. Examples of labeledURI Attribute Values 116 An example of a labeledURI attribute value that does not include a 117 label: 119 ftp://ftp.ietf.org/rfc/rfc0822.txt 121 An example of a labeledURI attribute value that contains a tilde 122 character in the URL (special characters in a URL must be encoded as 123 specified by the URI document [RFC2396]). The label is "UMich LDAP 124 Home Page": 126 http://www.umich.edu/%7Edirsvcs/ldap/ UMich LDAP Home Page 128 Another example. This one includes a hint in the label to help the 129 user realize that the URL points to a photo image. 131 http://www.salford.ac.uk/its024/chadwick.gif David Chadwick [photo] 133 7. Schema Definition of the labeledURIObject Object Class 135 ( 1.3.6.1.4.1.250.3.15 136 NAME 'labeledURIObject' 137 DESC 'object that contains the URI attribute type' 138 SUP top AUXILIARY MAY labeledURI ) 140 8. Discussion of the labeledURIObject Object Class 142 The labeledURIObject class is a subclass of top and may contain the 143 labeledURI attribute. The intent is that this object class can be 144 added to existing directory objects to allow for inclusion of URI 145 values. This approach does not preclude including the labeledURI 146 attribute type directly in other object classes as appropriate. 148 9. Security Considerations 150 Blindly inserting the label portion of a labeledURI attribute value 151 into an HTML document is not recommended, as this may allow a mali- 152 cious individual to include HTML tags in the label that mislead 153 viewers of the entire document in which the labeledURI value was 154 inserted. 156 10. Acknowledgments 158 Paul-Andre Pays, Martijn Koster, Tim Howes, Rakesh Patel, Russ 159 Wright, Hallvard Furuseth, Mark Wahl, and Kurt Zeilenga provided 160 valuable assistance in the creation of this document. 162 This material is based in part upon work supported by the National 163 Science Foundation under Grant No. NCR-9416667. 165 11. Bibliography 167 [ISO-10646]] 168 ISO/IEC 10646-1:1993. International Standard -- Information 169 technology -- Universal Multiple-Octet Coded Character Set (UCS) 170 -- Part 1: Architecture and Basic Multilingual Plane. 172 [RFC2251] 173 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Pro- 174 tocol (v3)", RFC 2251, December 1997. 176 [RFC2252] 177 M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins, 178 "Lightweight Directory Access Protocol (v3): Attribute Syntax 179 Definitions", RFC 2252, December 1997. 181 [RFC2396] 182 T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource 183 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 185 [RFC2854] 186 The 'text/html' Media Type. D. Connolly, L. Masinter, RFC 2854, 187 June 2000. 189 [X500] 190 Information Processing Systems -- Open Systems Interconnection 191 -- The Directory: Overview of Concepts, Models and Service. 192 ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988. 194 12. Author's Address 196 Mark Smith 197 Netscape Communications Corp. 198 447 Marlpool Drive 199 Saline, MI 48176-1519 200 USA 201 +1 650 937-3477 202 mcs@netscape.com 204 13. Appendix A: Changes Since RFC 2079 206 Updated schema definitions to use X.500(93) and RFC 2252 conventions. 207 The labeledURIObject object class is an auxiliary class. 209 Revised note about use of non-IA5 characters in labels to discuss 210 UTF-8 instead of T.61. 212 Added a note about the EQUALITY matching rule matching against the 213 entire value, including the label. 215 Updated the URLs in the examples. 217 Adjusted references: replaced RFC 1738 with RFC 2396, replaced RFC 218 1866 with RFC 2854, added references to RFCs 2251 and 2252. 220 Minor revision to Security Considerations section: removed leading 221 "Security considerations are not discussed in this memo, except..." 222 phrase. 224 Removed the appendix that described the deprecated labeledURL attri- 225 bute type. 227 Updated Author's Address. 229 Added "Full Copyright Statement" section 231 Added a table of contents. 233 Updated the acknowledgments section. 235 14. Full Copyright Statement 237 Copyright (C) The Internet Society (1997-2002). All Rights Reserved. 239 This document and translations of it may be copied and furnished to 240 others, and derivative works that comment on or otherwise explain it 241 or assist in its implementation may be prepared, copied, published 242 and distributed, in whole or in part, without restriction of any 243 kind, provided that the above copyright notice and this paragraph are 244 included on all such copies and derivative works. However, this 245 document itself may not be modified in any way, such as by removing 246 the copyright notice or references to the Internet Society or other 247 Internet organizations, except as needed for the purpose of develop- 248 ing Internet standards in which case the procedures for copyrights 249 defined in the Internet Standards process must be followed, or as 250 required to translate it into languages other than English. 252 The limited permissions granted above are perpetual and will not be 253 revoked by the Internet Society or its successors or assigns. 255 This document and the information contained herein is provided on an 256 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 257 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 258 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 259 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 260 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 This Internet Draft expires in August 2002. 264 1. Status of this Memo............................................1 265 2. Abstract.......................................................1 266 3. Background and Intended Usage..................................2 267 4. Schema Definition of the labeledURI Attribute Type.............2 268 5. Discussion of the labeledURI Attribute Type....................2 269 6. Examples of labeledURI Attribute Values........................3 270 7. Schema Definition of the labeledURIObject Object Class.........4 271 8. Discussion of the labeledURIObject Object Class................4 272 9. Security Considerations........................................4 273 10. Acknowledgments................................................4 274 11. Bibliography...................................................4 275 12. Author's Address...............................................5 276 13. Appendix A: Changes Since RFC 2079.............................5 277 14. Full Copyright Statement.......................................6