CARVIEW

MOTORHOMES

Select Language

HTTP/2 302 server: nginx date: Sat, 02 Aug 2025 20:54:47 GMT content-type: text/plain; charset=utf-8 content-length: 0 x-archive-redirect-reason: found capture at 20160317023218 location: https://web.archive.org/web/20160317023218/https://www.w3.org/TR/soap12-n11n/ server-timing: captures_list;dur=0.832902, exclusion.robots;dur=0.036560, exclusion.robots.policy;dur=0.022447, esindex;dur=0.014660, cdx.remote;dur=23.288296, LoadShardBlock;dur=327.570407, PetaboxLoader3.datanode;dur=138.083209, PetaboxLoader3.resolve;dur=165.131931 x-app-server: wwwb-app200 x-ts: 302 x-tr: 395 server-timing: TR;dur=0,Tw;dur=0,Tc;dur=1 set-cookie: wb-p-SERVER=wwwb-app200; path=/ x-location: All x-rl: 0 x-na: 0 x-page-cache: MISS server-timing: MISS x-nid: DigitalOcean referrer-policy: no-referrer-when-downgrade permissions-policy: interest-cohort=() HTTP/2 200 server: nginx date: Sat, 02 Aug 2025 20:54:48 GMT content-type: text/html; charset=utf-8 x-archive-orig-date: Thu, 17 Mar 2016 02:32:18 GMT x-archive-orig-last-modified: Mon, 06 Oct 2003 19:57:57 GMT x-archive-orig-etag: "4b50-3c90a21611b40" x-archive-orig-accept-ranges: bytes x-archive-orig-content-length: 19280 x-archive-orig-content-md5: WUP/M3pmJGajeS6fbPNVJA== x-archive-orig-cache-control: max-age=31536000 x-archive-orig-expires: Fri, 17 Mar 2017 02:32:18 GMT x-archive-orig-p3p: policyref="https://www.w3.org/2014/08/p3p.xml" x-archive-orig-vary: upgrade-insecure-requests x-archive-orig-access-control-allow-origin: * x-archive-orig-connection: close x-archive-guessed-content-type: text/html x-archive-guessed-charset: utf-8 memento-datetime: Thu, 17 Mar 2016 02:32:18 GMT link: ; rel="original", ; rel="timemap"; type="application/link-format", ; rel="timegate", ; rel="first memento"; datetime="Tue, 01 Apr 2003 15:38:41 GMT", ; rel="prev memento"; datetime="Sat, 05 Sep 2015 05:47:51 GMT", ; rel="memento"; datetime="Thu, 17 Mar 2016 02:32:18 GMT", ; rel="next memento"; datetime="Tue, 29 Mar 2016 23:09:26 GMT", ; rel="last memento"; datetime="Fri, 27 Jun 2025 01:52:57 GMT" content-security-policy: default-src 'self' 'unsafe-eval' 'unsafe-inline' data: blob: archive.org web.archive.org web-static.archive.org wayback-api.archive.org athena.archive.org analytics.archive.org pragma.archivelab.org wwwb-events.archive.org x-archive-src: WPO-20160317022556-crawl894/WPO-20160317022900-03108.warc.gz server-timing: captures_list;dur=0.501552, exclusion.robots;dur=0.021728, exclusion.robots.policy;dur=0.013385, esindex;dur=0.009438, cdx.remote;dur=7.282349, LoadShardBlock;dur=98.283754, PetaboxLoader3.datanode;dur=216.370607, load_resource;dur=264.666766, PetaboxLoader3.resolve;dur=97.268360 x-app-server: wwwb-app200 x-ts: 200 x-tr: 412 server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0 x-location: All x-rl: 0 x-na: 0 x-page-cache: MISS server-timing: MISS x-nid: DigitalOcean referrer-policy: no-referrer-when-downgrade permissions-policy: interest-cohort=() content-encoding: gzip SOAP Version 1.2 Message Normalization

SOAP Version 1.2 Message Normalization

W3C Working Group Note 8 October 2003

This version:: https://www.w3.org/TR/2003/NOTE-soap12-n11n-20031008/
Latest version:: https://www.w3.org/TR/soap12-n11n/
Previous version:: https://www.w3.org/TR/2003/NOTE-soap12-n11n-20030328/
Editors:: Martin Gudgin, Microsoft; Marc Hadley, Sun Microsystems

Abstract

SOAP 1.2 intermediaries have some license when reserializing messages that pass through them. This document defines a transformation algorithm that renders all semantically equivalent SOAP messages identically. The transformation may be used in conjunction with an XML canonicalization algorithm prior to the generation of a message digest in producing XML digital signatures that are sufficiently robust to survive passage through one or more SOAP intermediaries.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document is the work of the W3C XML Protocol Working Group, and no more work from this Working Group is currently expected on this document.

The XML Protocol Working Group is part of the Web Services Activity.

Comments on this document should be sent to the publicly archived mailing list xml-dist-app@w3.org

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

1. Introduction
    1.1 Notational Conventions
2. The Need for SOAP Message Normalization
    2.1 A Simple Example
3. Specification of SOAP Message Normalization
4. Use in XML Security
5. References
    5.1 Normative References
    5.2 Informative References

Appendices

A. XSLT Implementation (Non-Normative)
B. Acknowledgements (Non-Normative)

1. Introduction

SOAP 1.2 [SOAP Part1] intermediaries have some license when reserializing messages that pass through them. Current XML canonicalizations (see [XML C14N] and [EXCL C14N]) do not take into account the transforms that a SOAP intermediary can legally apply to messages passing through it. This document defines a transformation that renders all semantically equivalent SOAP messages identically. This transformation may be used in conjunction with an XML canonicalization algorithm prior to the generation of a message digest in producing XML digital signatures that are sufficiently robust to survive passage through one or more SOAP intermediaries.

