Network Working Group D. McWalter, Ed.
Request for Comments: 5017 Data Connection Ltd
Category: Standards Track September 2007
Network Working Group D. McWalter, Ed.
Request for Comments: 5017 Data Connection Ltd
Category: Standards Track September 2007
MIB Textual Conventions for Uniform Resource Identifiers (URIs)
统一资源标识符（URI）的MIB文本约定
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s).
此MIB模块定义文本约定来表示STD 66统一资源标识符（URI）。其目的是将这些文本约定导入并在MIB模块中使用，否则这些模块将定义它们自己的表示。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The Internet-Standard Management Framework . . . . . . . . . . 2
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The Internet-Standard Management Framework . . . . . . . . . . 2
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It defines textual conventions to represent STD 66 [RFC3986] URIs, which are further described by [RFC3305].
此备忘录定义了管理信息库（MIB）的一部分，用于Internet社区中的网络管理协议。它定义了表示STD 66[RFC3986]URI的文本约定，并在[RFC3305]中作了进一步描述。
Three textual conventions are defined: one of unrestricted length, and two of different restricted lengths. Which length is appropriate will depend on tradeoffs made in particular MIB modules. The purpose of providing standard restricted-length textual conventions is to improve compatibility between MIB modules that require restricted-length URIs.
定义了三种文本约定：一种是无限制长度，另一种是不同限制长度。哪种长度合适取决于在特定MIB模块中进行的权衡。提供标准的受限长度文本约定的目的是改进需要受限长度URI的MIB模块之间的兼容性。
If a URI needs to be used as an index object, then the 'Uri' TEXTUAL-CONVENTION SHOULD be subtyped to a length appropriate for the Object Identifier (OID) of which it is part. The description of the 'Uri' TEXTUAL-CONVENTION discusses this case.
如果URI需要用作索引对象，则“URI”文本约定的子类型应为适合其所属对象标识符（OID）的长度。“Uri”文本约定的描述讨论了这种情况。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
有关描述当前互联网标准管理框架的文件的详细概述，请参阅RFC 3410[RFC3410]第7节。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB对象通常通过简单网络管理协议（SNMP）进行访问。MIB中的对象是使用管理信息结构（SMI）中定义的机制定义的。本备忘录规定了符合SMIv2的MIB模块，如STD 58、RFC 2578[RFC2578]、STD 58、RFC 2579[RFC2579]和STD 58、RFC 2580[RFC2580]所述。
URI-TC-MIB DEFINITIONS ::= BEGIN
URI-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579]
从SNMPv2 SMI导入模块标识mib-2--[RFC2578]从SNMPv2 TC导入文本约定；--[RFC2579]
uriTcMIB MODULE-IDENTITY LAST-UPDATED "200709100000Z" -- 10 September 2007 ORGANIZATION "IETF Operations and Management (OPS) Area" CONTACT-INFO "EMail: ops-area@ietf.org Home page: http://www.ops.ietf.org/" DESCRIPTION "This MIB module defines textual conventions for representing URIs, as defined by RFC 3986 STD 66." REVISION "200709100000Z" -- 10 September 2007 DESCRIPTION "Initial revision, published as RFC 5017.
uriTcMIB模块标识最后更新的“200709100000Z”-2007年9月10日组织“IETF运行和管理（OPS）区域”联系信息电子邮件：OPS-area@ietf.org主页：http://www.ops.ietf.org/“说明”此MIB模块定义了表示URI的文本约定，如RFC 3986 STD 66所定义。“修订版”200709100000Z--2007年9月10日描述“初始修订版，作为RFC 5017出版。
Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 5017; see the RFC itself for full
版权所有（C）IETF信托基金（2007年）。此版本的MIB模块是RFC 5017的一部分；请参阅RFC本身以获取完整信息
legal notices."
::= { mib-2 164 }
legal notices."
::= { mib-2 164 }
Uri ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"A Uniform Resource Identifier (URI) as defined by STD 66.
Uri ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"A Uniform Resource Identifier (URI) as defined by STD 66.
Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII encoding, and MUST be normalized as described by RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary percent-encoding is removed, and all case-insensitive characters are set to lowercase except for hexadecimal digits, which are normalized to uppercase as described in Section 6.2.2.1.
使用此文本约定的对象必须采用US-ASCII编码，并且必须按照RFC 3986第6.2.1、6.2.2.1和6.2.2.2节的说明进行规范化。删除所有不必要的百分比编码，并将所有不区分大小写的字符设置为小写，但十六进制数字除外，十六进制数字标准化为大写，如第6.2.2.1节所述。
The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient to provide uniqueness. Two URIs that are textually distinct after this normalization may still be equivalent.
此规范化的目的是帮助提供唯一的URI。请注意，这种规范化不足以提供唯一性。在此规范化之后，文本上不同的两个URI可能仍然是等效的。
Objects using this TEXTUAL-CONVENTION MAY restrict the schemes that they permit. For example, 'data:' and 'urn:' schemes might not be appropriate.
使用此文本约定的对象可能会限制其允许的方案。例如，“data:”和“urn:”方案可能不合适。
A zero-length URI is not a valid URI. This can be used to express 'URI absent' where required, for example when used as an index field.
长度为零的URI不是有效的URI。这可用于在需要时表示“URI缺席”，例如用作索引字段时。
Where this TEXTUAL-CONVENTION is used for an index field, it MUST be subtyped to restrict its length. There is an absolute limit of 128 subids for an OID, and it is not efficient to have OIDs whose length approaches this limit." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING
如果此文本约定用于索引字段，则必须将其子类型化以限制其长度。OID有128个子ID的绝对限制，如果OID的长度接近此限制，则效率不高。“参考”RFC 3986 STD 66和RFC 3305“语法八位字节字符串
Uri255 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"A Uniform Resource Identifier (URI) as defined by STD 66.
Uri255 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"A Uniform Resource Identifier (URI) as defined by STD 66.
Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII encoding, and MUST be normalized as described by RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary percent-encoding is removed, and all case-insensitive
使用此文本约定的对象必须采用US-ASCII编码，并且必须按照RFC 3986第6.2.1、6.2.2.1和6.2.2.2节的说明进行规范化。删除所有不必要的百分比编码，并且不区分大小写
characters are set to lowercase except for hexadecimal digits, which are normalized to uppercase as described in Section 6.2.2.1.
字符设置为小写，十六进制数字除外，十六进制数字标准化为大写，如第6.2.2.1节所述。
The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient to provide uniqueness. Two URIs that are textually distinct after this normalization may still be equivalent.
此规范化的目的是帮助提供唯一的URI。请注意，这种规范化不足以提供唯一性。在此规范化之后，文本上不同的两个URI可能仍然是等效的。
Objects using this TEXTUAL-CONVENTION MAY restrict the schemes that they permit. For example, 'data:' and 'urn:' schemes might not be appropriate.
使用此文本约定的对象可能会限制其允许的方案。例如，“data:”和“urn:”方案可能不合适。
A zero-length URI is not a valid URI. This can be used to express 'URI absent' where required, for example when used as an index field.
长度为零的URI不是有效的URI。这可用于在需要时表示“URI缺席”，例如用作索引字段时。
STD 66 URIs are of unlimited length. Objects using this TEXTUAL-CONVENTION impose a length limit on the URIs that they can represent. Where no length restriction is required, objects SHOULD use the 'Uri' TEXTUAL-CONVENTION instead. Objects used as indices SHOULD subtype the 'Uri' TEXTUAL-CONVENTION." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING (SIZE (0..255))
STD 66 URI的长度不受限制。使用此文本约定的对象对它们可以表示的URI施加长度限制。如果不需要长度限制，对象应该使用“Uri”文本约定。用作索引的对象应为“Uri”文本约定的子类型。“参考”RFC 3986 STD 66和RFC 3305“语法八位字符串（大小（0..255））
Uri1024 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1024a"
STATUS current
DESCRIPTION
"A Uniform Resource Identifier (URI) as defined by STD 66.
Uri1024 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1024a"
STATUS current
DESCRIPTION
"A Uniform Resource Identifier (URI) as defined by STD 66.
Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII encoding, and MUST be normalized as described by RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary percent-encoding is removed, and all case-insensitive characters are set to lowercase except for hexadecimal digits, which are normalized to uppercase as described in Section 6.2.2.1.
使用此文本约定的对象必须采用US-ASCII编码，并且必须按照RFC 3986第6.2.1、6.2.2.1和6.2.2.2节的说明进行规范化。删除所有不必要的百分比编码，并将所有不区分大小写的字符设置为小写，但十六进制数字除外，十六进制数字标准化为大写，如第6.2.2.1节所述。
The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient to provide uniqueness. Two URIs that are textually distinct after this normalization may still be equivalent.
此规范化的目的是帮助提供唯一的URI。请注意，这种规范化不足以提供唯一性。在此规范化之后，文本上不同的两个URI可能仍然是等效的。
Objects using this TEXTUAL-CONVENTION MAY restrict the schemes that they permit. For example, 'data:' and 'urn:' schemes might not be appropriate.
使用此文本约定的对象可能会限制其允许的方案。例如，“data:”和“urn:”方案可能不合适。
A zero-length URI is not a valid URI. This can be used to express 'URI absent' where required, for example when used as an index field.
长度为零的URI不是有效的URI。这可用于在需要时表示“URI缺席”，例如用作索引字段时。
STD 66 URIs are of unlimited length. Objects using this TEXTUAL-CONVENTION impose a length limit on the URIs that they can represent. Where no length restriction is required, objects SHOULD use the 'Uri' TEXTUAL-CONVENTION instead. Objects used as indices SHOULD subtype the 'Uri' TEXTUAL-CONVENTION." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING (SIZE (0..1024))
STD 66 URI的长度不受限制。使用此文本约定的对象对它们可以表示的URI施加长度限制。如果不需要长度限制，对象应该使用“Uri”文本约定。用作索引的对象应为“Uri”文本约定的子类型。“参考”RFC 3986 STD 66和RFC 3305“语法八位字符串（大小（0..1024））
END
终止
See also the Security Considerations of STD 66 [RFC3986].
另见STD 66[RFC3986]的安全注意事项。
This MIB module does not define any management objects. Instead, it defines a textual convention that may be imported by other MIB modules and used for object definitions.
此MIB模块不定义任何管理对象。相反，它定义了一个文本约定，可以由其他MIB模块导入并用于对象定义。
Meaningful security considerations can only be written in the MIB modules that define management objects. This document therefore has no impact on the security of the Internet.
有意义的安全注意事项只能写入定义管理对象的MIB模块中。因此，本文件不影响互联网的安全。
URI-TC-MIB is rooted under the mib-2 subtree. IANA has assigned { mib-2 164 } to the URI-TC-MIB module specified in this document.
URI-TC-MIB根在MIB-2子树下。IANA已将{mib-2 164}分配给本文档中指定的URI-TC-mib模块。
This module was generated by editing together contributions from Randy Presuhn, Dan Romascanu, Bill Fenner, Juergen Schoenwaelder, and others.
这个模块是由兰迪·普雷森、丹·罗马斯坎努、比尔·芬纳、尤尔根·舍恩瓦埃尔德和其他人共同编辑的。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002.
[RFC3305]Mealling，M.和R.Denenberg，“W3C/IETF URI规划联合兴趣小组的报告：统一资源标识符（URI）、URL和统一资源名称（URN）：澄清和建议”，RFC 33052002年8月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
Author's Address
作者地址
David McWalter (editor) Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom
David McWalter（编辑）数据连接有限公司英国恩菲尔德教堂街100号EN2 6BQ
EMail: dmcw@dataconnection.com
EMail: dmcw@dataconnection.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.