← Prev in month ← Prev in thread

ISSUE 70 Part 1: S:mustUnderstand, what part of mustUnderstand don't we understand

From
Eric Gravengaard <>
Date
2003-05-20T17:52:50+00:00
ID
Thread
ISSUE 70 Part 1: S:mustUnderstand, what part of mustUnderstand don't we understand
Per our discussion 
on the call today I am again raising this issue for discussion on the list. What 
I originally wanted clarified was the processing that was required to 
definitively know if my implementation was capable of understanding a 
<Security> element that was tagged mustUnderstand. This is important since 
wsse has an open schema that allows for future token types to be 
defined.

 

There were several 
opinions on the call about what we might define as "understanding" including one 
that would create the following rule:

  To process a 
  <wsse:Security> header element with a S:mustUnderstand attribute equal 
  to "1", the implementation MUST know how to process all of the child 
  elements.

alternatively the 
former could be extended:

  ...unless such 
  child elements are explicitly tagged with S:mustUnderstand attribute equal to 
  "0".

This is 
particularly important when implementing tokens that are not specified in the 
core specification and the requestor wants the responder to fail if it does not 
understand the special token type. For example, the proposed Receipt Token 
Profile.

 

The SOAP 1.1 
specification defines the attribute as such:

 

4.2.3 SOAP mustUnderstand Attribute

The SOAP mustUnderstand global attribute can be used to 
indicate whether a header entry is mandatory or optional for the recipient to 
process. The recipient of a header entry is defined by the SOAP actor attribute 
(see section 4.2.2). The value of the mustUnderstand 
attribute is either "1" or "0". The absence of the SOAP mustUnderstand attribute 
is semantically equivalent to its presence with the value "0".

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).

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 understand it.

This attribute MUST appear in the instance in order to be 
effective (see section 3 and 4.2.1).

 

 

 

Eric 
Gravengaard

Reactivity

617-256-0328 
(mobile)

650-551-7891 
(office)

← Prev in month ← Prev in thread