wdiff draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt draft-ietf-opsawg-smi-datatypes-in-xsd-06.txt

Network Working Group B. Natale M. Ellison
Internet-Draft MITRE Ellison Software Consulting
Intended status: Standards Track March 27, 2009 B. Natale
Expires: September 27, 2009 2, 2010 MITRE
March 1, 2010

Expressing SNMP SMI Datatypes in XML Schema Definition Language
draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
draft-ietf-opsawg-smi-datatypes-in-xsd-06.txt

Abstract

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.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 27, 2009. 2, 2010.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.

Abstract

This memo defines the IETF standard expression of Structure of
Management Information (SMI) base datatypes Code Components extracted from this document must
include Simplified BSD License text as described in Extensible Markup
Language (XML) Schema Definition (XSD) language. The primary
objective Section 4.e of this memo is to enable
the production of XML documents
that Trust Legal Provisions and are provided without warranty as faithful to the SMI as possible, using XSD as
described in the
validation mechanism. BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. XSD for SMI Base Datatypes . . . . . . . . . . . . . . . . . . 7
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11
5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 10 11
5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 10 11
5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12
5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 12 13
5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 12 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 16
7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 14 16
7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 14 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 18
9.2. Informational References . . . . . . . . . . . . . . . . . 16
Author's Address . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 19

1. Introduction

Numerous uses use cases exist -- both within and outside the traditional IETF
network management community -- for expressing the expression of management information
described in and accessible via by SMI Management Information Base (MIB) modules as in XML documents
[XML]. Potential use cases reside both outside and within the
traditional IETF network management community. For example,
developers of some XML-based management applications which may want to
incorporate MIB
modules as the rich set of data models and/or provided by MIB modules.
Developers of other XML-based management applications may want to
access MIB module instrumentation via gateways to SNMP agents will agents. Such
applications benefit from an the IETF standard mapping of SMI datatypes
to XML documents datatypes via XSD. XSD [XMLSchema], [XSDDatatypes].

MIB data models are described using modules use SMIv2 [RFC2578] and, for to describe data models. For legacy
MIBs,
MIB modules, SMIv1 [RFC1155]. [RFC1155] was used. MIB data is conveyed in variable
bindings ("varbinds") within protocol data units (PDUs) within of SNMP
messages
using use the base/primitive primitive, base datatypes defined in by the SMI.

The SMI allows for the creation of derivative datatypes, termed "textual
conventions" ("TCs"), each of which ("TCs") [RFC2579]. A TC has a unique name, has a syntax which
is or
that either refines or is a primitive base SMI datatype, datatype and has relatively
precise application-level semantics. TCs are used principally to facilitate correct
application-level handling of MIB data and for the
convenience data, improve readability of humans reading MIB
modules by humans and appropriately rendered support appropriate renderings of MIB data output. data.

Values in varbinds corresponding to MIB objects defined with TC syntaxes
syntax are always encoded as the primitive base SMI datatype underlying the TC
syntax. Thus, the XSD mappings defined in this memo will provide support
for values of MIB objects defined with TC syntax as well as those for
values of MIB objects defined with base SMI syntax.

Various independent schemes have been devised for expressing the SMI
datatypes in XSD [XMLSchema]. XSD. These schemes have exhibited exhibit a degree of commonality (especially commonality,
especially concerning the numeric SMI datatypes), datatypes, but these schemes also
exhibit sufficient differences (especially differences, especially concerning the non-numeric
SMI datatypes) to preclude datatypes, precluding uniformity of expression and general
interoperability.

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.

The primary purpose of this memo is to define a the standard expression
of SMI base datatypes in XSD to ensure fidelity, consistency, XML documents that is both uniform and
general interoperability in this respect.
interoperable. This standard expression enables Internet operators,
management tool application developers, and users will to benefit from the a wider
selection
range of management tools and the to benefit from a greater degree of
unified
management -- with attendant improvements in timeliness and accuracy
of management information -- which such a standard facilitates.

