RFC 5017

MIB Textual Conventions for Uniform Resource Identifiers (URIs)

📅 published September 2007, from ietf

RFC 5017 💖 MIB Textual Conventions for Uniform Resource Identifiers (URIs)

okay bestie, so this is RFC 5017 🎀 and it's called MIB Textual Conventions for Uniform Resource Identifiers (URIs). It was written by D. McWalter, Ed. from Data Connection Ltd, it's on the Standards Track, and it dropped in September 2007 🦋. The header doesn't list anything it obsoletes or updates, so it's standing on its own, iconic behaviour 👑

Status of This Memo 🪧

this one is an Internet standards track protocol for the Internet community, and it's openly asking for discussion and suggestions for improvements 💬 if you want to check where it sits in the standardization process, look at the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🌈

Abstract 🌸

this MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs) 🔗 the whole point is that other MIB modules can import these conventions and use them, instead of inventing their own way of representing URIs 🫶

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 ✨

okay so this memo covers a portion of the Management Information Base (MIB) 🗂️, which is used with network management protocols across the Internet community. It defines textual conventions to represent STD 66 [RFC3986] URIs, and those are further described by [RFC3305] 🧚

Three textual conventions are defined: one of unrestricted length, and two of different restricted lengths. Which length is appropriate depends on the tradeoffs made in a particular MIB module ⚖️ The whole purpose of the standard restricted-length conventions is to make MIB modules that need restricted-length URIs play nicer together 💅

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 talks about this case, so go check it out 🙈

2. Terminology 🎀

the key words that matter in this document are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They're meant to be interpreted as described in RFC 2119 [RFC2119], so read that one too if you want the full picture 📖

3. The Internet-Standard Management Framework 🌷

if you want a detailed overview of the documents that describe the current Internet-Standard Management Framework, go to section 7 of RFC 3410 [RFC3410] 🗺️

okay so managed objects are accessed through a virtual information store called 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 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] 💜

4. Definitions 🧚‍♀️

here's the full MIB module, copied exactly so nothing gets lost in translation 🍓

URI-TC-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, mib-2             FROM SNMPv2-SMI      -- [RFC2578]
    TEXTUAL-CONVENTION                 FROM 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.

            Copyright (C) The IETF Trust (2007).  This version of this
            MIB module is part of RFC 5017; see the RFC itself for full
            legal notices."
    ::= { mib-2 164 }

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.

            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.

            Objects using this TEXTUAL-CONVENTION MAY restrict the
            schemes that they permit.  For example, 'data:' and 'urn:'
            schemes might not be appropriate.

            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.

            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

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
            characters are set to lowercase except for hexadecimal
            digits, which are normalized to uppercase as described in
            Section 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.

            Objects using this TEXTUAL-CONVENTION MAY restrict the
            schemes that they permit.  For example, 'data:' and 'urn:'
            schemes might not be appropriate.

            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.

            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))

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.

            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.

            Objects using this TEXTUAL-CONVENTION MAY restrict the
            schemes that they permit.  For example, 'data:' and 'urn:'
            schemes might not be appropriate.

            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.

            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))

END

Part 1 of 2 🦋 part 2 picks up with Section 5 (Security Considerations) and carries on through the References and the Author's Address 💅

Okay bestie, the legal part 💅 Copyright (C) The IETF Trust (2007), and this document is subject to the rights, licenses, and restrictions in BCP 78. Except where BCP 78 says otherwise, the authors keep all their rights 🎀

Now the fine print, which is kind of a lot 🙈 This document and everything in it is provided on an "AS IS" basis. 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 all DISCLAIM ALL WARRANTIES, express or implied. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose 💀

Read that part carefully, it's the whole "no promises" energy, so don't assume anything is guaranteed just because it's in an RFC 🫶

Intellectual Property 💜

Okay so the IETF is being pretty neutral here 🧚 It takes no position on whether any Intellectual Property Rights (or other rights) that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether a license for those rights is available. It hasn't independently checked for any of those rights either 👀 If you want to know how rights work for RFC documents, check out BCP 78 and BCP 79. Iconic homework, honestly 📚

If you want copies of IPR disclosures that were sent to the IETF Secretariat, or assurances that licenses will be made available, you can get them from the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the result of any attempt to get a general license or permission to use those proprietary rights, which implementers or users might be looking for 🌸

And last but not least, the IETF invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to ietf-ipr@ietf.org (the address is ietf-ipr@ietf.org) 🦋 Literally the most helpful thing you can do for the community, slay ✨

📦 where this page comes from