OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wss] ISSUE 70 Part 1: S:mustUnderstand, what part of mustUnderstand don't we understand




I think we should be explicit about what processing must be performed with a default that it is ok to not understand tokens that aren't needed by the service.  

For example, we might say
In other words, I think the default should be that it is ok to ignore elements if you don't care about them or you aren't explicitly requested to process them.

In general the contents of <Security> are intended to provide information, not request processing and if the service doesn't need that information there is no reason it needs to understand that information.

At 11:03 AM 5/20/2003, Eric Gravengaard wrote:
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)
eric@reactivity.com
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]