On its own, this memo specifies the IETF management. Thus, standard way to render SMI
data values carried in SNMP messages as XML in a faithful,
consistent, expression enables and interoperable way.

Certain XML-based applications will find this specification
sufficient for their purposes. Other XML applications may need
facilitates improvements to
make more complete reuse of existing MIB modules, requiring standard
XSDs for TCs [RFC2579] and MIB structure [RFC2578]. Documents
supporting those requirements are planned, but have not been produced
at the time timeliness, accuracy and utility of this writing.
management information.

The overall objective of this memo, and of any future related specifications
that might future memos
as may be produced, published, is to define the XSD equivalent [XSDDatatypes]
of SMIv2 (STD58) and to encourage XML-based protocols to carry, and
XML-based applications to use, the management information modeled defined in
SMIv2-compliant MIB modules.

Having such The use of a standard mapping of from
SMIv2 to XML via XSD validation
will enable enables and promote promotes the efficient
reuse of existing (including
future) and future MIB modules and instrumentation by XML-based management XML-
based protocols and management applications.

The

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 [RFC2579] and MIB structure [RFC2578]. Memos
supporting such requirements are planned, but have not been produced
at the time of this writing.

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 to
leverage effort. Fidelity leverages the established
"rough consensus" for of the precise SMIv2 data
modeling used models contained in MIB
modules, and to leverage leverages existing instrumentation, the "running code"
for implemented
implementing SMIv2 data models. This effort does not include any
redesign of SMIv2 datatypes or datatypes, data structures or textual conventions
in order to overcome known limitations -- that limitations. Such work can be pursued in by
other efforts.

2. Conventions

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 [RFC2119].

3. Requirements

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:

R1. All SMI base datatypes MUST have a corresponding XSD datatype.

R2. SMIv2 is the normative SMI for this document -- document. Prior to mapping
datatypes into XSD, legacy SMIv1 modules,
if encountered, modules MUST be converted (at
least logically) in accordance with Section 2.1, inclusive, of
the "Coexistence" RFC [RFC3584].

R3. The XSD datatype specified for a given SMI datatype MUST be able
to represent all valid values for that SMI datatype.

R4. The XSD datatype specified for a given SMI datatype MUST
represent any special encoding rules associated with that SMI
datatype.

R5. The XSD datatype specified for a given SMI datatype MUST include
any restrictions on values associated with the SMI datatype.

R6. The XSD datatype specified for a given SMI datatype MUST be the
most direct logical XSD datatype, with the most parsimonious
restrictions, which matches fewest necessary
restrictions on its set of values, consistent with the foregoing
requirements.

R7. The XML output produced as a result of meeting the foregoing
requirements SHOULD be the most direct coherent and succinct
representation (i.e., avoiding superfluous "decoration") from
the perspective of readability by humans.

4. XSD for SMI Base Datatypes

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:

o INTEGER, Integer32

o Unsigned32, Gauge32

o Counter32

o TimeTicks

o Counter64

o OCTET STRING

o Opaque

o IpAddress

o OBJECT IDENTIFIER

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.

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

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 2578

Contact: Bob Natale
Organization: MITRE
Address: 7515 Colshire Drive
McLean VA 22102
USA
Telephone: +1 703-983-2505
E-Mail: rnatale@mitre.org
Last Updated: 200903090000Z 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

5. Rationale

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
specifications
specification [XMLSchema], [XSDDatatypes] are assumed.

5.1. Numeric Datatypes

All of the numeric XSD datatypes specified in the previous section --
INTEGER, Integer32, Unsigned32, Gauge32, Counter32, TimeTicks, and
Counter64 -- comply with the relevant requirements

o They cover all valid values for the corresponding SMI datatypes.

o They comply with the standard encoding rules associated with the
corresponding SMI datatypes.

o They inherently match the range restrictions associated with the
corresponding SMI datatypes.

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

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

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.

5.2. OctetString

This XSD datatype corresponds to the SMI "OCTET STRING" datatype.

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.

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.

The hexBinary representation of "OCTET STRING" complies with the
relevant requirements:

