New issue: Default values of SOAP header block attributes

Last week I took an action item to describe the issue of dealing with
default values for the SOAP envelope attributes "mustUnderstand" and
"actor/role". This mail contains first a discussion of the issue and
then proposes a resolution to be considered.

Discussion
----------

Section 4 defines the semantics of omitting both the actor/role
attribute and the mustUnderstand attribute:

1) Section 4.2.2 says: "Omitting the SOAP actor attribute information
item implicitly targets the SOAP header block at the ultimate SOAP
receiver. An empty value for this attribute is equivalent to omitting
the attribute completely, i.e. targeting the block at the ultimate SOAP
recipient."

2) Section 4.2.3 says: "Omitting this attribute information item is
defined as being semantically equivalent to including it with a value of
"false"."

However, neither of the statements above provides any guidance as
whether the attributes should lexically appear in the SOAP message when
they have their default values. Later in the section, we find the
following statement:

3) Section 4.2.1 says: "SOAP header block attribute information items
MUST appear in the SOAP message itself in order to be effective; default
values which may be specified in an XML Schema or other description
language do not affect SOAP processing (see 3.1 XML Schema)."

While it might seem that these statements are contradictory, the
intention of the 3) is not to disallow omitting the SOAP header block
attributes but to state that SOAP modules can not default their values.
For example, a SOAP security module can not set the default mU value to
true in the schema definition for the header blocks that it defines.
Currently, the vast majority (if not all?) of existing SOAP
implementations do not generate SOAP header block attributes with their
default values.

In addition,

4) Section 3.1 says: "A SOAP message MUST NOT impose any XML schema
processing (assessment and validation) requirement on the part of any
receiving SOAP node. Therefore, SOAP REQUIRES that all attribute
information items, whether specified in this specification or whether
they belong to a foreign namespace be caried in the serialized SOAP
envelope."

Section 3.1 seems to go too far in the requirement of not requiring
schema processing. The only piece that we can possible talk about is
that schema processing MUST NOT be required in order to correctly
process a SOAP message according to the SOAP processing model in section
2. I don't think we have anything to say about whether
application-defined data relies on schema processing or not.

Proposal Outline
----------------

Whenever we have a choice in what can be generated by a sender and what
must be accepted by a receiver, it seems useful to invoke the general
Robustness Principle "Be liberal in what you accept, and conservative in
what you send" [2][3].

The proposal consists of three main parts and a minor part:

A) Clarify the paragraph in section 4.2.1 to remove the apparent
contradiction.

B) Add a sentence to the two paragraphs mentioned the semantics of
omitted SOAP header block attributes that indicated the guidelines for
handling default attribute values. 

C) Clarify section 3.1 to say that it only applies to SOAP processing as
defined by section 2.

D) In addition, I would suggest that we add a paragraph in the
introduction of part 1 (for example as part of section 3 explicitly
calling out the Robustness Principle as a general principle for SOAP
processors.

Specific Text Modifications
---------------------------

A. Modified section 4.2.1 paragraph (clarification):

SOAP header block attribute information items whose value differs from
their default value as defined in section 4.2.2 and 4.2.3 MUST appear in
the SOAP message itself in order to be effective; any other value that
does not appear directly in the SOAP message MUST NOT affect the SOAP
processing as defined by section 2.

B.1 Modified section 4.2.2 (added paragraph):

Omitting the SOAP actor attribute information item implicitly targets
the SOAP header block at the ultimate SOAP receiver. An empty value for
this attribute is equivalent to omitting the attribute completely, i.e.
targeting the block at the ultimate SOAP recipient.

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the
SOAP actor attribute information item for SOAP header blocks targeted at
the ultimate SOAP receiver (see section 3.2 Robustness Principle).

B.2 Modified section 4.2.3 (added paragraph):

Omitting this attribute information item is defined as being
semantically equivalent to including it with a value of "false" or "0".

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the
SOAP mustUnderstand attribute information item with a value of "false"
or "0" (see section 3.2 Robustness Principle).

C. Modified section 3.1 (clarification):

A SOAP message MUST NOT impose any XML schema processing (assessment and
validation) requirement on the part of any receiving SOAP node in order
to correctly process a SOAP message according to the processing rules
defined in section 2. Unless explicitly stated otherwise, SOAP REQUIRES
that all information items that affect the SOAP processing model,
whether specified in this specification or whether they belong to a
foreign namespace be carried in the serialized SOAP envelope.

D. Added subsection 3.2 about Robustness Principle

3.2 Robustness Principle

The use of XML as the fundamental description framework leaves in many
cases a great deal of flexibility for expressing semantically equivalent
statements in a variety of different ways. In order to obtain robust and
interoperable implementations it is essential that SOAP implementations
take into account the Robustness Principle as expressed by [2][3]: "Be
liberal in what you accept, and conservative in what you send".

Throughout this specification, guidelines will be provided as to what
constitutes "conservative". However, it is important that implementers
realize that this often represents only a subset of the set of
acceptable values.

Comments?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#N60D
[2] http://rfc.net/rfc1123.html
[3] http://rfc.net/rfc793.html

Received on Sunday, 10 February 2002 18:22:01 UTC