Comments inline . .
.
From: Christopher B Ferris
[mailto:]
[stuff removed]
> 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.
-
gp
