draft-ietf-xmldsig-requirements-00.txt   draft-ietf-xmldsig-requirements-01.txt 
XML Digital Signatures Working Group J. Reagle, XML Digital Signatures Working Group J. Reagle,
INTERNET-DRAFT W3C/MIT INTERNET-DRAFT W3C/MIT
draft-ietf-xmldsig-requirements-00.txt draft-ietf-xmldsig-requirements-01.txt
Expires December 23, 1999 Expires March 20, 1999
XML-Signature Requirements XML-Signature Requirements
Copyright Notice Copyright Notice
Copyright (c) 1999 The Internet Society & W3C (MIT, INRIA, Keio), All Copyright (c) 1999 The Internet Society & W3C (MIT, INRIA, Keio), All
Rights Reserved. Rights Reserved.
IETF Status of this Memo IETF Status of this Memo
This document is a production of the joint IETF/W3C XML Signature
Working Group.
http://www.w3.org/Signature
The latest version of this draft series may be found at:
http://www.w3.org/TR/1999/xml-dsig-requirements
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 document is a production of the joint IETF/W3C XML Signature W3C Status of this document
Working Group.
http://www.w3.org/Signature
The latest version of this draft series may be found at:
http://www.w3.org/TR/1999/xmldsig-requirements
XML-Signature Requirements
W3C Working Draft 1999-June-23
This version:
http://www.w3.org/TR/1999/xmldsig-requirements-990623 {ASCII}
http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-requirem
ents-00.txt
Latest version:
http://www.w3.org/TR/1999/xmldsig-requirements
Previous version:
http://www.w3.org/Signatures/Drafts/xml-dsig-requirements-99060
1
Editor(s):
Joseph Reagle Jr. <reagle@w3.org>
Copyright 1999 The Internet Society & W3C (MIT, INRIA, Keio), All
Rights Reserved. W3C liability, trademark, document use and software
licensing rules apply.
W3C Status of this Document
This is the first Public Working Draft of the IETF/W3C XML-Digital This is a Last Call XML Signature Requirements public Working Draft.
Signature Working Group Requirements document. Its content is based This report is not expected to be advanced to Recommendation. Instead,
on the Charter [Charter], XML-Signature Workshop [WS], Brown's IETF this Last Call designation is (1) a representation of WG consensus,
draft [Brown] and mailing list discussion. This draft will be (2) an invitation for comments that will affect the future course of
published prior to the June 25 IETF deadline for consideration at the the technical specification, and (3) an opportunity to identify and
IETF in Oslo as an IETF-draft and W3C Working Draft. The first draft obtain commitments regarding WG dependencies. This document will be
of a Working Group consensus version should be produced by July. referred to at least the W3C XML Plenary Interest Group and W3C Chairs
Working Group. Last Call period ends when dependencies between WGs
have been acknowledged and the Signature Chairs have procured
commitments of review. This is expected to take six weeks from the
date of publication.
This document does not necessarily represent the working group's This document attempts to capture the Working Group's consensus though
consensus on a finished document; it also includes contrary positions it contains points which are still uncertain or not well
(or alternative wordings) in order to elicit review and discussion. specified. Issues which are still being actively discussed during the
Positions which are potentially in conflict are specified as a list of publication of this document are of class="discuss" and rendered in
lettered points. For example: navy by style sheet compliant applications.
1 Extensibility
a. Position
b. Alternative/Contrary Position
Please send comments to the editor <reagle@w3.org> and cc: the list Please send comments to the editor <reagle@w3.org> and cc: the list
<w3c-ietf-xmldsig@w3.org>. Publication as a Working Draft does not <w3c-ietf-xmldsig@w3.org>. Publication as a Working Draft does not
imply endorsement by the W3C membership. This is a draft document and imply endorsement by the W3C membership. This is a draft document and
may be updated, replaced or obsoleted by other documents at any time. may be updated, replaced or obsoleted by other documents at any time.
It is inappropriate to cite W3C Drafts as other than "work in It is inappropriate to cite W3C Drafts as other than "work in
progress".A list of current W3C working drafts can be found at progress".A list of current W3C working drafts can be found at
http://www.w3.org/TR. Publication as a Working Draft does not imply http://www.w3.org/TR
endorsement by the W3C membership.
Abstract Abstract
This document lists the design principles, scope, and requirements for This document lists the design principles, scope, and requirements for
the XML Digital Signature specification. It includes requirements as the XML Digital Signature specification. It includes requirements as
they relate to the signature syntax, data model, format, cryptographic they relate to the signature syntax, data model, format, cryptographic
porcessing, and external requirements and coordination. processing, and external requirements and coordination.
Table of Contents Table of Contents
1 Introduction 1. 1. Introduction
2 Design Principles and Scope 2. 2. Design Principles and Scope
3 Requirements 3. 3. Requirements
1 Signature Data Model and Syntax 3.1 1. Signature Data Model and Syntax
2 Format 3.2 2. Format
3 Cryptography 3.3 3. Cryptography and Processing
4 Processing 3.4 4. Coordination
5 Coordination 4. 4. References
4 References
_________________________________________________________________
1 Introduction 1 1. Introduction
The XML 1.0 Recommendation [XML] describes the syntax of a class of The XML 1.0 Recommendation [XML] describes the syntax of a class of
data objects called XML documents. The mission of this working group data objects called XML documents. The mission of this working group
is to develop an XML compliant syntax used for representing signatures is to develop a XML syntax used for representing signatures on digital
on Web resources and portions of protocol messages (anything that can content and procedures for computing and verifying such signatures.
be referenced by a URI) and procedures for computing and verifying Signatures will provide data integrity, authentication, and/or
such signatures. Signatures will provide data integrity, non-repudiatability.
authentication, and/or non-repudiatability
2 Design Principles and Scope This document lists the design principles, scope, and requirements
over three things: (1) the scope of work available to the WG, (2) the
XML signature specification, and (3) applications that implement the
specification. It includes requirements as they relate to the
signature syntax, data model, format, cryptographic processing, and
external requirements and coordination. Those things that are required
are designated as "must," those things that are optional are
designated by "may," those things that are optional but recommended
are designated as "should."
1 The XML-Signature specification will describe how to a digitally 2 2. Design Principles and Scope
sign a Web resource in general, and an XML document in particular.
[Charter] The specification will not specify methods of providing 1. The specification must describe how to a sign digital content, and
confidentiality though the Working Group may report on the XML content in particular. [Charter]
feasibility of such work in a future or rechartered activity. 2. XML-signatures are generated from a hash over the canonical form
[List(Bugbee)] of a signature manifest. The manifest must support references to
2 The meaning of the signature is very simple: The XML signature Web resources, the hash of the resource content (or its
syntax associates the cryptographic signature value with Web canonicalized form), and (optionally) the resource content type.
resources using XML markup. [Brown, List(Solo)] Web resources are defined as any digital
1 The WG is not chartered to specify trust semantics, but content content that can be addressed using the syntax of XLink
locator [XLink]).
Comment: Scenarios are being explored which examine the ability to
sign without requiring a manifest whereas the scope of the signed
content is designated by the relative placement of signature
elements in the XML stream/tree. For instance:
<html> .....</body><dsig xmlns="http://..." referent=""><html>.
or
<html><title>pricelist</title>...<dsig xmlns="http://..."> ...
</dsig></html>
3. The meaning of a signature is simple: The XML-signature syntax
associates the content of resources listed in a manifest with a
key via a strong one-way transformation.
1. The XML-signature syntax must be extensible such that it can
support arbitrary application/trust semantics and assertion
capabilities -- that can also be signed.
[Charter(Requirement1&4), List(Bugbee, Solo)]
2. The WG is not chartered to specify trust semantics, but
syntax and processing rules necessary for communicating syntax and processing rules necessary for communicating
signature validity (authenticity, integrity and signature validity (authenticity, integrity and
non-repudiation). [Charter(Requirement1)] non-repudiation). [Charter(Requirement1)] At the Chairs'
2 The XML signature syntax must be highly extensible such that discretion and in order to test the extensibility of the
it can support arbitrary application/trust semantics and syntax, the WG may produce non-standard-track proposals
assertion capabilities -- that can also be signed. For defining common semantics (e.g., package, timestamps,
example, potential trust applications include sophisticated endorsement, etc.) relevant to signed assertions about Web
timestamps, endorsement, and threshold signature schemes. At resources in a schema definition [XML, RDF] or link type
the Chairs' discretion and in order to test the extensibility definition [XLink].
the syntax, the WG may produce non-standard-track proposals Comment: A more formal definition of a signed resource is the
defining common semantics relevant to signed assertions about following evaluates as true "definition(inputs):constraints" where
Web resources and their relationships in a schema definition R is a resource., I is a resource identifier (URI), and C is
(XML/RDF) or link type definition (XLink). content (sequence-of-octects).
[Charter(Requirement1&4), List(Bugbee, Solo)] signed-resource(I, C, key, sig): there was some request R such
3 Validity and Identity that GET(R) = C and address(R) = I and sign-doc(C, key, sig)
A. Only enough information necessary to check the validity sign-doc(C, key, sig): sig is the value of a strong one-way
of the cryptographic signature need be provided. function over content and key that yields C integrity/validity and
[Reagle] K non-repudiability
B. Each signature shall be associated with information to 4. The specification must not specify methods of confidentiality
identify the signer and/or the cryptographic information though the Working Group may report on the feasibility of such
required to validate the signature. [List(Solo)] work in a future or rechartered activity. [List(Bugbee)]
3 An XML-Signature can apply to a part or totality of an XML 5. The specification must only require the provision of key
document. [Charter, Brown] information essential to checking the validity of the
4 More than one signature may exist over any resource.[Charter, cryptographic signature. For instance, identity and key recovery
Brown] information might be of interest to particular applications, but
5 A key use of XML Signatures will be detached Web signatures. In they are not within the class of required information defined in
conjunction with XML facilities (including packaging) signatures this specification. [List(Reagle)]
may be embedded within or encapsulate XML or encoded content. 6. The specification must define or reference at least one method of
canonicalizing and hashing the signature syntax (i.e., the
manifest and signature blocks). [Oslo] The specification must not
specify methods of canonicalizing resource content [Charter],
though it may specify security requirements over such methods.
[Oslo] Such content is normalized by specifying an appropriate
content C14N (canonicalization) algorithm [DOMHASH, XML-C14N].
Applications are expected to normalize application specific
semantics prior to handing data to a XML-signature application.
[Charter] [Charter]
6 The Signature syntax specification will not specify methods of 7. XML-signature applications must be conformant with the
serialization or canonicalization. XML content is normalized by specifications as follows:
specifying an appropriate content C14N (canonicalization) 1. XML-namespaces [XML-namespaces] within its own signature
algorithm [DOMHASH, C14N]; applications are expected to normalize syntax. Applications may choose C14N algorithms which do or
application specific semantics prior to handing data to a do not process namespaces within XML content. For instance,
XML-Signature application. [Charter] some C14N algorithms may opt remove all namespace
7 An XML-Signature application must be able to use and understand declarations, others may rewrite namespace declarations to
1 XML-namespaces [XML-namespaces] within its own signature provide for context independent declarations within every
syntax. Applications may optionally choose C14N algorithms element.
which do or do not process namespaces within XML content. 2. XLink [Xlink] within its own signature syntax. Applications
2 XLink [Xlink]. Applications will use XLink locators within must use XLink locators within the signature manifest to
the signature manifest to reference signed resources. reference resources. Signature applications must not embed or
Signature applications will not embed or expand XLink expand XLink references in signed content, though
references in the signed content, though applications may applications may choose C14N algorithms which provide this
optionally choose C14N algorithms which provide this feature. feature.
3 XML-Pointers [XPointer]. Applications will reference/select 3. XML-Pointers [XPointer] within its own signature syntax. If
parts of XML documents using XML-Pointer within an XLink applications reference/select parts of XML documents, they
locator. [Reagle, WS-list(1)] must use XML-Pointer within an XLink locator. [WS-list(1)]
8 Implementation/Design Philosophy The WG may specify security requirements that constrain the
A. XML Signatures will be developed as part of the broader Web operation of these dependencies to ensure consistent and secure
design philosophy of decentralization, URIs, Web data signature generation and operation. [Oslo]
[WebData], modularity/layering/extensibility, and assertions 8. XML-signatures must be developed as part of the broader Web design
as statements about statements. [Reagle] philosophy of decentralization, URIs, Web data,
B. The ability to leverage existing cryptographic provider (and modularity/layering/extensibility, and assertions as statements
infrastructure) primitives is desirable. [List(Solo)] about statements. [Berners-Lee, WebData] In this context, existing
cryptographic provider (and infrastructure) primitives should be
taken advantage of. [List(Solo)]
3 Requirements 3 3. Requirements
Signature Data Model and Syntax 3.1 1. Signature Data Model and Syntax
1 The XML-Signature data structures will be predicated on an RDF 1. XML-signature data structures must be based on the RDF data model
data model [RDF] but need not use the RDF serialization syntax. [RDF] but need not use the RDF serialization syntax. [Charter]
[Charter] 2. XML-signatures apply to any resource addressable by a locator --
2 XML-Signatures can be applied to any Web resource -- including including non-XML content. XML-signature referents are identified
non-XML content. XML-Signature referents are identified with XML with XML locators (URIs or fragments) within the manifest that
locators (URIs or fragments) within the manifest that refer to refer to external or internal resources (i.e., network accessible
external or internal resources (i.e., network accessible or within or within the same XML document/package). [Berners-Lee, Brown,
the same XML document/package). [Berners-Lee, Reagle, Brown, List(Vincent), WS, XFDL]
List(Vincent)] 3. XML-signatures must be able to apply to a part or totality of a
1 Entries may include explicit content type information. XML document. [Charter, Brown]
[List(Solo)] Comment: A related requirement under consideration is requiring
3 XML-Signatures are first class objects themselves and consequently the specification to support the ability to indicate those
can be referenced and signed. [Berners-Lee, Reagle] portions of a document one signs via exclusion of those portions
4 Algorithm Identification one does not wish to sign. This feature allows one to create
A. Whenever possible, any resource or algorithm identifier is a signatures that have document closure, retain ancestor
first class object, and addressable by a URI. [Beners-Lee, information, and retain element order of non-continuous regions
Reagle] that must be signed. We are considering implementing this
B. Ability to specify algorithms independently and to reference requirement via (1) a special <dsig:exclude> element, (2) an
the algorithms linked to standard algorithm specifications exclude list accompanying the resource locator, or (3) a request
(e.g. OIDs) [List(Solo)] to change the XML-Fragment or XPointer specifications to yield
5 XML-Signatures must be able to apply to the original version of an this functionality. See List(Boyer(1,2)) for further discussion of
this issue.
4. Multiple XML-signatures must be able to exist over the static
content of a Web resource given varied keys, content
transormations, and algorithm specifications (signature, hash,
canonicalization, etc.). [Charter, Brown]
5. XML-signatures are first class objects themselves and consequently
must be able to be referenced and signed. [Berners-Lee]
6. The specification must permit the use of varied digital signature
and message authentication codes, such as symmetric and asymmetric
authentication schemes as well as dynamic agreement of keying
material. [Brown] Resource or algorithm identifier are a first
class objects, and must be addressable by a URI. [Beners-Lee]
7. XML-signatures must be able to apply to the original version of an
included/encoded resource. [WS-list (Brown/Himes)] included/encoded resource. [WS-list (Brown/Himes)]
Format 3.2 2. Format
1 An XML-Signature is XML. [Charter] 1. An XML-signature must be an XML element (as defined by production
2 An XML document of a certain type must still be recognizable as 39 of the XML1.0 specification. [XML])
its original type when signed. [WS-summary] 2. An XML document of a certain type must still be recognizable as
3 XML-Signature will provide a mechanism that facilitates the its original type when signed. For example, an XML form, when
signed, should still be recognizable as a XML form to its
application after it has been signed. [WS-summary]
3. XML-signature must provide a mechanism that facilitates the
production of composite documents -- by addition or deletion -- production of composite documents -- by addition or deletion --
while preserving the signature characteristics (integrity, while preserving the signature characteristics (integrity,
authentication, and non-repudiatability) of the consituent parts. authentication, and non-repudiatability) of the consituent parts.
[Charter, Brown, List(Bugbee)] [Charter, Brown, List(Bugbee)]
4 ?Packaging? 4. A key use of XML-signatures will be detached Web signatures.
However, signatures may be embedded within or encapsulate XML or
Cryptography encoded content. [Charter] This WG must specify a simple method of
packaging and encapsulation if no W3C Recommendation is available.
1 The solution shall provide indifferently for digital signature and
message authentication codes, considering symmetric and asymmetric
authentication schemes as well as dynamic negotiation of keying
material. [Brown]
Processing 3.3 3. Cryptography and Processing
1 In the event of redundant attributes within the XML Signature 1. The specification must permit arbitrary cryptographic signature
and message authentication algorithms, symmetric and asymmetric
authentication schemes, and key agreement methods. [Brown]
2. The specification must specify at least one mandatory to implement
signature canonicalization, content canonicalization, hash, and
signature algorithm.
3. In the event of redundant attributes within the XML Signature
syntax and relevant cryptographic blobs, XML Signature syntax and relevant cryptographic blobs, XML Signature
applications prefer the XML Signature semantics. [Reagle] applications prefer the XML Signature semantics.
Comment: Another possibility is that an error should be generated,
however it isn't where a conflict will be flagged between the
various function and application layers regardless.
Coordination 3.4 4. Coordination
The XML Signature specification should meet the requirements of the 1. The XML Signature specification should meet the requirements of
following applications: the following applications:
1 Internet Open Trading Protocol v2.0 [Charter] 1. Internet Open Trading Protocol v1.0 [IOTP]
2 Financial Services Mark Up Language v2.0 [Charter] 2. Financial Services Mark Up Language v2.0 [Charter]
To ensure the above requirements are adequately addressed, the XML 3. At least one forms application [XFA, XFDL]
Signature specification must be reviewed by a designated member of the 2. To ensure that all requirements within this document are
following communities: adequately addressed, the XML Signature specification must be
1 XML Syntax Working Group [Charter] reviewed by a designated member of the following communities:
2 XML Linking Working Group [Charter] 1. XML Syntax Working Group: canonicalization dependencies.
3 XML Schema Working Group [Charter] [Charter]
4 Metadata Coordination Group [Charter] 2. XML Linking Working Group: signature referants. [Charter]
5 ?W3C Internationalization Interest Group? 3. XML Schema Working Group: signature schema design. [Charter]
4. Metadata Coordination Group: data model design. [Charter]
5. W3C Internationalization Interest Group: [AC Review]
6. XML Package Working Group: signed content in/over packages.
7. XML Fragment Working Group: signing portions of XML content.
Comment: Members of the WG are very interested in signing and
processing XML fragments and packaged components. Boyer asserts
that [XML-fragment] does not "identify non-contiguous portions of
a document in such a way that the relative positions of the
connected components is preserved." Packaging is a capability
critical to XML-Signature applications, but it is clearly
dependent on clear trust/semantic definitions, package application
requirements, and even cache-like application requirements. It is
not clear how this work will be addressed.
4 References 4 4. References
AC Review
Misha Wolf. "The Charter should include the I18N WG in the
section on 'Coordination with Other Groups.'"
http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007.
html
Berners-Lee Berners-Lee
Axioms of Web Architecture: URIs. Axioms of Web Architecture: URIs.
http://www.w3.org/DesignIssues/Axioms.html http://www.w3.org/DesignIssues/Axioms.html
Web Architecture from 50,000 feet
http://www.w3.org/DesignIssues/Architecture.html
Brown-XML-DSig Brown-XML-DSig
Internet Draft. Digital Signatures for XML Internet Draft. Digital Signatures for XML
http://search.ietf.org/internet-drafts/draft-brown-xml-dsig-00. http://search.ietf.org/internet-drafts/draft-ietf-xmldsig-signa
txt ture-00.txt
C14N
XML Canonicalization Requirements.
http://www.w3.org/TR/NOTE-xml-canonical-req
Charter Charter
XML-DSig Charter. XML Signature (xmldsig) Charter.
http://www.w3.org/1999/05/XML-DSig-charter-990521.html http://www.w3.org/1999/05/XML-DSig-charter-990521.html
DOMHASH DOMHASH
Internet Draft. Digest Values for DOM (DOMHASH) Internet Draft. Digest Values for DOM (DOMHASH)
http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-0 http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-0
1txt 1.txt
FSML
FSML 1.5 Reference Specification
http://www.echeck.org/library/ref/fsml-v1500a.pdf
Infoset-Req Infoset-Req
XML Information Set Requirements Note. XML Information Set Requirements Note.
http://www.w3.org/TR/NOTE-xml-infoset-req http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html
IOTP
Internet Open Trading Protocol v1.0
draft-ietf-trade-iotp-v1.0-protocol-04.txt
IOTP-DSig IOTP-DSig
Internet Draft. Digital Signatures for the Internet Open Internet Draft. Digital Signatures for the Internet Open
Trading Protocol Trading Protocol
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0- http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-
dsig-00.txt dsig-00.txt
Namespaces Oslo
Namespaces in XML Recommendation. Minutes of the XML Signature WG Sessions at IETF face-to-face
http://www.w3.org/TR/REC-xml-names meeting in Oslo.
Signature List RDF
RDF Schema
http://www.w3.org/TR/1999/PR-rdf-schema-19990303
RDF Model and Syntax
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Signature WG List
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/ http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/
URI
Uniform Resource Identifiers (URI): Generic Syntax
http://www.ietf.org/rfc/rfc2396.txt
WS (list, summary) WS (list, summary)
XML-DSig '99: The W3C Signed XML Workshop XML-DSig '99: The W3C Signed XML Workshop
http://www.w3.org/DSig/signed-XML99/ http://www.w3.org/DSig/signed-XML99/
http://www.w3.org/DSig/signed-XML99/summary.html http://www.w3.org/DSig/signed-XML99/summary.html
XLink XLink
XML Linking Language XML Linking Language
http://www.w3.org/TR/WD-xlink http://www.w3.org/1999/07/WD-xlink-19990726
XML XML
Extensible Markup Language (XML) Recommendation. Extensible Markup Language (XML) Recommendation.
http://www.w3.org/TR/REC-xml http://www.w3.org/TR/1998/REC-xml-19980210
XML-C14N
XML Canonicalization Requirements.
http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605
XFA
XML Forms Architecture (XFA)
http://www.w3.org/Submission/1999/05/
XFDL
Extensible Forms Description Language (XFDL) 4.0
http://www.w3.org/Submission/1998/16/
XML-Fragment
XML-Fragment Interchange
http://www.w3.org/1999/06/WD-xml-fragment-19990630.html
XML-namespaces XML-namespaces
Namespaces in XML Namespaces in XML
http://www.w3.org/TR/REC-xml-names/ http://www.w3.org/TR/1999/REC-xml-names-19990114
XML-schema
XML Schema Part 1: Structures
http://www.w3.org/1999/05/06-xmlschema-1/
XML Schema Part 2: Datatypes
http://www.w3.org/1999/05/06-xmlschema-2/
XPointer XPointer
XML Pointer Language (XPointer) XML Pointer Language (XPointer)
http://www.w3.org/TR/WD-xptr http://www.w3.org/1999/07/WD-xptr-19990709
WebData WebData
Web Architecture: Describing and Exchanging Data. Web Architecture: Describing and Exchanging Data.
http://www.w3.org/1999/04/WebData http://www.w3.org/1999/04/WebData
 End of changes. 39 change blocks. 
202 lines changed or deleted 288 lines changed or added

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