draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt   draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt 
Network Working Group B. Natale, Ed. Network Working Group B. Natale, Ed.
Internet-Draft MITRE Internet-Draft MITRE
Intended status: Standards Track Y. Li, Ed. Intended status: Standards Track Y. Li, Ed.
Expires: August 14, 2008 Huawei Technologies Expires: August 28, 2008 Huawei Technologies
February 11, 2008 February 25, 2008
Expressing SNMP SMI Datatypes in XML Schema Definition Language Expressing SNMP SMI Datatypes in XML Schema Definition Language
draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo defines the IETF standard expression of Simple Network This memo (when approved as a standards-track RFC) defines the IETF
Management Protocol (SNMP) Structure of Management Information (SMI) standard expression of Structure of Management Information (SMI) base
datatypes in eXtensible Markup Language (XML) Schema Definition (XSD) datatypes in Extensible Markup Language (XML) Schema Definition (XSD)
language. The primary objective of this memo is to enable production language. The primary objective of this memo is to enable production
of XML documents that are as faithful to the SMI as possible, using of XML documents that are as faithful to the SMI as possible, using
XSD as the validation mechanism. XSD as the validation mechanism.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. XSD for SMI Datatypes . . . . . . . . . . . . . . . . . . . . 5 4. XSD for SMI Datatypes . . . . . . . . . . . . . . . . . . . . 5
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 7 5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 7
5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 9 5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informational References . . . . . . . . . . . . . . . . . 11
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Numerous uses exist -- both within and outside the traditional IETF Numerous uses exist -- both within and outside the traditional IETF
network management industry -- for the expression of management network management community -- for the expression of management
information described in and accessible via SNMP Management information described in and accessible via SMI Management
Information Bases (MIBs) as XML documents [ref.XML]. For example, Information Base (MIB) modules as XML documents [ref.XML]. For
XML-based management applications which want to incorporate SNMP MIBs example, XML-based management applications which want to incorporate
as data models and/or to access SNMP MIB instrumentation via gateways MIB modules as data models and/or to access MIB module
to SNMP agents will benefit from an IETF standard mapping of MIB instrumentation via gateways to SNMP agents will benefit from an IETF
datatypes and structures to XML documents via XSD. standard mapping of SMI datatypes and structures to XML documents via
XSD.
MIB data models are described using SMIv2 [RFC2578] and, for legacy MIB data models are described using SMIv2 [RFC2578] and, for legacy
MIBs, SMIv1 [RFC1155]. MIB data is conveyed via SNMP using the MIBs, SMIv1 [RFC1155]. MIB data is conveyed via SNMP using the base
datatypes defined in the SMI. The SMI allows for creation of datatypes defined in the SMI. The SMI allows for creation of
derivative datatypes, termed "textual conventions" ("TCs"), each of derivative datatypes, termed "textual conventions" ("TCs"), each of
which has a unique name, a syntax based on a core SMI datatype, and which has a unique name, a syntax based on a core SMI datatype, and
relatively precise application-level semantics. TCs are used relatively precise application-level semantics. TCs are used
principally to facilitate correct application-level handling of MIB principally to facilitate correct application-level handling of MIB
data and for the convenience of humans reading MIB modules and data and for the convenience of humans reading MIB modules and
appropriately rendered MIB data output. appropriately rendered MIB data output.
Various independent schemes have been devised for expressing the SMI Various independent schemes have been devised for expressing the SMI
datatypes and textual conventions in XSD [ref.XMLSchema]. These datatypes and TCs in XSD [ref.XMLSchema]. These schemes have
schemes have exhibited a degree of commonality (especially concerning exhibited a degree of commonality (especially concerning the numeric
the numeric SMI datatypes), but also sufficient differences SMI datatypes), but also sufficient differences (especially
(especially concerning the non-numeric SMI datatypes) to preclude concerning the non-numeric SMI datatypes) to preclude general
general interoperability. interoperability.
The primary purpose of this memo is to define a standard expression The primary purpose of this memo is to define a standard expression
of SMI datatypes in XSD to ensure uniformity and general of SMI base datatypes in XSD to ensure uniformity and general
interoperability in this respect. Internet operators, management interoperability in this respect. Internet operators, management
tool developers, and users will benefit from the wider selection of tool developers, and users will benefit from the wider selection of
management tools and the greater degree of unified management -- with management tools and the greater degree of unified management -- with
attendant improvements in timeliness and accuracy of management attendant improvements in timeliness and accuracy of management
information -- which such a standard will facilitate. information -- which such a standard will facilitate.
This memo is the first in a set of three related and (logically) This memo is the first in a set of three related and (logically)
ordered specifications: ordered specifications:
1. SNMP SMI Datatypes [RFC2578] in XSD 1. SMI Base Datatypes [RFC2578] in XSD
2. SNMP MIB Structure [RFC2578] in XSD 2. SMI MIB Structure [RFC2578] in XSD
3. SNMP Textual Conventions [RFC2579] in XSD 3. SNMP Textual Conventions [RFC2579] in XSD
As a set, these documents define the XSD equivalent of SMIv2 to As a set, these documents define the XSD equivalent of SMIv2 to
encourage XML-based protocols to carry, and XML-based applications to encourage XML-based protocols to carry, and XML-based applications to
use, the information modeled in the SMIv2-compliant Management use, the information modeled in SMIv2-compliant MIB modules.
Information Base ("The MIB").
This work will define XSD equivalents of the datatypes and data This work defines XSD equivalents of the datatypes and data
structures [RFC2578]" and the textual conventions [RFC2579] defined structures [RFC2578] and the textual conventions [RFC2579] defined in
in the SMIv2 standard (STD58) to encourage efficient reuse of the SMIv2 standard (STD58) to encourage efficient reuse of existing
existing (including future) MIB modules and instrumentation by XML- (including future) MIB modules and instrumentation by XML-based
based management protocols and applications. management protocols and applications.
The goal of fidelity to the SMIv2 standard (STD58), as specified in The goal of fidelity to the SMIv2 standard (STD58), as specified in
the "Requirements" section below, is crucial to this effort to the "Requirements" section below, is crucial to this effort to
leverage the established "rough consensus" for the precise data leverage the established "rough consensus" for the precise data
modeling used in MIB modules, and to leverage existing "running code" modeling used in MIB modules, and to leverage existing "running code"
for implemented SMIv2 data models. This effort does not include for implemented SMIv2 data models. This effort does not include
redesign of SMIv2 datatypes or data structures or textual conventions redesign of SMIv2 datatypes or data structures or textual conventions
to overcome known limitations -- that work can be pursued in other to overcome known limitations -- that work can be pursued in other
efforts. efforts.
skipping to change at page 4, line 38 skipping to change at page 4, line 38
identified by [DISCUSS] markers in the text. identified by [DISCUSS] markers in the text.
3. Requirements 3. Requirements
R1. All SMI datatypes MUST have a corresponding XSD datatype. R1. All SMI datatypes MUST have a corresponding XSD datatype.
R2. SMIv2 is the normative SMI for this document -- SMIv1 modules, R2. SMIv2 is the normative SMI for this document -- SMIv1 modules,
if encountered, MUST be converted (at least logically) in if encountered, MUST be converted (at least logically) in
accordance with Section 2.1, inclusive, of the "Coexistence" RFC accordance with Section 2.1, inclusive, of the "Coexistence" RFC
[RFC3584]. [RFC3584].
R3. The XSD datatype specified for a given SMI datatype MUST be able R3. The XSD datatype specified for a given SMI datatype MUST be able
to represent all valid values for that SMI datatype, and only to represent all valid values for that SMI datatype.
those values.
R4. The XSD datatype specified for a given SMI datatype MUST R4. The XSD datatype specified for a given SMI datatype MUST
represent any special encoding rules associated with that SMI represent any special encoding rules associated with that SMI
datatype. datatype.
R5. The XSD datatype specified for a given SMI datatype MUST include R5. The XSD datatype specified for a given SMI datatype MUST include
any restrictions on values associated with the SMI datatype. any restrictions on values associated with the SMI datatype.
R6. The XSD datatype specified for a given SMI datatype MUST be the R6. The XSD datatype specified for a given SMI datatype MUST be the
most direct XSD datatype, with the most parsimonious most direct XSD datatype, with the most parsimonious
restrictions, which matches the foregoing requirements. restrictions, which matches the foregoing requirements.
R7. The XML output produced as a result of meeting the foregoing R7. The XML output produced as a result of meeting the foregoing
requirements SHOULD be the most direct from the perspective of requirements SHOULD be the most direct (i.e., avoiding
readability by humans. superfluous "decoration") from the perspective of readability by
humans.
[DISCUSS} Should any requirements be added, deleted, re-worded? [DISCUSS} Should any requirements be added, deleted, re-worded?
4. XSD for SMI Datatypes 4. XSD for SMI Datatypes
This document concerns the SMI datatypes that are carried "on-the- This document concerns the SMI base datatypes. These are carried
wire" -- i.e., have tag values defined in the SMI carried in varbinds "on-the-wire" (and, therefore, have tag values defined in the SMI to
in SNMP PDUs -- between SNMP management applications and SNMP agents: identify them in varbinds) in SNMP PDUs between SNMP management
applications and SNMP agents:
o INTEGER o INTEGER, Integer32
o Integer32 o Unsigned32, Gauge32
o Unsigned32
o Counter32 o Counter32
o Gauge32
o TimeTicks o TimeTicks
o Counter64 o Counter64
o OctetString o OctetString
o Opague o Opague
o IpAddress o IpAddress
o ObjectIdentifier o ObjectIdentifier
The following should be considered a "notional" XSD file for now, The following should be considered a "notional" XSD file for now,
pending agreement on the actual datatype specifications. An pending agreement on the actual datatype specifications. An
appropriate (official) targetNamespace must be designated (and appropriate (official) targetNamespace must be designated (and
skipping to change at page 6, line 4 skipping to change at page 5, line 50
<xs:restriction base="xs:int"/> <xs:restriction base="xs:int"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="Integer32"> <xs:simpleType name="Integer32">
<xs:restriction base="xs:int"/> <xs:restriction base="xs:int"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="Unsigned32"> <xs:simpleType name="Unsigned32">
<xs:restriction base="xs:unsignedInt"/> <xs:restriction base="xs:unsignedInt"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="Counter32">
<xs:simpleType name="Gauge32">
<xs:restriction base="xs:unsignedInt"/> <xs:restriction base="xs:unsignedInt"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="Gauge32"> <xs:simpleType name="Counter32">
<xs:restriction base="xs:unsignedInt"/> <xs:restriction base="xs:unsignedInt"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="TimeTicks"> <xs:simpleType name="TimeTicks">
<xs:restriction base="xs:unsignedInt"/> <xs:restriction base="xs:unsignedInt"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="Counter64"> <xs:simpleType name="Counter64">
<xs:restriction base="xs:unsignedLong"/> <xs:restriction base="xs:unsignedLong"/>
</xs:simpleType> </xs:simpleType>
skipping to change at page 7, line 35 skipping to change at page 7, line 35
of the "lexical representations") documented in the W3C XSD of the "lexical representations") documented in the W3C XSD
specifications are assumed. specifications are assumed.
[DISCUSS] The use of "canonical representations" in the XSD specs [DISCUSS] The use of "canonical representations" in the XSD specs
might merit review by others. This author's (Natale) understanding might merit review by others. This author's (Natale) understanding
might not be complete or correct. might not be complete or correct.
5.1. Numeric Datatypes 5.1. Numeric Datatypes
All of the numeric XSD datatypes specified in the previous section -- All of the numeric XSD datatypes specified in the previous section --
INTEGER, Integer32, Unsigned32, Counter32, Counter, Gauge32, Gauge, INTEGER, Integer32, Unsigned32, Gauge32, Counter32, TimeTicks, and
TimeTicks, and Counter64 -- comply with the relevant requirements: Counter64 -- comply with the relevant requirements:
o They cover all valid values for the corresponding SMI datatypes. o They cover all valid values for the corresponding SMI datatypes.
o They comply with the standard encoding rules associated with the o They comply with the standard encoding rules associated with the
corresponding SMI datatypes. corresponding SMI datatypes.
o They inherently match the range restrictions associated with the o They inherently match the range restrictions associated with the
corresponding SMI datatypes. corresponding SMI datatypes.
o They are the most direct XSD datatype which exhibit the foregoing o They are the most direct XSD datatype which exhibit the foregoing
characteristics relative to the corresponding SMI datatypes (which characteristics relative to the corresponding SMI datatypes (which
is why no "restriction" statements are required in the XSD). is why no "restriction" statements -- other than the "base" XSD
type -- are required in the XSD).
o The XML output produced from the canonical representation of these o The XML output produced from the canonical representation of these
XSD datatypes is also the most direct from the perspective of XSD datatypes is also the most direct from the perspective of
readability by humans (i.e., no leading "+" sign and no leading readability by humans (i.e., no leading "+" sign and no leading
zeros). zeros).
5.2. OctetString 5.2. OctetString
This XSD datatype corresponds to the SMI "OCTET STRING" datatype. This XSD datatype corresponds to the SMI "OCTET STRING" datatype.
Several independent schemes for mapping SMI datatypes to XSD have Several independent schemes for mapping SMI datatypes to XSD have
skipping to change at page 9, line 45 skipping to change at page 9, line 45
the core requirements for allowable value sequences)? the core requirements for allowable value sequences)?
5.5. ObjectIdentifier 5.5. ObjectIdentifier
This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER" This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"
datatype. datatype.
The XSD "string" datatype is also the natural choice to represent an The XSD "string" datatype is also the natural choice to represent an
ObjectIdentifier as XML output, for the same reasons as for the ObjectIdentifier as XML output, for the same reasons as for the
IpAddress choice. The "pattern" restriction applied in this case IpAddress choice. The "pattern" restriction applied in this case
results in a dotted- decimal string of up to 128 elements (referred results in a dotted-decimal string of up to 128 elements (referred to
to as "sub-ids"), holding "Unsigned32" integer values. as "sub-ids"), holding "Unsigned32" integer values.
Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to the
encoding rules the first two sub-ids of an "OBJECT IDENTIFIER" have use of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules
limited value ranges ([0-2] and [0-39], respectively), and the (BER) the first two sub-ids of an "OBJECT IDENTIFIER" have limited
minimum length of an "OBJECT IDENTIFIER" is two sub-ids (with a zero- value ranges ([0-2] and [0-39], respectively) and are packed into a
valued "OBJECT IDENTIFIER" represented as "0.0"). No explicit single octet [Steedman], and the minimum length of an "OBJECT
"minLength" restriction (which would be "3" to allow for the minimum IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER"
of two sub-ids) is required, since the pattern itself enforces this 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. restriction.
[DISCUSS] The pattern specified for ObjectIdentifier attempts to [DISCUSS] The pattern specified for ObjectIdentifier attempts to
faithfully capture the restrictions mentioned above. Does it do so faithfully capture the restrictions mentioned above. Does it do so
correctly and is there a more efficient way of doing so? correctly and is there a more efficient way of doing so?
6. Security Considerations 6. Security Considerations
Security considerations for any given MIB are likely to be relevant Security considerations for any given SMI MIB module are likely to be
to any XSD/XML mapping of that MIB. relevant to any XSD/XML mapping of that MIB module; however, this
mapping itself does not introduce any new security considerations.
If and when proxies or gateways are developed to convey SNMP If and when proxies or gateways are developed to convey SNMP
management information from SNMP agents to XML-based management management information from SNMP agents to XML-based management
applications via XSD/XML mapping of MIBs based on this specification applications via XSD/XML mapping of MIB modules based on this
and its planned siblings, special care will need to be taken to specification and its planned siblings, special care will need to be
ensure that any SNMPv3 security mechanisms are supported in an taken to ensure that all applicable SNMP security mechanisms are
appropriate manner yet to be determined. supported in an appropriate manner yet to be determined.
7. IANA Considerations 7. IANA Considerations
[DISCUSS] We will likely need namespace and location resources from [DISCUSS] We will likely need namespace and location resources from
IANA...?. IANA...?.
8. Acknowledgements 8. Acknowledgements
Dave Harrington provided strategic and technical leadership to the Dave Harrington provided strategic and technical leadership to the
team which developed this particular specification. Yan Li did much team which developed this particular specification. Yan Li did much
of the research into existing approaches that was used as a baseline of the research into existing approaches that was used as a baseline
for the recommendations in this particular specification. for the recommendations in this particular specification.
This document owes much to draft-romascanu-netconf-datatypes-xx and This document owes much to draft-romascanu-netconf-datatypes-xx and
to many other sources (including libsmi and group discussions on the to many other sources (including libsmi and group discussions on the
NETCONF mailing lists) developed by those who have researched and NETCONF mailing lists) developed by those who have researched and
published candidate mappings of SMI datatypes and textual conventions published candidate mappings of SMI datatypes and textual conventions
to XSD. to XSD.
[TODO] Add an "Informational References" section documenting prior Individuals who participated in various discussions of this topic at
developmental publications and implementations.
Individuals who participated in earlier discussions of this topic at
IETF meetings and on IETF mailing lists include: Sharon Chisholm, IETF meetings and on IETF mailing lists include: Sharon Chisholm,
David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Andy David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Andy
Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear, Avri Doria, Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear, Avri Doria,
Juergen Schoenwaelder, Rob Ennes, Faye Ly and Andre Westerinen. Juergen Schoenwaelder, Rob Ennes, Faye Ly and Andre Westerinen.
[TODO] Expand list of participants as appropriate. [TODO] Expand list of participants as appropriate.
9. Normative References 9. References
9.1. Normative References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and [RFC1155] Rose, M. and K. McCloghrie, "Structure and
identification of management information for TCP/ identification of management information for TCP/
IP-based internets", STD 16, RFC 1155, May 1990. IP-based internets", STD 16, RFC 1155, May 1990.
[RFC2119] Bradner, s., "Key words for use in RFCs to [RFC2119] Bradner, s., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997. March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
skipping to change at page 11, line 45 skipping to change at page 11, line 47
<http://www.w3.org/TR/1998/REC-xml-19980210>. <http://www.w3.org/TR/1998/REC-xml-19980210>.
[ref.XMLSchema] World Wide Web Consortium, "XML Schema Part 1: [ref.XMLSchema] World Wide Web Consortium, "XML Schema Part 1:
Structures Second Edition", W3C XML Schema, Structures Second Edition", W3C XML Schema,
October 2004, <http://www.w3.org/TR/xmlschema-1/>. October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[ref.XSDDatatype] World Wide Web Consortium, "XML Schema Part 2: [ref.XSDDatatype] World Wide Web Consortium, "XML Schema Part 2:
Datatypes Second Edition", W3C XML Schema, Datatypes Second Edition", W3C XML Schema,
October 2004, <http://www.w3.org/TR/xmlschema-2/>. October 2004, <http://www.w3.org/TR/xmlschema-2/>.
9.2. Informational References
[Steedman] Steedman, D., "ASN.1: The Tutorial and Reference".
Appendix A. Open Issues Appendix A. Open Issues
o Resolve all [TODO] items. o Resolve all [TODO] items.
o Resolve all [DISCUSS] items. o Resolve all [DISCUSS] items.
Appendix B. Change Log Appendix B. Change Log
-00 Initial version o -00 Initial version
o -01 version:
o
* Incorporated mailing list comments on -00 version from Juergen
Schoenwaelder
* Incorporated mailing list comments on -00 version from David
Harrington
Authors' Addresses Authors' Addresses
Bob Natale (editor) Bob Natale (editor)
MITRE MITRE
7515 Colshire Dr 7515 Colshire Dr
MS H405 MS H405
McLean, VA 22102 McLean, VA 22102
USA USA
 End of changes. 29 change blocks. 
69 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/