RE: [ws-rx] issue 115: clarifying question

> Using a separate SOAP header places the flag/annotation in a > completely separate part of the SOAP envelope. It seems strange to > do this solely because "SOAP:mustUnderstand" can only be applied to > headers. As I pointed out earlier, it also complicates the security > processing because I need to remember to include any "extension flag > headers" in the signature that encompasses the thing being extended.

This isn't a "complication" since the spec already cautions that the
headers need to be signed with the body.

"Cautioning" and "doing" are two different things. People who implement extensions will have remember and do more things if we make them flag mU extensions in SOAP headers.
> There is also a granularity problem. "wsrm: > ExtendSeqAcksToIncludeAnEPR" just says that somewhere in this > message is a SequenceAcknowledgement that has been extended to > include an EPR and that the receiver needs to understand what this > extension means. It doesn't say which SequenceAcknowledgment (there > can be more than one in a message) has been extended.

It doesn't NEED to tell you WHICH one has it, it is asserting that the
SOAP node "understand" that particular use of the extension.

You are making the assumption that it is the "type" of the extension that must be understood, not the particular "instance". There are pros and cons to each, and it may be that both instance and type mustUnderstand are appropriate. FWIW, soap:mustUnderstand is on the instance of the header, not the type.

> Also, people keep saying "a" new SOAP header as if we were talking > about the creation of a single new header when what we are really > talking about is the creation of a new header for every extension to > every message or header. If I add an STR to CreateSequence it's one

OMG! Alert the media!

LOL! I would but I'm afraid the story would just get buried behind "ALL SOAP STACKS OBSOLETED!" > header. If I add an STR to CreateSequenceResponse it's another > header. If I add an EPR to AckRequested . . . you get the point. I > can't help but think that creating a single new attribute is much > simpler than creating a multitude of new headers (of course, this TC > isn't the group that will have to create all these new headers and > maybe therein lies the appeal).

I would rather have this than require that all SOAP processors change
the way in which they parse and process messages. Furthermore, since you are
expecting every other spec to do the same thing, then that means that each one
will have such an effect on the SOAP parsing/processing. Somehow, I think that
is a REALLY BAD IDEA.

You have repeatedly asserted that all SOAP processors will have to change to support the wsrm:mustUnderstand attribute yet you have provided no evidence or argument to support this assertion. Futhermore, I am not "expecting" every other spec to do anything so kindly refrain from putting words into my mouth.

ws-rx message