This is a little list I have started compiling of the MUST and MUST
NOTs of the SOAP spec. Some of you may find this interesting.
SOAP MUSTs and MUST NOTs
1. A SOAP application receiving a SOAP message MUST process that
message by performing the following actions in the order listed below
2. A SOAP application MUST be able to process SOAP namespaces in
messages that it receives. It MUST discard messages that have
incorrect namespaces (see section 4.4) and it MAY process SOAP
messages without SOAP namespaces as though they had the correct SOAP
3. A SOAP message MUST NOT contain a Document Type Declaration.
A SOAP message MUST NOT contain Processing Instructions. 
4. The element MUST be present in a SOAP message
5. The element MAY contain namespace declarations as well as
additional attributes. If present, such additional attributes MUST be
namespace-qualified. Similarly, the element MAY contain additional
sub elements. If present these elements MUST be namespace-qualified
and MUST follow the SOAP Body element.
6. The element MAY be present in a SOAP message. If present, the
element MUST be the first immediate child element of a SOAP Envelope
7. The element MAY contain a set of header entries each being an
immediate child element of the SOAP Header element. All immediate
child elements of the SOAP Header element MUST be namespace-qualified.
8. The element MUST be present in a SOAP message and MUST be an
immediate child element of a SOAP Envelope element. It MUST directly
follow the SOAP Header element if present. Otherwise it MUST be the
first immediate child element of the SOAP Envelope element.
9. SOAP does not define a traditional versioning model based on
major and minor version numbers. A SOAP message MUST have an Envelope
element associated with
namespace. If a
message is received by a SOAP application in which the SOAP Envelope
element is associated with a different namespace, the application
MUST treat this as a version error and discard the message. If the
message is received through a request/response protocol such as HTTP,
the application MUST respond with a SOAP VersionMismatch faultcode
message (see section 4.4) using the
Encoding rules for Headers
10. A header entry is identified by its fully qualified element
name, which consists of the namespace URI and the local name. All
immediate child elements of the SOAP Header element MUST be namespace-
Use of Header Attributes
11. The recipient of a SOAP message MUST ignore all SOAP Header
attributes that are not applied to an immediate child element of the
SOAP Header element.
12. That is, a recipient receiving a header element MUST NOT
forward that header element to the next application in the SOAP
13. This attribute MUST appear in the SOAP message instance in
order to be effective (see section 3 and 4.2.1).
14. If a header element is tagged with a SOAP mustUnderstand
attribute with a value of "1", the recipient of that header entry
either MUST obey the semantics (as conveyed by the fully qualified
name of the element) and process correctly to those semantics, or
MUST fail processing the message (see section 4.4).
15. The SOAP mustUnderstand attribute allows for robust
evolution. Elements tagged with the SOAP mustUnderstand attribute
with a value of "1" MUST be presumed to somehow modify the semantics
of their parent or peer elements. Tagging elements in this manner
assures that this change in semantics will not be silently (and,
presumably, erroneously) ignored by those who may not fully
16. This attribute MUST appear in the instance in order to be
effective (see section 3 and 4.2.1).
17. The Body element is encoded as an immediate child element of
the SOAP Envelope XML element. If a Header element is present then
the Body element MUST immediately follow the Header element,
otherwise it MUST be the first immediate child element of the
18. The SOAP Fault element is used to carry error and/or status
information within a SOAP message. If present, the SOAP Fault element
MUST appear as a body entry and MUST NOT appear more than once within
a Body element.
19. The faultcode element is intended for use by software to
provide an algorithmic mechanism for identifying the fault. The
faultcode MUST be present in a SOAP Fault element and the faultcode
value MUST be a qualified name as defined in , section 3. SOAP
defines a small set of SOAP fault codes covering basic SOAP faults
(see section 4.4.1)
20. The faultstring element is intended to provide a human
readable explanation of the fault and is not intended for algorithmic
processing. The faultstring element is similar to the 'Reason-Phrase'
defined by HTTP (see , section 6.1). It MUST be present in a SOAP
Fault element and SHOULD provide at least some information explaining
the nature of the fault.
21. The faultactor element is intended to provide information
about who caused the fault to happen within the message path (see
section 2). It is similar to the SOAP actor attribute (see section
4.2.2) but instead of indicating the destination of the header entry,
it indicates the source of the fault. The value of the faultactor
attribute is a URI identifying the source. Applications that do not
act as the ultimate destination of the SOAP message MUST include the
faultactor element in a SOAP Fault element. The ultimate destination
of a message MAY use the faultactor element to indicate explicitly
that it generated the fault (see also the detail element below).
22. The detail element is intended for carrying application
specific error information related to the Body element. It MUST be
present if the contents of the Body element could not be successfully
processed. It MUST NOT be used to carry information about error
information belonging to header entries. Detailed error information
belonging to header entries MUST be carried within header entries.
23. The faultcode values defined in this section MUST be used in
the faultcode element when describing faults defined by this
specification. The namespace identifier for these faultcode values
Use of this space is
recommended (but not required) in the specification of methods
defined outside of the present specification.
24. HTTP applications MUST use the media type "text/xml"
according to RFC 2376  when including SOAP entity bodies in HTTP
25. The SOAPAction HTTP request header field can be used to
indicate the intent of the SOAP HTTP request. The value is a URI
identifying the intent. SOAP places no restrictions on the format or
specificity of the URI or that it is resolvable. An HTTP client MUST
use this header field when issuing a SOAP HTTP Request.
26. In case of a SOAP error while processing the request, the
SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error"
response and include a SOAP message in the response containing a SOAP
Fault element (see section 4.4) indicating the SOAP processing error.