smilint output for ./URI-TC-MIB

Messages:

URI-TC-MIB

   1: -- extracted from rfc5017.txt
   2: -- at Fri Sep 14 06:09:14 2007

  26: 
  27: Uri ::= TEXTUAL-CONVENTION

  28:    DISPLAY-HINT "1a"
  29:    STATUS      current
  30:    DESCRIPTION
  31:             "A Uniform Resource Identifier (URI) as defined by STD 66.
  32: 
  33:             Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII
  34:             encoding, and MUST be normalized as described by RFC 3986
  35:             Sections 6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
  36:             percent-encoding is removed, and all case-insensitive
  37:             characters are set to lowercase except for hexadecimal
  38:             digits, which are normalized to uppercase as described in
  39:             Section 6.2.2.1.
  40: 
  41:             The purpose of this normalization is to help provide unique
  42:             URIs.  Note that this normalization is not sufficient to
  43:             provide uniqueness.  Two URIs that are textually distinct
  44:             after this normalization may still be equivalent.
  45: 
  46:             Objects using this TEXTUAL-CONVENTION MAY restrict the
  47:             schemes that they permit.  For example, 'data:' and 'urn:'
  48:             schemes might not be appropriate.
  49: 
  50:             A zero-length URI is not a valid URI.  This can be used to
  51:             express 'URI absent' where required, for example when used
  52:             as an index field.
  53: 
  54:             Where this TEXTUAL-CONVENTION is used for an index field,
  55:             it MUST be subtyped to restrict its length.  There is an
  56:             absolute limit of 128 subids for an OID, and it is not
  57:             efficient to have OIDs whose length approaches this
  58:             limit."
  59:    REFERENCE "RFC 3986 STD 66 and RFC 3305"
  60:    SYNTAX      OCTET STRING
  61: 
  62: Uri255 ::= TEXTUAL-CONVENTION

  63:    DISPLAY-HINT "255a"
  64:    STATUS      current
  65:    DESCRIPTION
  66:             "A Uniform Resource Identifier (URI) as defined by STD 66.
  67: 
  68:             Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII
  69:             encoding, and MUST be normalized as described by RFC 3986
  70:             Sections 6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
  71:             percent-encoding is removed, and all case-insensitive
  72:             characters are set to lowercase except for hexadecimal
  73:             digits, which are normalized to uppercase as described in
  74:             Section 6.2.2.1.
  75: 
  76:             The purpose of this normalization is to help provide unique
  77:             URIs.  Note that this normalization is not sufficient to
  78:             provide uniqueness.  Two URIs that are textually distinct
  79:             after this normalization may still be equivalent.
  80: 
  81:             Objects using this TEXTUAL-CONVENTION MAY restrict the
  82:             schemes that they permit.  For example, 'data:' and 'urn:'
  83:             schemes might not be appropriate.
  84: 
  85:             A zero-length URI is not a valid URI.  This can be used to
  86:             express 'URI absent' where required, for example when used
  87:             as an index field.
  88: 
  89:             STD 66 URIs are of unlimited length.  Objects using this
  90:             TEXTUAL-CONVENTION impose a length limit on the URIs that
  91:             they can represent.  Where no length restriction is
  92:             required, objects SHOULD use the 'Uri' TEXTUAL-CONVENTION
  93:             instead.  Objects used as indices SHOULD subtype the 'Uri'
  94:             TEXTUAL-CONVENTION."
  95:    REFERENCE "RFC 3986 STD 66 and RFC 3305"
  96:    SYNTAX      OCTET STRING (SIZE (0..255))
  97: 
  98: Uri1024 ::= TEXTUAL-CONVENTION

  99:    DISPLAY-HINT "1024a"
 100:    STATUS      current
 101:    DESCRIPTION
 102:             "A Uniform Resource Identifier (URI) as defined by STD 66.
 103: 
 104:             Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII
 105:             encoding, and MUST be normalized as described by RFC 3986
 106:             Sections 6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
 107:             percent-encoding is removed, and all case-insensitive
 108:             characters are set to lowercase except for hexadecimal
 109:             digits, which are normalized to uppercase as described in
 110:             Section 6.2.2.1.
 111: 
 112:             The purpose of this normalization is to help provide unique
 113:             URIs.  Note that this normalization is not sufficient to
 114:             provide uniqueness.  Two URIs that are textually distinct
 115:             after this normalization may still be equivalent.
 116: 
 117:             Objects using this TEXTUAL-CONVENTION MAY restrict the
 118:             schemes that they permit.  For example, 'data:' and 'urn:'
 119:             schemes might not be appropriate.
 120:             A zero-length URI is not a valid URI.  This can be used to
 121:             express 'URI absent' where required, for example when used
 122:             as an index field.
 123: 
 124:             STD 66 URIs are of unlimited length.  Objects using this
 125:             TEXTUAL-CONVENTION impose a length limit on the URIs that
 126:             they can represent.  Where no length restriction is
 127:             required, objects SHOULD use the 'Uri' TEXTUAL-CONVENTION
 128:             instead.  Objects used as indices SHOULD subtype the 'Uri'
 129:             TEXTUAL-CONVENTION."
 130:    REFERENCE "RFC 3986 STD 66 and RFC 3305"
 131:    SYNTAX      OCTET STRING (SIZE (0..1024))
 132: 
 133: END
 134: 
 135: -- 
 136: --    Copyright (C) The IETF Trust (2007).
 137: -- 
 138: --    This document is subject to the rights, licenses and restrictions
 139: --    contained in BCP 78, and except as set forth therein, the authors
 140: --    retain all their rights.
 141: -- 
 142: --    This document and the information contained herein are provided on an
 143: --    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 144: --    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 145: --    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 146: --    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 147: --    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 148: --    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 149: -- 
 150: -- Intellectual Property
 151: -- 
 152: --    The IETF takes no position regarding the validity or scope of any
 153: --    Intellectual Property Rights or other rights that might be claimed to
 154: --    pertain to the implementation or use of the technology described in
 155: --    this document or the extent to which any license under such rights
 156: --    might or might not be available; nor does it represent that it has
 157: --    made any independent effort to identify any such rights.  Information
 158: --    on the procedures with respect to rights in RFC documents can be
 159: --    found in BCP 78 and BCP 79.
 160: -- 
 161: --    Copies of IPR disclosures made to the IETF Secretariat and any
 162: --    assurances of licenses to be made available, or the result of an
 163: --    attempt made to obtain a general license or permission for the use of
 164: --    such proprietary rights by implementers or users of this
 165: --    specification can be obtained from the IETF on-line IPR repository at
 166: --    http://www.ietf.org/ipr.
 167: -- 
 168: --    The IETF invites any interested party to bring to its attention any
 169: --    copyrights, patents or patent applications, or other proprietary
 170: --    rights that may cover technology that may be required to implement
 171: --    this standard.  Please address the information to the IETF at
 172: --    ietf-ipr@ietf.org.
 173: