idnits 2.17.1 draft-mcwalter-uri-mib-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (March 20, 2007) is 6219 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF D. McWalter, Ed. 3 Internet-Draft Data Connection Ltd 4 Proposed Status: Standards Track March 20, 2007 5 Expires: September 21, 2007 7 MIB Textual Conventions for Uniform Resource Identifiers (URIs) 8 draft-mcwalter-uri-mib-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 21, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This MIB module defines textual conventions to represent STD 66 42 Uniform Resource Identifiers (URIs). The intent is that these 43 textual conventions will be imported and used in MIB modules that 44 would otherwise define their own representation(s). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. The Internet-Standard Management Framework . . . . . . . . . . 3 51 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 55 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 57 8.2 Informative References . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . 9 61 1. Introduction 63 This memo defines a portion of the Management Information Base (MIB) 64 for use with network management protocols in the Internet community. 65 It defines textual conventions to represent STD 66 [RFC3986] URIs, 66 which are further described by [RFC3305]. 68 Three textual conventions are defined, one of unrestricted length, 69 and two of different restricted lengths. Which length is appropriate 70 will depend on tradeoffs made in particular MIB modules. The purpose 71 of providing standard restricted-length textual conventions is to 72 improve compatibility between MIB modules that require restricted- 73 length URIs. 75 If a URI needs to be used as an index object, then the 'Uri' textual 76 convention SHOULD be subtyped to a length appropriate for the OID of 77 which it is part. The description of the 'Uri' textual convention 78 discusses this case. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 3. The Internet-Standard Management Framework 88 For a detailed overview of the documents that describe the current 89 Internet-Standard Management Framework, please refer to section 7 of 90 RFC 3410 [RFC3410]. 92 Managed objects are accessed via a virtual information store, termed 93 the Management Information Base or MIB. MIB objects are generally 94 accessed through the Simple Network Management Protocol (SNMP). 95 Objects in the MIB are defined using the mechanisms defined in the 96 Structure of Management Information (SMI). This memo specifies a MIB 97 module that is compliant to the SMIv2, which is described in STD 58, 98 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 99 [RFC2580]. 101 4. Definitions 103 URI-TC-MIB DEFINITIONS ::= BEGIN 105 IMPORTS 106 MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] 107 TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] 109 uriTcMIB MODULE-IDENTITY 110 LAST-UPDATED "200703200000Z" -- 20 March 2007 111 ORGANIZATION "IETF Operations and Management (OPS) Area" 112 CONTACT-INFO "EMail: ops-area@ietf.org 113 Home page: http://www.ops.ietf.org/" 114 DESCRIPTION 115 "This MIB module defines textual conventions for 116 representing URIs, as defined by RFC 3986 STD 66." 117 REVISION "200703200000Z" -- 20 March 2007 118 DESCRIPTION 119 "Initial revision, published as RFC yyyy. 121 Copyright (C) The IETF Trust (2007). This version of this 122 MIB module is part of RFC yyyy; see the RFC itself for full 123 legal notices." 124 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 125 ::= { mib-2 XXX } 126 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 128 Uri ::= TEXTUAL-CONVENTION 129 DISPLAY-HINT "1a" 130 STATUS current 131 DESCRIPTION 132 "A Uniform Resource Identifier (URI) as defined by STD 66. 134 Objects using this textual convention MUST be in US-ASCII 135 encoding, and MUST be normalized as described by RFC 3986 136 sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 137 percent-encoding is removed, and all case-insensitive 138 characters are set to lowercase except for hexadecimal 139 digits, which are normalized to uppercase as described in 140 section 6.2.2.1. 142 The purpose of this normalization is to help provide unique 143 URIs. Note that this normalization is not sufficient to 144 provide uniqueness. Two URIs that are textually distinct 145 after this normalization may still be equivalent. 147 Objects using this textual convention MAY restrict the 148 schemes that they permit. For example, 'data:' and 'urn:' 149 schemes might not be appropriate. 151 A zero-length URI is not a valid URI. This can be used to 152 express 'URI absent' where required, for example when used 153 as an index field. 155 Where this textual convention is used for an index field, 156 it MUST be subtyped to restrict its length. There is an 157 absolute limit of 128 subids for an OID, and it is not 158 efficient to have OIDs whose length approaches this limit." 159 REFERENCE "RFC 3986 STD 66 and RFC 3305" 160 SYNTAX OCTET STRING 162 Uri255 ::= TEXTUAL-CONVENTION 163 DISPLAY-HINT "255a" 164 STATUS current 165 DESCRIPTION 166 "A Uniform Resource Identifier (URI) as defined by STD 66. 168 Objects using this textual convention MUST be in US-ASCII 169 encoding, and MUST be normalized as described by RFC 3986 170 sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 171 percent-encoding is removed, and all case-insensitive 172 characters are set to lowercase except for hexadecimal 173 digits, which are normalized to uppercase as described in 174 section 6.2.2.1. 176 The purpose of this normalization is to help provide unique 177 URIs. Note that this normalization is not sufficient to 178 provide uniqueness. Two URIs that are textually distinct 179 after this normalization may still be equivalent. 181 Objects using this textual convention MAY restrict the 182 schemes that they permit. For example, 'data:' and 'urn:' 183 schemes might not be appropriate. 185 A zero-length URI is not a valid URI. This can be used to 186 express 'URI absent' where required, for example when used 187 as an index field. 189 STD 66 URIs are of unlimited length. Objects using this 190 textual convention impose a length limit on the URIs that 191 they can represent. Where no length restriction is 192 required, objects SHOULD use the 'Uri' textual convention 193 instead. Objects used as indices SHOULD subtype the 'Uri' 194 textual convention." 195 REFERENCE "RFC 3986 STD 66 and RFC 3305" 196 SYNTAX OCTET STRING (SIZE (0..255)) 198 Uri1024 ::= TEXTUAL-CONVENTION 199 DISPLAY-HINT "1024a" 200 STATUS current 201 DESCRIPTION 202 "A Uniform Resource Identifier (URI) as defined by STD 66. 204 Objects using this textual convention MUST be in US-ASCII 205 encoding, and MUST be normalized as described by RFC 3986 206 sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 207 percent-encoding is removed, and all case-insensitive 208 characters are set to lowercase except for hexadecimal 209 digits, which are normalized to uppercase as described in 210 section 6.2.2.1. 212 The purpose of this normalization is to help provide unique 213 URIs. Note that this normalization is not sufficient to 214 provide uniqueness. Two URIs that are textually distinct 215 after this normalization may still be equivalent. 217 Objects using this textual convention MAY restrict the 218 schemes that they permit. For example, 'data:' and 'urn:' 219 schemes might not be appropriate. 221 A zero-length URI is not a valid URI. This can be used to 222 express 'URI absent' where required, for example when used 223 as an index field. 225 STD 66 URIs are of unlimited length. Objects using this 226 textual convention impose a length limit on the URIs that 227 they can represent. Where no length restriction is 228 required, objects SHOULD use the 'Uri' textual convention 229 instead. Objects used as indices SHOULD subtype the 'Uri' 230 textual convention." 231 REFERENCE "RFC 3986 STD 66 and RFC 3305" 232 SYNTAX OCTET STRING (SIZE (0..1024)) 234 END 236 5. Security Considerations 238 See also the Security Considerations of STD 66 [RFC3986]. 240 This MIB module does not define any management objects. Instead, it 241 defines a textual convention that may be imported by other MIB 242 modules and used for object definitions. 244 Meaningful security considerations can only be written in the MIB 245 modules that define management objects. This document therefore has 246 no impact on the security of the Internet. 248 6. IANA Considerations 250 URI-TC-MIB should be rooted under the mib-2 subtree. IANA is 251 requested to assign { mib-2 XXX } to the URI-TC-MIB module specified 252 in this document. 254 7. Acknowledgements 256 This module was generated by editing together contributions from 257 Randy Presuhn, Dan Romascanu, Bill Fenner, Juergen Schoenwaelder, and 258 others. 260 8. References 262 8.1 Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 268 Schoenwaelder, Ed., "Structure of Management Information 269 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 271 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 272 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 273 STD 58, RFC 2579, April 1999. 275 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 276 "Conformance Statements for SMIv2", STD 58, RFC 2580, 277 April 1999. 279 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 280 Resource Identifier (URI): Generic Syntax", STD 66, 281 RFC 3986, January 2005. 283 8.2 Informative References 285 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 286 IETF URI Planning Interest Group: Uniform Resource 287 Identifiers (URIs), URLs, and Uniform Resource Names 288 (URNs): Clarifications and Recommendations", RFC 3305, 289 August 2002. 291 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 292 "Introduction and Applicability Statements for Internet- 293 Standard Management Framework", RFC 3410, December 2002. 295 Author's Address 297 David McWalter (editor) 298 Data Connection Ltd 299 100 Church Street 300 Enfield EN2 6BQ 301 United Kingdom 303 Email: dmcw@dataconnection.com 305 Intellectual Property Statement 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at 327 ietf-ipr@ietf.org. 329 Disclaimer of Validity 331 This document and the information contained herein are provided on an 332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 333 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 334 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 335 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 336 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 339 Copyright Statement 341 Copyright (C) The IETF Trust (2007). This document is subject to the 342 rights, licenses and restrictions contained in BCP 78, and except as 343 set forth therein, the authors retain all their rights. 345 Acknowledgment 347 Funding for the RFC Editor function is currently provided by the 348 Internet Society.