smilint output for ./SIP-TC-MIB

Message Severities
SeverityCount
warning4
Message Types
TypeCount
type-unref (warning)4

Messages:

SIP-TC-MIB

   1: -- extracted from rfc4780.txt
   2: -- at Tue May  1 06:08:36 2007
  58: 
  59: SipTCTransportProtocol ::= TEXTUAL-CONVENTION
  59: warning - warning: current type `SipTCTransportProtocol' is not referenced in this module 
  60:     STATUS      current
  61:     DESCRIPTION
  62:        "This convention is a bit map.  Each bit represents a transport
  63:         protocol.  If a bit has value 1, then that selected transport
  64:         protocol is in some way dependent on the context of the object
  65:         using this convention.  If a bit has value 0, then that
  66:         transport protocol is not selected.  Combinations of bits can
  67:         be set when multiple transport protocols are selected.
  68: 
  69:         bit 0: a protocol other than those defined here
  70:         bit 1: User Datagram Protocol
  71:         bit 2: Transmission Control Protocol
  72:         bit 3: Stream Control Transmission Protocol
  73:         bit 4: Transport Layer Security Protocol over TCP
  74:         bit 5: Transport Layer Security Protocol over SCTP
  75:        "
  76:     REFERENCE "RFC 3261, Section 18 and RFC 4168"
  77:     SYNTAX      BITS {
  78:                   other(0),  -- none of the following
  79:                   udp(1),
  80:                   tcp(2),
  81:                   sctp(3),   -- RFC4168
  82:                   tlsTcp(4),
  83:                   tlsSctp(5) -- RFC 4168
  84:                 }
  85: 
  86: SipTCEntityRole ::= TEXTUAL-CONVENTION
  86: warning - warning: current type `SipTCEntityRole' is not referenced in this module 
  87:     STATUS      current
  88:     DESCRIPTION
  89:        "This convention defines the role of a SIP entity.  Examples of
  90:         SIP entities are proxies, user agents, redirect servers,
  91:         registrars, or combinations of the above.
  92: 
  93:         User Agent (UA): A logical entity that can act as both a user
  94:         agent client and user agent server.
  95:         User Agent Client (UAC): A logical entity that creates a new
  96:         request, and then uses the client transaction state machinery
  97:         to send it.  The role of UAC lasts only for the duration of
  98:         that transaction.  In other words, if a piece of software
  99:         initiates a request, it acts as a UAC for the duration of that
 100:         transaction.  If it receives a request later, it assumes the
 101:         role of a user agent server for the processing of that
 102:         transaction.
 103: 
 104:         User Agent Server (UAS): A logical entity that generates a
 105:         response to a SIP request.  The response accepts, rejects,
 106:         or redirects the request.  This role lasts only for the
 107:         duration of that transaction.  In other words, if a piece of
 108:         software responds to a request, it acts as a UAS for the
 109:         duration of that transaction.  If it generates a request
 110:         later, it assumes the role of a user agent client for the
 111:         processing of that transaction.
 112: 
 113:         Proxy, Proxy Server: An intermediary entity that acts as both
 114:         a server and a client for the purpose of making requests on
 115:         behalf of other clients.  A proxy server primarily plays the
 116:         role of routing, which means its job is to ensure that a
 117:         request is sent to another entity 'closer' to the targeted
 118:         user.  Proxies are also useful for enforcing policy.  A proxy
 119:         interprets and, if necessary, rewrites specific parts of a
 120:         request message before forwarding it.
 121: 
 122:         Redirect Server: A redirect server is a user agent server that
 123:         generates 3xx responses to requests it receives, directing the
 124:         client to contact an alternate set of URIs.
 125: 
 126:         Registrar: A registrar is a server that accepts REGISTER
 127:         requests and places the information it receives in those
 128:         requests into the location service for the domain it handles."
 129:     REFERENCE
 130:        "RFC 3261, Section 6"
 131:     SYNTAX      BITS {
 132:                   other(0),
 133:                   userAgent(1),
 134:                   proxyServer(2),
 135:                   redirectServer(3),
 136:                   registrarServer(4)
 137:                 }
 138: 
 139: SipTCOptionTagHeaders ::= TEXTUAL-CONVENTION
 139: warning - warning: current type `SipTCOptionTagHeaders' is not referenced in this module 
 140:     STATUS      current
 141:     DESCRIPTION
 142:        "This convention defines the header fields that use the option
 143:         tags per Section 19.2 of RFC 3261.  These tags are used in
 144:         Require (Section 20.32), Proxy-Require (Section 20.29),
 145:         Supported (Section 20.37), and Unsupported (Section 20.40)
 146:         header fields."
 147:     REFERENCE
 148:        "RFC 3261, Sections 19.2, 20.32, 20.29, 20.37, and 20.40"
 149:     SYNTAX      BITS {
 150:                   require(0),       -- Require header
 151:                   proxyRequire(1),  -- Proxy-Require header
 152:                   supported(2),     -- Supported header
 153:                   unsupported(3)    -- Unsupported header
 154:                 }
 155: 
 156: SipTCMethodName ::= TEXTUAL-CONVENTION
 156: warning - warning: current type `SipTCMethodName' is not referenced in this module 
 157:     STATUS      current
 158:     DESCRIPTION
 159:        "This TEXTUAL-CONVENTION is a string that uniquely identifies a
 160:         SIP method.  The scope of uniqueness is the context of all
 161:         defined SIP methods.
 162: 
 163:         Experimental support of extension methods is acceptable and
 164:         expected.  Extension methods are those defined in
 165:         Internet-Draft documents but not yet allocated and
 166:         officially sanctioned by IANA.
 167: 
 168:         To support experimental extension methods, any object using
 169:         this TEXTUAL-CONVENTION as syntax MAY return/accept a method
 170:         identifier value other than those sanctioned by IANA.  That
 171:         system MUST ensure no collisions with officially assigned
 172:         method names."
 173:     REFERENCE
 174:        "RFC 3261, Section 27.4"
 175:     SYNTAX      OCTET STRING (SIZE (1..100))
 176: 
 177: END
 178: 
 179: -- 
 180: --    Copyright (C) The IETF Trust (2007).
 181: -- 
 182: --    This document is subject to the rights, licenses and restrictions
 183: --    contained in BCP 78, and except as set forth therein, the authors
 184: --    retain all their rights.
 185: -- 
 186: --    This document and the information contained herein are provided on an
 187: --    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 188: --    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 189: --    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 190: --    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 191: --    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 192: --    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 193: -- 
 194: -- Intellectual Property
 195: -- 
 196: --    The IETF takes no position regarding the validity or scope of any
 197: --    Intellectual Property Rights or other rights that might be claimed to
 198: --    pertain to the implementation or use of the technology described in
 199: --    this document or the extent to which any license under such rights
 200: --    might or might not be available; nor does it represent that it has
 201: --    made any independent effort to identify any such rights.  Information
 202: --    on the procedures with respect to rights in RFC documents can be
 203: --    found in BCP 78 and BCP 79.
 204: -- 
 205: --    Copies of IPR disclosures made to the IETF Secretariat and any
 206: --    assurances of licenses to be made available, or the result of an
 207: --    attempt made to obtain a general license or permission for the use of
 208: --    such proprietary rights by implementers or users of this
 209: --    specification can be obtained from the IETF on-line IPR repository at
 210: --    http://www.ietf.org/ipr.
 211: -- 
 212: --    The IETF invites any interested party to bring to its attention any
 213: --    copyrights, patents or patent applications, or other proprietary
 214: --    rights that may cover technology that may be required to implement
 215: --    this standard.  Please address the information to the IETF at
 216: --    ietf-ipr@ietf.org.
 217: -- 
 218: