One document matched: draft-ietf-opsawg-smi-datatypes-in-xsd-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<?rfc strict="yes"?>
<?rfc rfcedstyle="no"?>
<?rfc iprnotified="yes"?>
<rfc category="std" ipr="trust200811" docName="draft-ietf-opsawg-smi-datatypes-in-xsd-06.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev="Expressing SNMP SMI Datatypes in XSD">
Expressing SNMP SMI Datatypes in XML Schema Definition Language
</title>
<author initials='M.' surname='Ellison'
fullname='Mark Ellison'>
<organization>Ellison Software Consulting</organization>
<address>
<postal>
<street>38 Salem Road</street>
<city>Atkinson</city>
<region>NH</region>
<code>03811</code>
<country>USA</country>
</postal>
<phone>+1 603-362-9270</phone>
<email>ietf@ellisonsoftware.com</email>
</address>
</author>
<author initials='B.' surname='Natale'
fullname='Bob Natale'>
<organization>MITRE</organization>
<address>
<postal>
<street>300 Sentinel Drive</street>
<street>6th Floor</street>
<city>Annapolis Junction</city>
<region>MD</region>
<code>20701</code>
<country>USA</country>
</postal>
<phone>+1 301-617-3008</phone>
<email>rnatale@mitre.org</email>
</address>
</author>
<date year='2010'/>
<area>Operations and Management</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>SMI</keyword>
<keyword>Datatype</keyword>
<keyword>XML</keyword>
<keyword>eXtensible Markup Language</keyword>
<keyword>XML Schema</keyword>
<keyword>XSD</keyword>
<abstract>
<t>This memo defines the IETF standard expression of Structure of Management
Information (SMI) base datatypes in Extensible Markup Language (XML) Schema
Definition (XSD) language. The primary objective of this memo is to enable
the production of XML documents that are as faithful to the SMI as possible,
using XSD as the validation mechanism.</t>
</abstract>
</front>
<middle>
<!-- INTRODUCTION -->
<section title="Introduction">
<t>Numerous use cases exist for expressing the management information
described by SMI Management Information Base (MIB) modules
in XML <xref target="XML"/>. Potential use cases reside both outside
and within the traditional IETF network management community.
For example, developers of some XML-based management applications
may want to incorporate the rich set of data models provided by MIB modules.
Developers of other XML-based management applications may want to access MIB module
instrumentation via gateways to SNMP agents. Such applications
benefit from the IETF standard mapping of SMI datatypes to XML datatypes via
XSD <xref target="XMLSchema"/>, <xref target="XSDDatatypes"/>.</t>
<t>MIB modules use SMIv2 <xref target="RFC2578"/> to describe data models. For
legacy MIB modules, SMIv1 <xref target="RFC1155"/> was used. MIB data conveyed in
variable bindings ("varbinds") within protocol data units (PDUs) of
SNMP messages use the primitive, base datatypes defined by the SMI.</t>
<t>The SMI allows for the creation of derivative datatypes, "textual
conventions" ("TCs") <xref target="RFC2579"/>. A TC has a unique name,
has a syntax that either refines or is a base SMI datatype and has
relatively precise application-level semantics. TCs facilitate correct
application-level handling of MIB data, improve readability of MIB
modules by humans and support appropriate renderings of MIB data.</t>
<t>Values in varbinds corresponding to MIB objects defined with TC
syntax are always encoded as the base SMI datatype underlying the
TC syntax. Thus, the XSD mappings defined in this memo provide support
for values of MIB objects defined with TC syntax as well as for values
of MIB objects defined with base SMI syntax.</t>
<t>Various independent schemes have been devised for expressing SMI
datatypes in XSD. These schemes exhibit a degree of commonality, especially
concerning numeric SMI datatypes, but these schemes also exhibit sufficient differences,
especially concerning the non-numeric SMI datatypes, precluding uniformity
of expression and general interoperability.</t>
<t>Throughout this memo, the term "fidelity" refers to the quality of an accurate,
consistent representation of SMI data values and the term "faithful" refers
to the quality of reliably reflecting the semantics of SMI data values.
Thus defined, the characteristics of fidelity and being faithful are
essential to uniformity of expression and general interoperability in the
XML representation of SMI data values.
</t>
<t>The primary purpose of this memo is to define the standard expression
of SMI base datatypes in XML documents that is both uniform and
interoperable. This standard expression enables Internet operators, management
application developers, and users to benefit from a wider range
of management tools and to benefit from a greater degree of unified management.
Thus, standard expression enables and facilitates improvements to the timeliness, accuracy and utility
of management information.
</t>
<t>The overall objective of this memo, and of any related future memos
as may be published, is to define the XSD equivalent <xref target="XSDDatatypes"/>
of SMIv2 (STD58) and to encourage XML-based protocols to carry, and XML-based
applications to use, the management information defined in SMIv2-compliant MIB modules.
The use of a standard mapping from SMIv2 to XML via XSD validation
enables and promotes the efficient reuse of existing and future MIB modules
and instrumentation by XML-based protocols and management applications.</t>
<t>Developers of certain XML-based management applications will find this specification sufficient
for their purposes. Developers of other XML-based management applications may need to make more complete
reuse of existing MIB modules, requiring standard XSD documents for TCs <xref target="RFC2579"/>
and MIB structure <xref target="RFC2578"/>. Memos supporting such
requirements are planned, but have not been produced at the time of this writing.</t>
<t>Finally, it is worthwhile to note that the goal of fidelity to the SMIv2
standard (STD58), as specified in the
"Requirements" section below, is crucial to this effort. Fidelity leverages
the established "rough consensus" of the precise SMIv2 data models contained in MIB
modules, and leverages existing instrumentation, the "running code" implementing SMIv2
data models. This effort does not include any redesign of SMIv2 datatypes,
data structures or textual conventions in order to overcome known limitations.
Such work can be pursued by other efforts.</t>
</section>
<!-- CONVENTIONS -->
<section title="Conventions">
<t>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 <xref target="RFC2119"/>.
</t>
</section>
<!-- REQUIREMENTS -->
<section title="Requirements">
<t>The following set of requirements is intended to produce XML documents
which can be validated via the XSD defined in this specification to
faithfully represent values carried "on-the-wire" in SNMP PDUs as defined
by the SMI:
<list style="format R%d." counter="rqmts">
<t>All SMI base datatypes MUST have a corresponding XSD datatype.</t>
<t>SMIv2 is the normative SMI for this document. Prior to mapping
datatypes into XSD, legacy SMIv1 modules MUST be converted (at least
logically) in accordance with Section 2.1, inclusive, of the
"Coexistence" RFC <xref target="RFC3584"/>.</t>
<t>The XSD datatype specified for a given SMI datatype MUST be able
to represent all valid values for that SMI datatype.</t>
<t>The XSD datatype specified for a given SMI datatype MUST represent
any special encoding rules associated with that SMI datatype.</t>
<t>The XSD datatype specified for a given SMI datatype MUST include
any restrictions on values associated with the SMI datatype.</t>
<t>The XSD datatype specified for a given SMI datatype MUST be the
most logical XSD datatype, with the fewest necessary restrictions on
its set of values, consistent with the foregoing requirements.</t>
<t>The XML output produced as a result of meeting the foregoing
requirements SHOULD be the most coherent and succinct representation
(i.e., avoiding superfluous "decoration") from the perspective of
readability by humans.</t>
</list></t>
</section>
<!-- XSD FOR SMI BASE DATATYPES -->
<section title="XSD for SMI Base Datatypes">
<t>This document provides XSD datatype mappings for the SMIv2 base datatypes
only -- i.e., the eleven "ObjectSyntax" datatypes defined in RFC 2578. These
datatypes -- via tag values defined in the SMIv2 to identify them in varbinds
-- constrain values carried "on-the-wire" in SNMP PDUs between SNMP management
applications and SNMP agents:
<list style="symbols">
<t>INTEGER, Integer32</t>
<t>Unsigned32, Gauge32</t>
<t>Counter32</t>
<t>TimeTicks</t>
<t>Counter64</t>
<t>OCTET STRING</t>
<t>Opaque</t>
<t>IpAddress</t>
<t>OBJECT IDENTIFIER</t>
</list></t>
<t>The "BITS" pseudo-type (also referred to as a "construct" in RFC 2578)
is treated as a Textual Convention, not a base datatype, for the purpose
of this document. <vspace blankLines="100"/> </t>
<figure>
<artwork>
<![CDATA[
BEGIN
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:opsawg:smi:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:opsawg:smi:base:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en">
<xs:annotation>
<xs:documentation>
Mapping of SMIv2 base datatypes from RFC 2578
Contact: Mark Ellison
Organization: Ellison Software Consulting
Address: 38 Salem Road
Atkinson, NH 03811
USA
Telephone: +1 603-362-9270
E-Mail: ietf@EllisonSoftware.com
Contact: Bob Natale
Organization: MITRE
Address: 300 Sentinel Drive
6th Floor
Annapolis Junction MD 20701
USA
Telephone: +1 301-617-3008
E-Mail: rnatale@mitre.org
Last Updated: 201002260000Z
Copyright (c) 2010 IETF Trust and the persons
identified as the document authors. All rights
reserved.
Redistribution and use in source and binary forms,
with or without modification, is permitted pursuant
to, and subject to the license terms contained in,
the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to
IETF Documents (http://trustee.ietf.org/license-info).
This version of this XML Schema Definition (XSD)
document is part of RFC XXXX; see the RFC itself for
full legal notices."
RFC Editor - please replace XXXX with the value allocated
for publication as an RFC.
</xs:documentation>
</xs:annotation>
<xs:simpleType name="INTEGER">
<xs:restriction base="xs:int"/>
</xs:simpleType>
<xs:simpleType name="Integer32">
<xs:restriction base="xs:int"/>
</xs:simpleType>
<xs:simpleType name="Unsigned32">
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<xs:simpleType name="Gauge32">
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<xs:simpleType name="Counter32">
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<xs:simpleType name="TimeTicks">
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<xs:simpleType name="Counter64">
<xs:restriction base="xs:unsignedLong"/>
</xs:simpleType>
<xs:simpleType name="OctetString">
<xs:restriction base="xs:hexBinary">
<xs:maxLength value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="Opaque">
<xs:restriction base="xs:hexBinary"/>
</xs:simpleType>
<xs:simpleType name="IpAddress">
<xs:restriction base="xs:string">
<xs:pattern value=
"((0|(1[0-9]{0,2})|
(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|
([3-9][0-9]?))\.){3}
(0|(1[0-9]{0,2})|
(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|
([3-9][0-9]?))"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ObjectIdentifier">
<xs:restriction base="xs:string">
<xs:pattern value=
"(([0-1](\.[1-3]?[0-9]))|
(2\.(0|([1-9]\d*))))
(\.(0|([1-9]\d*))){0,126}"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
END
]]>
</artwork>
</figure>
</section>
<!-- RATIONALE -->
<section title="Rationale">
<t>The XSD datatypes, including any specified restrictions, were chosen
based on fit with the requirements specified earlier in this document, and
with attention to simplicity while maintaining fidelity to the SMI. Also,
the "canonical representations" (i.e., refinements of the "lexical
representations") documented in the W3C XSD specification <xref target="XMLSchema"/>,
<xref target="XSDDatatypes"/> are assumed.</t>
<section title="Numeric Datatypes">
<t>All of the numeric XSD datatypes specified in the previous section --
INTEGER, Integer32, Unsigned32, Gauge32, Counter32, TimeTicks, and Counter64
-- comply with the relevant requirements
<list style="symbols">
<t>They cover all valid values for the corresponding SMI datatypes.</t>
<t>They comply with the standard encoding rules associated with the
corresponding SMI datatypes.</t>
<t>They inherently match the range restrictions associated with the
corresponding SMI datatypes.</t>
<t>They are the most direct XSD datatypes which exhibit the foregoing
characteristics relative to the corresponding SMI datatypes (which is
why no "restriction" statements -- other than the "base" XSD type -- are
required in the XSD).</t>
<t>The XML output produced from the canonical representation of these
XSD datatypes is also the most direct from the perspective of readability
by humans (i.e., no leading "+" sign and no leading zeros).</t>
</list></t>
<t>Special note to application developers: Compliance with this schema
in an otherwise correct translation from raw ("on-the-wire" representation)
SNMP MIB data produces values that are faithful to the original. However,
the Gauge32, Counter32, Counter64, and TimeTicks datatypes have special
application semantics that must be considered when using their raw values
for anything other than display, printing, storage, or transmission of the
literal value. RFC 2578 provides the necessary details.</t>
</section>
<section title="OctetString">
<t>This XSD datatype corresponds to the SMI "OCTET STRING" datatype.</t>
<t>Several independent schemes for mapping SMI datatypes to XSD have used
the XSD "string" type to represent "OCTET STRING", but this mapping does
not conform to the requirements specified in this document. Most notably,
"string" cannot faithfully represent all valid values (0 thru 255) that
each octet in an "OCTET STRING" can have -- or at least cannot do so in a
way that provides for easy human readability of the resulting XML output.</t>
<t>Consequently, the XSD datatype "hexBinary" is specified as the standard
mapping of the SMI "OCTET STRING" datatype. In hexBinary, each octet is
encoded as two hexadecimal digits; the canonical representation limits the
set of allowed hexadecimal digits to 0-9 and uppercase A-F.</t>
<t>The hexBinary representation of "OCTET STRING" complies with the relevant
requirements:
<list style="symbols">
<t>It covers all valid values for the corresponding SMI datatype.</t>
<t>It complies with the standard encoding rules associated with the
corresponding SMI datatype.</t>
<t>With the "maxLength" restriction to 65535 octets, the XSD datatype
specification matches the restrictions associated with the corresponding
SMI datatype.</t>
<t>It is the most direct XSD datatype which exhibits the foregoing
characteristics relative to the corresponding SMI datatype (which must
allow for any valid binary octet value).</t>
<t>The XML output produced from the canonical representation of this
XSD datatype is not optimal with respect to readability by humans; however,
that is a consequence of the SMI datatype itself. Where human readability
is more of a concern, it is likely that the actual MIB objects in question
will be represented by textual conventions which limit the set of values
that will be included in the OctetStrings and will, thus, bypass the
hexBinary typing.</t>
</list></t>
</section>
<section title="Opaque">
<t>The "hexBinary" XSD datatype is specified as the representation of the
SMI "Opaque" datatype generally for the same reasons as "hexBinary" is
specified for the "OctetString" datatype:
<list style="symbols">
<t>It covers all valid values for the corresponding SMI datatype.</t>
<t>It complies with the standard encoding rules associated with the
corresponding SMI datatype.</t>
<t>There are no restriction issues associated with using "hexBinary" for
"Opaque".</t>
<t>It is the most direct XSD datatype which exhibits the foregoing
characteristics relative to the corresponding SMI datatype (which must
allow for any valid binary octet value).</t>
<t>The XML output produced from the canonical representation of this
XSD datatype is not optimal with respect to readability by humans; however,
that is a consequence of the SMI datatype itself. Unmediated "Opaque"
data is intended for consumption by applications, not humans.</t>
</list></t>
</section>
<section title="IpAddress">
<t>The XSD "string" datatype is the natural choice to represent an IpAddress
as XML output. The "pattern" restriction applied in this case results in
a dotted-decimal string of four values between "0" and "255" separated by
a period (".") character. This pattern also precludes leading zeros.</t>
<t>Note that the SMI relies upon Textual Conventions (TCs) to specify
an IPv6 address. As such, the representation of an IPv6 address as an XSD
datatype is beyond the scope of this document.</t>
</section>
<section title="ObjectIdentifier">
<t>This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER" datatype.</t>
<t>The XSD "string" datatype is also the natural choice to represent an
ObjectIdentifier as XML output, for the same reasons as for the IpAddress
choice. The "pattern" restriction applied in this case results in a
dotted-decimal string of up to 128 elements (referred to as "sub-ids"),
each holding an "Unsigned32" integer value.</t>
<t>Note that the first two components of an "OBJECT IDENTIFIER" each have
a limited range of values as indicated in the XSD pattern restriction and
as described in The ASN1.1/BER standard <xref target="ASN.1"/>.</t>
<t>There are three values allocated for the root node, and at most
39 values for nodes subordinate to a root node value of 0 or 1.</t>
<t>The minimum length of an "OBJECT IDENTIFIER" is two sub-ids and
the representation of a zero-valued "OBJECT IDENTIFIER" is "0.0".</t>
<t>Note that no explicit "minLength" restriction, which would be "3" to allow for the
minimum of two sub-ids and a single separating dot, is required since the
pattern itself enforces this restriction.</t>
</section>
<!--
<section title="ObjectIdentifier">
<t>This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER" datatype.</t>
<t>The XSD "string" datatype is also the natural choice to represent an
ObjectIdentifier as XML output, for the same reasons as for the IpAddress
choice. The "pattern" restriction applied in this case results in a
dotted-decimal string of up to 128 elements (referred to as "sub-ids"),
each holding an "Unsigned32" integer value.</t>
<t>Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to the use
of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules (BER) the first
two components of an "OBJECT IDENTIFIER" have limited value ranges and are
encoded into a single sub-id value <xref target="Steedman"/>. The ASN.1/BER
standards specify that the numerical value of the first sub-identifier is
derived from the values of the first two "OBJECT IDENTIFIER" components in
the value being encoded, using the formula: (X*40) + Y, where X is the value
of the first component and Y is the value of the second component. This
packing of the first two components recognizes that only three values are
allocated from the root node, and at most 39 subsequent values from nodes
reached by X = 0 and X = 1. The minimum length of an "OBJECT IDENTIFIER"
is two sub-ids (with a zero-valued "OBJECT IDENTIFIER" represented as "0.0").
No explicit "minLength" restriction (which would be "3" to allow for the
minimum of two sub-ids and a single separating dot) is required, since the
pattern itself enforces this restriction.</t>
</section>
-->
</section>
<!-- SECURITY CONSIDERATIONS -->
<section title="Security Considerations">
<t>Security considerations for any given SMI MIB module are likely to be
relevant to any XSD/XML mapping of that MIB module; however, the mapping
defined in this document does not itself introduce any new security
considerations.</t>
<t>If and when proxies or gateways are developed to convey SNMP management
information from SNMP agents to XML-based management applications via
XSD/XML mapping of MIB modules based on this specification and its planned
siblings, special care will need to be taken to ensure that all applicable
SNMP security mechanisms are supported in an appropriate manner yet to be
determined.</t>
</section>
<section title="IANA Considerations">
<t>In accordance with RFC 3688 <xref target="RFC3688"/>, we request the
following namespace and schema registrations associated with this document
in the IANA XML Registry:
<list style="symbols">
<t>urn:ietf:params:xml:ns:opsawg:smi:base:[version_id]</t>
<t>urn:ietf:params:xml:schema:opsawg:smi:base:[version_id]</t>
</list></t>
<section title="SMI Base Datatypes Namespace Registration">
<t>This document registers a URI for the SMI Base Datatypes XML namespace
in the IETF XML registry. Following the format in RFC 3688, IANA has
made the following registration:</t>
<t>URI: urn:ietf:params:xml:ns:opsawg:smi:base:1.0</t>
<t>Registration Contact: The IESG.</t>
<t>XML: N/A, the requested URI is an XML namespace.</t>
</section>
<section title="SMI Base Datatypes Schema Registration">
<t>This document registers a URI for the SMI Base Datatypes XML schema
in the IETF XML registry. Following the format in RFC 3688, IANA has
made the following registration:</t>
<t>URI: urn:ietf:params:xml:schema:opsawg:smi:base:1.0</t>
<t>Registration Contact: The IESG.</t>
<t>XML: Section 4 of this document.</t>
</section>
</section>
<section title="Acknowledgements">
<t>Dave Harrington provided strategic and technical leadership to the
team which developed this particular specification. Yan Li did much
of the research into existing approaches that was used as a baseline for
the recommendations in this particular specification.</t>
<t>This document owes much to draft-romascanu-netconf-datatypes-xx and to
many other sources (including libsmi and group discussions on the NETCONF
mailing lists) developed by those who have researched and published candidate
mappings of SMI datatypes to XSD.</t>
<t>Individuals who participated in various discussions of this topic at
IETF meetings and on IETF mailing lists include: Ray Atarashi, Yoshifumi
Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Rob Ennes,
Mehmet Ersue, David Harrington, Alfred Hines, Eliot Lear, Chris Lonvick,
Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre Westerinen, and Bert
Wijnen.</t>
</section>
</middle>
<back>
<!-- NORMATIVE REFERENCES -->
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="s." surname="Bradner" fullname="Scott Brander">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document:
<list>
<t>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.</t>
</list>
</t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"
type="TXT" />
<format octets="16553"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5703"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC1155">
<front>
<title abbrev="SMI">Structure and identification of management information for TCP/IP-based internets</title>
<author initials="M." surname="Rose" fullname="Marshall T. Rose">
<organization>Performance Systems International, Inc.</organization>
<address>
<postal>
<street>P.O. Box 391776</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>
<phone>+1 415 961 3380</phone>
<email>mrose@PSI.COM</email>
</address>
</author>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie">
<organization>Hughes LAN Systems, The Wollongong Group</organization>
<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>
<phone>+1 415 962 7160</phone>
<email>sytek!kzm@HPLABS.HP.COM</email>
</address>
</author>
<date year="1990" day="1" month="May"/>
</front>
<seriesInfo name="STD" value="16"/>
<seriesInfo name="RFC" value="1155"/>
<format type="TXT" octets="40927" target="ftp://ftp.isi.edu/in-notes/rfc1155.txt"/>
</reference>
<reference anchor="RFC2578">
<front>
<title abbrev="SMIv2">Structure of Management Information Version 2
(SMIv2)</title>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie"
role="editor">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country>
</postal>
<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>
<author initials="D." surname="Perkins" fullname="David Perkins"
role="editor">
<organization>SNMPinfo</organization>
<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>USA</country>
</postal>
<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email>
</address>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder"
role="editor">
<organization>TU Braunschweig</organization>
<address>
<postal>
<street>Bueltenweg 74/75</street>
<street>38106 Braunschweig</street>
<country>Germany</country>
</postal>
<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>
<date month="April" year="1999"/>
</front>
<seriesInfo name="STD" value="58"/>
<seriesInfo name="RFC" value="2578"/>
</reference>
<reference anchor='RFC3584'>
<front>
<title>Coexistence between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework</title>
<author initials='R.' surname='Frye' fullname='R. Frye'>
<organization/></author>
<author initials='D.' surname='Levi' fullname='D. Levi'>
<organization/></author>
<author initials='S.' surname='Routhier' fullname='S. Routhier'>
<organization/></author>
<author initials='B.' surname='Wijnen' fullname='B. Wijnen'>
<organization/></author>
<date year='2003' month='August' />
</front>
<seriesInfo name='BCP' value='74' />
<seriesInfo name='RFC' value='3584' />
<format type='TXT' octets='115222' target='ftp://ftp.isi.edu/in-notes/rfc3584.txt' />
</reference>
<reference anchor="XML" target="http://www.w3.org/TR/1998/REC-xml-19980210">
<front>
<title>Extensible Markup Language (XML) 1.0</title>
<author>
<organization abbrev="W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>
<phone>+ 1 617 253 2613</phone>
<facsimile>+ 1 617 258 5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3c.org</uri>
</address>
</author>
<date month="February" year="1998"/>
</front>
<seriesInfo name="W3C" value="XML"/>
</reference>
<reference anchor="XMLSchema" target="http://www.w3.org/TR/xmlschema-1/">
<front>
<title>XML Schema Part 1: Structures Second Edition</title>
<author>
<organization abbrev="W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>
<phone>+ 1 617 253 2613</phone>
<facsimile>+ 1 617 258 5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3c.org</uri>
</address>
</author>
<date month="October" year="2004"/>
</front>
<seriesInfo name="W3C" value="XML Schema"/>
</reference>
<reference anchor="XSDDatatypes" target="http://www.w3.org/TR/xmlschema-2/">
<front>
<title>XML Schema Part 2: Datatypes Second Edition</title>
<author>
<organization abbrev="W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>
<phone>+ 1 617 253 2613</phone>
<facsimile>+ 1 617 258 5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3c.org</uri>
</address>
</author>
<date month="October" year="2004"/>
</front>
<seriesInfo name="W3C" value="XML Schema"/>
</reference>
</references>
<!-- INFORMATIONAL REFERENCES -->
<references title="Informational References">
<reference anchor="RFC2579">
<front>
<title>Textual Conventions for SMIv2</title>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country>
</postal>
<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>
<author initials="D." surname="Perkins" fullname="David Perkins">
<organization>SNMPinfo</organization>
<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>USA</country>
</postal>
<phone>+1 408 221-8702</phone>
<email>dperkins@snmpinfo.com</email>
</address>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder">
<organization>TU Braunschweig</organization>
<address>
<postal>
<street>Bueltenweg 74/75</street>
<city>Braunschweig</city>
<code>38106</code>
<country>Germany</country>
</postal>
<phone>+49 531 391-3283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>
<date month="April" year="1999"/>
</front>
<seriesInfo name="STD" value="58"/>
<seriesInfo name="RFC" value="2579"/>
</reference>
<reference anchor='RFC3688'>
<front>
<title>The IETF XML Registry</title>
<author initials='M.' surname='Mealling' fullname='M. Mealling'>
<organization/></author>
<date year='2004' month='January' />
<abstract>
<t>This document describes an IANA maintained registry for IETF standards
which use Extensible Markup Language (XML) related items such as Namespaces,
Document Type Declarations (DTDs), Schemas, and Resource Description Framework
(RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='81' />
<seriesInfo name='RFC' value='3688' />
<format type='TXT' octets='17325' target='ftp://ftp.isi.edu/in-notes/rfc3688.txt' />
</reference>
<reference anchor="ASN.1">
<front>
<title>Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1)
</title>
<author>
<organization>International Organization for Standardization</organization>
<address/>
</author>
<date month="December" year="1987"/>
</front>
<seriesInfo name="International Standard" value="8825"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:25 |