o It covers all valid values for the corresponding SMI datatype.

o It complies with the standard encoding rules associated with the
corresponding SMI datatype.

o With the "maxLength" restriction to 65535 octets, the XSD datatype
specification matches the restrictions associated with the
corresponding SMI datatype.

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

o 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.

5.3. Opaque

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:

o It covers all valid values for the corresponding SMI datatype.

o It complies with the standard encoding rules associated with the
corresponding SMI datatype.

o There are no restriction issues associated with using "hexBinary"
for "Opaque".

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

5.4. IpAddress

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.

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.

5.5. ObjectIdentifier

This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"
datatype.

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.

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) that the first two components of an "OBJECT IDENTIFIER" each
have limited
value ranges and are encoded into a single sub-id value [Steedman].
The ASN.1/BER standards specify that the numerical value limited range of the first
sub-identifier is derived from the values of the first two "OBJECT
IDENTIFIER" components as indicated in the value being encoded, using the formula:
(X*40) + Y, where X is the value of the first component XSD pattern
restriction and Y is the
value of the second component. This packing of the first two
components recognizes that only as described in The ASN1.1/BER standard [ASN.1].

There are three values are allocated from for the root node, and at most 39 subsequent
values from for nodes reached by X = subordinate to a root node value of 0 and X = or 1.

The minimum length of an "OBJECT IDENTIFIER" is two sub-ids (with and the
representation of a zero-valued "OBJECT IDENTIFIER" represented as
"0.0"). No is "0.0".

Note that no explicit "minLength" restriction (which restriction, which would be "3" to
allow for the minimum of two sub-ids and a single separating dot) dot, is
required,
required since the pattern itself enforces this restriction.

6. Security Considerations

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.

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.

7. IANA Considerations

In accordance with RFC 3688 [RFC3688], we request the following
namespace and schema registrations associated with this document in
the IANA XML Registry:

o urn:ietf:params:xml:ns:opsawg:smi:base:[version_id]

o urn:ietf:params:xml:schema:opsawg:smi:base:[version_id]

7.1. SMI Base Datatypes Namespace Registration

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:

URI: urn:ietf:params:xml:ns:opsawg:smi:base:1.0

Registration Contact: The IESG.

XML: N/A, the requested URI is an XML namespace.

7.2. SMI Base Datatypes Schema Registration

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:

URI: urn:ietf:params:xml:schema:opsawg:smi:base:1.0

Registration Contact: The IESG.

XML: Section 4 of this document.

8. Acknowledgements

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.

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.

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, Mark
Ellison, Rob
Ennes, Mehmet Ersue, David Harrington, Alfred Hines, Eliot Lear,
Chris Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre
Westerinen, and Bert Wijnen.

9. References

9.1. Normative References

[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990.

[RFC2119] Bradner, s., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
BCP 74, RFC 3584, August 2003.

9.2. Informational References

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.

[Steedman]
Steedman, D., "ASN.1: The Tutorial and Reference".

[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.

[XMLSchema]
World Wide Web Consortium, "XML Schema Part 1: Structures
Second Edition", W3C XML Schema, October 2004,
<http://www.w3.org/TR/xmlschema-1/>.

[XSDDatatypes]
World Wide Web Consortium, "XML Schema Part 2: Datatypes
Second Edition", W3C XML Schema, October 2004,
<http://www.w3.org/TR/xmlschema-2/>.

Author's Address

9.2. Informational References

[ASN.1] International Organization for Standardization,
"Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1)", International
Standard 8825, December 1987.

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.

Authors' Addresses

Mark Ellison
Ellison Software Consulting
38 Salem Road
Atkinson, NH 03811
USA

Phone: +1 603-362-9270
Email: ietf@ellisonsoftware.com

Bob Natale
MITRE
7515 Colshire Dr
MS H405
McLean, VA 22102
300 Sentinel Drive
6th Floor
Annapolis Junction, MD 20701
USA

Phone: +1 703-983-2505 301-617-3008
Email: rnatale@mitre.org