SIMPLE WG M. Thomson
Internet-Draft Andrew
Expires: June 16, 2006 December 13, 2005
A Document Format for Expressing XML Support (EXS)
draft-thomson-simple-expressing-xml-support-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of 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 June 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a simple XML format for expressing support for,
or understanding of sections of XML documents. This format is
designed for use in negotiating a common level of support in
protocols. XPath expressions are used to define which XML nodes
within any particular instance document are understood.
Thomson Expires June 16, 2006 [Page 1]
Internet-Draft Expressing XML Support December 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Feature Model . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Document Format . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Establishing a Common Schema Definition . . . . . . . . . 7
4.2. Indicating Support for an Entire Namespace . . . . . . . . 8
4.2.1. Specifying Schema Definitions for Namespaces . . . . . 8
4.3. Indicating Support for Individual Nodes . . . . . . . . . 9
4.3.1. Excluding Node Descendants . . . . . . . . . . . . . . 9
4.4. Establishing Contexts . . . . . . . . . . . . . . . . . . 10
4.5. Excluding Specific Nodes . . . . . . . . . . . . . . . . . 11
4.6. Excluded Node Types . . . . . . . . . . . . . . . . . . . 11
5. Simplified XPath Profile . . . . . . . . . . . . . . . . . . . 13
5.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 14
6. Testing for Support . . . . . . . . . . . . . . . . . . . . . 15
7. Expression of XML Support Schema . . . . . . . . . . . . . . . 16
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.1. MIME Type registration . . . . . . . . . . . . . . . . . . 22
10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 23
10.3. XML Schema Registration . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Thomson Expires June 16, 2006 [Page 2]
Internet-Draft Expressing XML Support December 2005
1. Introduction
Extensible Markup Language (XML) documents are widely used to express
data of all forms. One highly desirable feature of XML is that
documents are extensible, that is, additional functionality can be
added to a base document. For specifications, extensibility enables
a basic specification to address an existing need without
constraining the future use of the document and its future usage.
Similarly, a specification can define a framework upon which other
specifications may build solutions through extensibility, for example
[I-D.ietf-geopriv-common-policy].
Extensibility therefore offers a great deal of flexibility in
specification. However, extensibility can lead to arbitrary levels
of complexity, which could lead to interoperability issues. A
document created by one system can only be understood in its entirety
by another if the target system supports all the features used in the
document. In extreme cases, if a single fragment is not understood,
the entire document could be unusable.
To address this problem, interoperating systems need a method for
negotiating a common level of support. Negotiating support for
entire document formats can already be accomplished through the use
of MIME and protocol headers, such as the "Accept" header in HTTP and
SIP. However, a MIME type alone cannot express the rich set of
features that could be combined within an XML document, nor do MIME
types allow for expressing support for parts of a document.
This document defines an expression of XML support (EXS) document
format. An EXS document is created so that document generators can
determine if a generated document can be understood. An EXS document
is an XML document that specifies what features are understood by a
particular processor.
An EXS document can also be used to indicate to individual users the
level of service that they are permitted to access. This goes beyond
an expression about what a service can provide and provides
information on user permission.
EXS is based on the XPath grammar [W3C.REC-xpath-19991116], which is
a very rich and flexible tool for selecting XML nodes. In order to
simplify implementation, this document also defines a basic profile
of XPath that removes predicates and limits the axes that may be
used.
This document does not define methods for sharing or publishing EXS
documents. Different applications and protocols are responsible for
defining how this information is shared and any negotiation
Thomson Expires June 16, 2006 [Page 3]
Internet-Draft Expressing XML Support December 2005
completed.
Thomson Expires June 16, 2006 [Page 4]
Internet-Draft Expressing XML Support December 2005
2. Conventions used in this document
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 [RFC2119].
Terminology from the XPath specification [W3C.REC-xpath-19991116] is
used extensively in this document. This includes the following
terms: document, node, node-set, part, child, parent, descendant,
axis, document order.
Thomson Expires June 16, 2006 [Page 5]
Internet-Draft Expressing XML Support December 2005
3. Feature Model
XML documents model data of varying complexity. A _feature_ is an
abstraction that refers to the capacity of a document to convey a
particular unit of data.
Since the concept of a feature is abstract, they are not necessarily
discrete; that is, features can compose other features or overlap
with other features. For example, an element and its children could
be characterized as a single feature; or each child element could
each be characterized as a single feature; alternatively, a feature
could also be a collection of attributes distributed throughout a
document.
This document defines a simplified feature model where individual
features can be reduced to a node-set. A feature is expressed as a
single node or node-set. Typically, this a set of elements,
attributes and text nodes. This model is chosen because the nature
of XML is such that elements and attributes are the usual points
where extensibility is used.
The simple model presented in this document is not intended to be
exhaustively capable of specifying capabilities. The degree to which
this model is applicable depends on the application and the subset of
XPath that is used.
Thomson Expires June 16, 2006 [Page 6]
Internet-Draft Expressing XML Support December 2005
4. Document Format
An expression of XML support is made so that document generators can
determine if a generated document can be understood. An EXS document
is intended to be evaluated against a target document.
4.1. Establishing a Common Schema Definition
The EXS document format described in the following sections relies on
having a shared definition of XML document structure. This is
achieved primarily through the use of XML Schema definitions
[W3C.REC-xmlschema-1-20041028], although other schema definition
languages MAY be used.
A shared schema definition cannot be guaranteed by using the
namespace URI only. It is uncommon to have different schema
definitions sharing a namespace, therefore the schema definitions MAY
be omitted from an EXS document. However, the namespace alone cannot
be used to ensure a shared schema definition. Aside from the case
where two applications have different schema definitions, XML Schema
defines a "redefine" element that can be used to alter the
definitions for particular schema.
The "structure" element contains arbitrary content that is used to
define the schema used in the document. It is RECOMMENDED that this
section is included and that it contain a "schema" element from
[W3C.REC-xmlschema-1-20041028] that imports all necessary schema
documents.
Alternatively a common schema definition MAY be indicated through the
use of the "ns" attribute on the "namespace" element. This is
described in more detail in Section 4.2.
Schemas that are referenced by an EXS document and not included
directly within the "structure" element SHOULD be retrieved, even if
the schema for the given namespace is already known.
For example, the following EXS fragment defines document structure by
referencing an external schema document.
Note that schema definitions for published RFCs are not usually
Thomson Expires June 16, 2006 [Page 7]
Internet-Draft Expressing XML Support December 2005
published to a fixed location. For these schema, it is not necessary
to provide a schema definition, providing that the schema from the
published RFC is used. Schema URNs that are registered with IANA
SHOULD NOT be used in place of URLs.
4.2. Indicating Support for an Entire Namespace
Support for all nodes from a namespace is indicated by using the
"namespace" element. The namespace is indicated by the "ns"
attribute. This statement indicates that all nodes that belong to
given namespace are supported.
From the perspective of the XPath data model, a node is supported if
the namespace URI in the expanded-name of the node matches the value
of the namespace.
For example, the following minimal EXS document that indicates
support for an entire namespace:
The XPath data model states that attributes with no prefix do not
have a namespace URI in their expanded name. Similarly, text nodes
do not have an expanded name. For the purposes of testing for
support, all text children and attribute children that have no
namespace prefix belong to the same namespace as their parent
element.
For example, when the following document is evaluated against the
above statement, this selects the "yes:supported" element and its
text content, the "param" attribute and the "yes:info" attribute.
text content
This document format SHOULD only be used where namespaces in XML are
employed.
4.2.1. Specifying Schema Definitions for Namespaces
The "namespace" element also allows for references to schema
definitions, which may be used in place of the "structure" element.
Thomson Expires June 16, 2006 [Page 8]
Internet-Draft Expressing XML Support December 2005
The "schemaLocation" attribute indicates the location of the schema
definition for the given namespace. It is RECOMMENDED that this
attribute be included where possible to avoid any potential
miscommunication.
A "namespace" element MAY occur with the same namespace multiple
times within an EXS document, however the value of the
"schemaLocation" attribute MUST not have multiple different values
within the same document. An omitted "schemaLocation" attribute
indicates that the value is the same as an included "schemaLocation"
attribute for the same namespace.
Schema definitions MAY be included in the document through the use of
the "structure" element. In this case, the "schemaLocation"
attribute SHOULD be omitted, or it should contain a fragment URI
referring to the schema definition.
The following EXS fragment refers to the location of the schema for a
supported namespace:
4.3. Indicating Support for Individual Nodes
Support for individual nodes is indicated by using the "node"
element. The "path" attribute of this element includes an XPath
expression that selects a node-set from the target document.
For example, the following EXS document indicates that the entirety
of the "app:supported" element is supported as a child of the current
context:
Node expressions are evaluated in the current context, see
Section 4.4 for details. If the "app:supported" element is suported
in all contexts, then a value of "//app:supported" might be a better
expression.
4.3.1. Excluding Node Descendants
Unless otherwise specified, selecting a node using the "node" element
also selects all of its descendants. The "descendants" attribute
specifies the types of descendants are included. The value is a list
that MAY include any of the following values: "elements" (element
descendants are included), "attributes" (attribute descendants are
Thomson Expires June 16, 2006 [Page 9]
Internet-Draft Expressing XML Support December 2005
included) and "text" (text descendants are included). Unless the
value "elements" is included, only the immediate child attribute and
text nodes are included.
Two special values are also defined for convenience: "##all"
indicates that all descendants are included, and "##none" indicates
that no descendants are included. "##all" is the default value, which
is equivalent to "elements attributes text".
For example, the following EXS document indicates that the entirety
of the "app:supported" element and its attributes is understood.
Text and element descendants of these nodes are not supported.
The "descendants" attribute is particularly useful when an element
could contain any content. For instance, this is allowed by the
"any" or "anyAttribute" in XML Schema [W3C.REC-xmlschema-1-20041028].
Since the content model of the "ruleset" element (through its
descendants, see [I-D.ietf-geopriv-common-policy]) could include
arbitrary content, this statement constitutes an unlimited promise of
support. Where any content is allowed, this expression is NOT
RECOMMENDED, instead it SHOULD be limited by using the "descendants"
attribute.
4.4. Establishing Contexts
For the purposes of simplification of grouping the "context" enables
the selection of a document subset. The "path" attribute of this
element is an XPath expression that selects a node-set. Elements
that are nested within the "context" element are evaluated once for
each node in the context node-set.
Contexts MAY be nested within other contexts, in which case the path
expression for the context is evaluated within the context of each
node of the enclosing context node-set.
Within a context, a "namespace" element can only select descendants
of the context node, including the context node itself. Note that a
"node" element can select any node from the document, however it is
RECOMMENDED that nodes are only selected from the descendants of the
context node.
Thomson Expires June 16, 2006 [Page 10]
Internet-Draft Expressing XML Support December 2005
Since the "context" element selects a node-set that could contain any
number of nodes, it is RECOMMENDED that the node-set is restricted
sufficiently to limit the performance impact of evaluating nested
statements. If nested "context" statements are used, it is
RECOMMENDED that the node-set be restricted to a single node.
For example, the following EXS document indicates that the
"http://example.com/ns/app" namespace is understood within the
"enclosing" element only.
4.5. Excluding Specific Nodes
The "except" element MAY be included as a child of either the
"namespace" or "node" elements to indicate nodes that are excluded.
Similar to "node", the "except" element selects all descendants
unless the "descendants" attribute is used.
When nested with a "node" element, the "except" element is evaluated
as if the "node" element had established a context. That is.
For example, the following EXS fragment indicates support for the
"app:supported" element and all its contents, except for the
"app:exception" element (when it is a child of "app:supported").
4.6. Excluded Node Types
The EXS document format is aimed at the three primary XML node types:
elements, attributes and text. Support for other node types is
limited.
Namespace prefix declarations ("xmlns" attributes) MUST always be
supported, regardless of any statements to the contrary. "except"
elements MUST NOT select namespace prefix declarations.
Comment nodes SHOULD NOT be the subject of expressions of support.
Declarations that indicate support for comments SHOULD be ignored.
Note however, that comment nodes affect the XPath content model,
Thomson Expires June 16, 2006 [Page 11]
Internet-Draft Expressing XML Support December 2005
specifically text nodes; therefore, where text nodes are selected,
expressions might need to compensate for comment nodes.
Processing instructions SHOULD automatically be considered as
unsupported.
Thomson Expires June 16, 2006 [Page 12]
Internet-Draft Expressing XML Support December 2005
5. Simplified XPath Profile
This section defines a simplified profile of XPath that MAY be
required by protocols. This profile retains only the parts of the
XPath grammar that enable the selection of elements and attributes.
Protocols MAY use this profile, or define any other profile that most
suits the application. However, protocols that use this
specification MUST specify which XPath profile is required.
5.1. Grammar
This profile defines a simple XPath grammar that prohibits the use of
axes, except for the special axes "child", "self",
"descendent-or-self" and "attribute". These axes MUST be specified
using their abbreviated syntax only; they cannot be used with the
double-colon ("::") notation. Note that the parent axis ("..") is
not allowed by this profile.
Predicates are excluded from this grammar, as are operators and all
functions except the "node()" and "text()" functions. This grammar
excludes support for selecting comments and processing instructions.
The following ABNF grammar [RFC4234] describes this XPath profile.
LocationPath = RelativeLocationPath / AbsoluteLocationPath
AbsoluteLocationPath = "/" RelativeLocationPath?
/ AbbreviatedAbsoluteLocationPath
RelativeLocationPath = Step / (RelativeLocationPath "/" Step)
/ AbbreviatedRelativeLocationPath
Step = NodeTest / AbbreviatedStep
NodeTest = ([AttributeSpecifier] NameTest)
/ (NodeType "()")
AbbreviatedAbsoluteLocationPath = "//" RelativeLocationPath
AbbreviatedRelativeLocationPath = RelativeLocationPath "//" Step
AbbreviatedStep = "." / ".."
AttributeSpecifier = "@"
NameTest = "*" / (NCName ":*") / QName
NodeType = %x74.65.78.74 / %x6E.6F.64.65
; case-sensitive: "text" / "node"
Definitions for "NCName" and "QName" can be found in [W3C.REC-xml-
20040204].
These restrictions reduce the complexity of a processor and mean that
a processor only needs to provide support for node-set results.
Since the included axes are all evaluated in document order and no
predicates are allowed, this profile also grants significant scope
Thomson Expires June 16, 2006 [Page 13]
Internet-Draft Expressing XML Support December 2005
for optimization.
5.2. Limitations
In order to use this simplified XPath profile, features MUST be able
to be described as a set of elements and attributes only.
This simplified XPath profile is limited in its capability to deal
with loosely structured documents. In terms of expressing the
context where a node is supported, this grammar only allows the
parents of a node to be indicated. For instance, indicating support
for an element that is dependent on the value of an attribute
requires the use of predicates.
Thomson Expires June 16, 2006 [Page 14]
Internet-Draft Expressing XML Support December 2005
6. Testing for Support
An application can test if a document that it generates conforms to a
particular EXS document by applying the following procedure:
1. Search for the context node-set. The initial node set consists
of the document root (the parent of the document element) only.
2. For each node in that node-set:
A. Find all "namespace" and "node" elements within the current
context.
B. Conditionally mark the nodes that match the each statement:
+ For the "namespace" element, this includes all nodes that
are in the current context and the specified namespace.
All direct descendants of these nodes that are either
attributes with the null namespace or text nodes are also
included.
+ For the "node" element, this includes all nodes in the
node-set specified. All descendants of those nodes are
also marked based on the value of the "descendants"
attribute.
C. If the support statement has "except" children, evaluate each
and remove any conditional marks from the node-set result.
Similar to the "node" element, descendants of excluded nodes
are also excluded based on the value of the "descendants"
attribute.
D. Mark all remaining conditionally marked nodes as supported.
E. Find all "context" element children of the current context
node.
F. Recurse: evaluate step 1. for each context child.
3. Mark all namespace prefix declarations and comments as supported.
4. If any nodes are not marked, the document is considered as not
supported and this procedure terminates.
5. The document is validated against the specified schema, taking
into account any schemas that are indicated. Only valid
documents are considered supported.
Thomson Expires June 16, 2006 [Page 15]
Internet-Draft Expressing XML Support December 2005
7. Expression of XML Support Schema
Thomson Expires June 16, 2006 [Page 16]
Internet-Draft Expressing XML Support December 2005
Thomson Expires June 16, 2006 [Page 17]
Internet-Draft Expressing XML Support December 2005
For formatting purposes, the EXS schema contains extra line-breaks in
the XPath pattern. These must be removed to use this schema - the
actual value does not contain spaces or newline characters.
Thomson Expires June 16, 2006 [Page 18]
Internet-Draft Expressing XML Support December 2005
8. Example
Thomson Expires June 16, 2006 [Page 19]
Internet-Draft Expressing XML Support December 2005
Thomson Expires June 16, 2006 [Page 20]
Internet-Draft Expressing XML Support December 2005
9. Security Considerations
In general, the purpose for which EXS documents are used will
determine what security constraints apply. This section provides
some guidance on the types of security considerations that SHOULD be
made when using this specification.
An expression of XML support document could reveal capability
information about a service. This information could be used for
competitive analysis, or as input to an attack that focusses on
unsupported values or border cases. Where the EXS document is widely
published, there are often many legitimate means for obtaining this
sort of information, so encryption of this information is not
especially important.
EXS documents can be used to indicate the service level offered to a
individual users of a service. This information is sensitive to that
user and therefore users SHOULD be authenticated and EXS documents
SHOULD be encrypted where information applies to individuals users.
If an EXS document is alterable, an attacker could use it to make
promises of support that cannot be satisfied. Conversely, a forged
EXS could be used to limit the features used by a user. Protocols
that provide message integrity SHOULD be used to prevent alterations.
Services that provide EXS documents out-of-band to protocols that use
the information SHOULD be authenticated by their clients.
Thomson Expires June 16, 2006 [Page 21]
Internet-Draft Expressing XML Support December 2005
10. IANA Considerations
10.1. MIME Type registration
This specification requests the registration of a new MIME type
according to the procedures of [RFC2048] and guidelines in [RFC3023].
MIME media type name: application
MIME subtype name: exs+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023[RFC3023].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 9 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
XXXX with the RFC number of this specification]].
Interoperability considerations: none.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this specification]]
Applications which use this media type: This document type is used
to express application support for XML features within documents.
This has general application for a range of applications.
Additional Information:
Magic Number: None
File Extension: .exs
Macintosh file type code: "TEXT"
Personal and email address for further information: Martin
Thomson, martin.thomson@andrew.com
Intended usage: COMMON
Author/Change controller: The IETF.
Thomson Expires June 16, 2006 [Page 22]
Internet-Draft Expressing XML Support December 2005
10.2. URN Sub-Namespace Registration
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:exs" as per the guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:exs
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
Expression of XML Support
Namespace for Expression of XML Support
urn:ietf:params:xml:ns:exs
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
END
10.3. XML Schema Registration
This section registers an XML schema as per the procedures in
[RFC3688].
URI: urn:ietf:params:xml:schema:exs
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
The XML for this schema can be found in Section 7 of this document
between lines starting with "",
inclusive.
Thomson Expires June 16, 2006 [Page 23]
Internet-Draft Expressing XML Support December 2005
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[W3C.REC-xpath-19991116]
DeRose, S. and J. Clark, "XML Path Language (XPath)
Version 1.0", W3C REC REC-xpath-19991116, November 1999.
[W3C.REC-xml-20040204]
Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC REC-xml-20040204, February 2004.
11.2. Informative References
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[I-D.ietf-geopriv-common-policy]
Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-06 (work in
progress), October 2005.
[W3C.REC-xmlschema-1-20041028]
Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", W3C
REC REC-xmlschema-1-20041028, October 2004.
Thomson Expires June 16, 2006 [Page 24]
Internet-Draft Expressing XML Support December 2005
Appendix A. Acknowledgements
The author would like to recognize the work of Jonathon Rosenberg for
his work in defining a document format for policy capabilities.
Security considerations are largely based on that work.
Thomson Expires June 16, 2006 [Page 25]
Internet-Draft Expressing XML Support December 2005
Author's Address
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
Thomson Expires June 16, 2006 [Page 26]
Internet-Draft Expressing XML Support December 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Thomson Expires June 16, 2006 [Page 27]