Re: Question on section 2.7.1, Part 1

Marc Hadley writes:

> On Tuesday, Oct 8, 2002, at 15:40 US/Eastern, 
> noah_mendelsohn@us.ibm.com wrote:
> 
> >
> >>> Why is it important that the header *not* be "mustUnderstand='1'" ?
> >
> > The scenario is:  a bunch of SOAP implementations get deployed and set 

> > up
> > as intermediaries and endpoints along a path.  Afterawhile, I discover
> > there is some information I want to include in my messages and that
> > information is really for anyone who cares.  Maybe I want to put in a
> > "TimeSent" header.  Is it mU?  No.  If you don't care that's harmless. 

> >  It
> > will only be understood selectively as individual intermediaries are
> > redepoloyed with software that can take advantage of the sending time
> > info.
> >
> > What's the problem?  As soon as it hits an intermediary that wasn't
> > updated, the header disappears.
> >
> 
> Only if you target the header to a role the
> intermediary is playing.  The example you give above
> would work quite well targetted at '.../none'. The
> whole message is available to any intermediary so the
> information is there if required. An 'active'
> intermediary could take some action based on the
> presence of a header targetted at '.../none' if it so
> desired.

If I target at none, then I get none of the benefit of
the SOAP processing model, because none forbids me to
process (in the SOAP sense) the header, though of
course I can process it in an ad-hoc manner.  By
targeting an explicit role, I get the benefit of SOAP's
rules about mU checking, ordering, the fact that I need
to "understand" the header to process it (even if it's
not marked mU), etc. 

> > The alternative Henrik suggests, I believe, is:  either use an 
> > application
> > specific role (ICareAboutTime)
> 
> That would be fine too I think, provided everyone who
> played the role also understood the specific header -
> otherwise you would get the problem you describe.

And that's the problem.  In practice, knowing how to
relay is something that's baked into SOAP middleware.
True, we don't mandate implementations, but that will
be common.  Let's say I invent a new role and intend
that it be used for headers that shouldn't disappear.
The problem is, as soon as the message reaches a node
with an old SOAP implementation, if the application
says "play this new role", the wrong thing happens.
The SOAP layer doesn't realized the role is magic, and
discards all headers not processed by the application.

> > or a general relaying Role
> > (IDontRemoveNotUnderstoodHeaders) and claim that any node implementing 

> > the
> > chosen role agrees not to remove headers, even headers that it doesn't
> > process.
> 
> I don't like the above - I agree that it stretches the
> processing model uncomfortably far.

Good. We agree.

> > I'm concerned that this is at least a serious stretch of the
> > processing model which says:  if you play the role, you must remove 
it.
> > You can only reinsert if you have some specific reeason based on
> > processing.  To read that as:  "well actually, you can leave it in if 
> > you
> > know something special about the role"  seems to go well beyond what 
we
> > imply.
> >
> +1.
> 
> Regards,
> Marc.
> 
> --
> Marc Hadley <marc.hadley@sun.com>
> XML Technology Center, Sun Microsystems.
> 

Seems like we agree overall.  Henrik and I had a good
discussion of this earlier this evening, and I think
we've come to a near meeting of the minds.  One or the
other of us will try and write it up within the next
day.  If we can get some sense from a few
correspondents that we've come to a reasonable middle
ground, we'll probably propose something specific to
distApp as a whole.  Stay tuned... 

Thanks.

Noah

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 8 October 2002 21:06:37 UTC