1.1 Notational Conventions

The keywords "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].

This note uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [XML InfoSet]).

Table 1: Prefixes and Namespaces used in this specification.
Prefix	Namespace	Notes
env	"https://www.w3.org/2003/05/soap-envelope"	A normative XML Schema [XML Schema Part1], [XML Schema Part2] document for the "https://www.w3.org/2003/05/soap-envelope" namespace can be found at https://www.w3.org/2003/05/soap-envelope.

Namespace names of the general form "https://example.org/..." and "https://example.com/..." represent application or context-dependent URIs (see [RFC 2396]).

All parts of this note are normative, with the exception of examples and sections explicitly marked as "Non-Normative".

2. The Need for SOAP Message Normalization

2.1 A Simple Example

As a simple example of the kind of problem a SOAP intermediary can cause for an XML signature, consider the following SOAP message:

Example 1: SOAP message containing a SOAP header block and a SOAP body

<env:Envelope xmlns:env="https://www.w3.org/2003/05/soap-envelope">
 <env:Header>
  <n:alertcontrol env:mustUnderstand="false"
   xmlns:n="https://example.org/alertcontrol">
   <n:priority>1</n:priority>
   <n:expires>2001-06-22T14:00:00-05:00</n:expires>
  </n:alertcontrol>
 </env:Header>
 <env:Body>
  <m:alert xmlns:m="https://example.org/alert">
   <m:msg>Pick up Mary at school at 2pm</m:msg>
  </m:alert>
 </env:Body>
</env:Envelope>

A SOAP intermediary is at liberty to remove the env:mustUnderstand attribute from SOAP header blocks when its value is "false" or "0". If the message included a signature of the header block generated using XML Canonicalization [XML C14N] or Exclusive XML Canonicalization [EXCL C14N] then that signature would be invalidated if the intermediary removed the mustUnderstand attribute. There is therefore a requirement for a transformation that takes into account the variations that a SOAP intermediary can introduce. SOAP Message Normalization fulfils this requirement.

3. Specification of SOAP Message Normalization

SOAP Message Normalization is specified as an XML infoset transformation and consists of the following steps:

A SOAP Header element information item that has no child element information items is removed.
If a SOAP Header element information item is present then for each child element information item of the SOAP Header element information item:
- If the SOAP mustUnderstand attribute information item is present with a value of "0" or "false" then remove the mustUnderstand attribute information item.
- If the SOAP mustUnderstand attribute information item is present with a value of "1" then change its value to "true".
- If the SOAP role attribute information item is present with a value of "https://www.w3.org/2003/05/soap-envelope/role/ ultimateReceiver" or "" then remove the role attribute information item.
- If the SOAP relay attribute information item is present with a value of "0" or "false" then remove the relay attribute information item.
- If the SOAP relay attribute information item is present with a value of "1" then change its value to "true".
Processing instruction information items that are children of the SOAP Envelope , Header , Fault , Code , Subcode , Value , Reason , Text , Node and Role element information items are removed.
Whitespace character information items that are children of the SOAP Envelope , Header , Fault , Code , Subcode , Value , Reason , Node and Role element information items are removed.

4. Use in XML Security

SOAP Message Normalization may be used as a Transform algorithm in XML Digital Signature [XML DSig]. Use of a separate CanonicalizationMethod such as XML Canonicalization [XML C14N] or Exclusive XML Canonicalization [EXCL C14N] is required. SOAP Message Normalization is identified with the following URI:

"https://www.w3.org/2003/10/soap12-n11n"

5. References

5.1 Normative References

[SOAP Part1]: W3C Recommendation "SOAP Version 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003. (See https://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)
[RFC 2119]: IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See https://www.ietf.org/rfc/rfc2119.txt.)
[RFC 2396]: IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See https://www.ietf.org/rfc/rfc2396.txt.)
[XML Schema Part1]: W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See https://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.)
[XML Schema Part2]: W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See https://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)
[Namespaces in XML]: W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See https://www.w3.org/TR/1999/REC-xml-names-19990114/.)
[XML 1.0]: W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See https://www.w3.org/TR/2000/REC-xml-20001006.)
[XML InfoSet]: W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See https://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)
[XML C14N]: W3C Recommendation "Canonical XML", John Boyer, 15 March 2001. (See https://www.w3.org/TR/xml-c14n.)
[EXCL C14N]: W3C Recommendation "Exclusive Canonical XML", John Boyer, Donald Eastlake, Joseph Reagle, 18 July 2001. (See https://www.w3.org/TR/xml-exc-c14n/.)
[XML DSig]: IETF Draft Standard/W3C Recommendation "XML-Signature Syntax and Processing", D. Eastlake, J. Reagle, and D. Solo, August 2001. (See https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.)
[XML Enc]: W3C Recommendation "XML Encryption Syntax and Processing", Takeshi Imamura, Blair Dillaway, Ed Simon, December 2002. (See https://www.w3.org/TR/xmlenc-core/.)

5.2 Informative References

[SOAP 1.1]: W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (See https://www.w3.org/TR/SOAP/.)

A. XSLT Implementation (Non-Normative)

A future version of this document might usefully contain an implementation of SOAP Message Normalization in the form of an XSLT stylesheet.

B. Acknowledgements (Non-Normative)

This document is the work of the W3C XML Protocol Working Group.

The authors would like to thank Rich Salz for initiating this work. The authors would like to thank Rich Salz and Joseph Reagle for reviewing this document during production

Original Source | Taken Source