- From: <Noah_Mendelsohn@lotus.com>
- Date: Fri, 16 Nov 2001 20:48:55 -0500
- To: "Doug Davis" <dug@us.ibm.com>
- Cc: distobj@acm.org, henrikn@microsoft.com, marting@develop.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
We agree. There are scenarios such as the one you illustrate in which
skipping an intermediary, or misconfiguaring software to not do required
processing (getAuthorization), can have dangerous consequences. Core SOAP
doesn't handle it: extensions can.
There are also equally important scenarios in which data can be tampered
with, or disclosed to those who shouldn't see it. Core soap doesn't check
it, extensions can. Likewise for various flavors of transaction.
Likewise for routing, which is surely related to mustHappen. You surely
wouldn't fire weapons without trustworth encryption and tamperproofing for
the message; after all, what if someone turned off your mU bit on
getAuthorization? What if the wrong node claimed to have given you
authorization. We rely on extensions for all of those protections. Why
is mustHappen special? Furthermore, if you go back to the original
discussion, I pointed out that to work right, mustHappen must be checked
at each step in the path, not just at the end (it may not be safe to
process even getAuthorization if the checkSignature header that was
supposed to come ahead of it was missed). Using mU for this purpose
doesn't seem to work.
All of these features are important. Core SOAP can't do any of them.
That's been the SOAP philospophy: put as many of these higher level
capabilities as possible in layered specifications. I'm comfortable with
that tradeoff, and you're obviously not, at least for mustHappen. Of
course, the workgroup can reopen any decisions up until the point we
freeze the specification, but I really do feel that this issue was
considered quite explicitly and in some detail. I don't see any new
factors that we didn't consider the first time around, but I may be
missing something.
------------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
Lotus Development Corp. Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
"Doug Davis" <dug@us.ibm.com>
11/16/01 08:05 PM
To: Noah_Mendelsohn@lotus.com
cc: distobj@acm.org, henrikn@microsoft.com, marting@develop.com,
skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Subject: Re: Issue 146 proposed resolution
Providing an example that doesn't show the problem
doesn't convince me. 8-)
How about the fireNuke example we had back in France:
<Header>
<c:fireNuke xmlns:c='http://us.gov/potus' mu='1'/>
<c:getAuthorization xmlns:c='http://us.gov/potus' mu='1'/>
</Header>
but now add an actor:
<Header>
<c:fireNuke xmlns:c='http://us.gov/potus' mu='1'/>
<c:getAuthorization xmlns:c='http://us.gov/potus'
actor="checker" mu='1'/>
</Header>
There's a little bit of trouble if the "checker" actor isn't hit.
In "core" soap there is no way at all to use a header
targeted for anyone but "next" or the ultimate recipient
and guarantee that it will be processed or a fault will
be thrown. Its useless w/o an extension.
I don't necessarily want MU to be mustHappen (that is one
option, making mustHappen part of "core" soap is another),
what I would like is an agreement that this is a valid
problem that we should look into but until then whenever someone
says "the spec isn't broken" I will continue to say and believe
that it is (IMO of course).
-Dug
Noah_Mendelsohn@lotus.com on 11/16/2001 07:10:26 PM
To: Doug Davis/Raleigh/IBM@IBMUS
cc: distobj@acm.org, henrikn@microsoft.com, marting@develop.com,
skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Subject: Re: Issue 146 proposed resolution
You have raised this concern before, and we have discussed it several
times. A concrete example of where the current design is useful
(namespaces left off and pseudo-URI's used for brevity):
<Header>
<dontCacheThisMessage actor="anyCachingIntermediary"
mustUnderstand="1"/>
</Header>
<Body>
<getAccountBalance> ... </getAccountBalance>
</Body>
There's no reason at all there should be any trouble if this message
doesn't happen to pass a caching server. If it does, it's essential that
that caching intermediary understand the "don't cache" instruction. What's
broken? It's simple and it works.
I know you have said repeatedly that you would like mustUnderstand to have
a mustHappen semantic. It doesn't, but as we have said you can introduce
various flavors of mustHappen as headers which are themselves
mustUnderstand? Separating these two concepts strikes me as a good, not
a bad thing.
Is there new information on this question at this point? It really looks
to me like something that we discussed in detail and settled (in Rennes).
Thanks
------------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
Lotus Development Corp. Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
"Doug Davis" <dug@us.ibm.com>
11/16/01 06:50 PM
To: Noah_Mendelsohn@lotus.com
cc: "Martin Gudgin" <marting@develop.com>, distobj@acm.org,
henrikn@microsoft.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Subject: Re: Issue 146 proposed resolution
Without going into the specifics of this proposal, I do
believe that the current spec if very much broken with
respect to something we talked about a long time ago:
MU=1+actor where that actor is never hit. IMO, if you
use a user-defined actor (ie. not "next") using MU=1
too is a completely useless feature. "Useless" because
no one should *ever* use it. Why would a sender ever
use MU=1+actor if there is no guarantee that that actor
will ever be hit - and the MUness was obviously important
to the sender - but they're never told that that header
was never processed. So, who would ever send any critical
data in that header? The answer should be "no one" - thus
its a useless feature. I know we talked about this and
yes using an extension like "mustHappen" could solve it
but that doesn't excuse the fact that "core soap" has
this useless feature. This is one of my biggest annoyances
with "actor" (and I guess MUs) - and IMO the "core" spec
is broken as a result.
-Dug
Noah_Mendelsohn@lotus.com on 11/16/2001 06:20:27 PM
To: "Martin Gudgin" <marting@develop.com>
cc: distobj@acm.org, Doug Davis/Raleigh/IBM@IBMUS,
henrikn@microsoft.com,
skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Subject: Re: Issue 146 proposed resolution
I think the reason not to do this is that the SOAP processing model then
doesn't apply directly to the header entries: it applies only to the
immediate children of <Header> and <Body>. Of course, we could give the
processing model knowledge of the <Actor> attribute, which would put it in
the core.
I do see that by marking this mU, you can write a spec for <Actor> that
says: add my children to the headers to be processed per chapter2, and
process me really really first so that my mU checks are done before any
other processing. Still, a situation like this:
<envelope>
<header>
<block1>...</block1>
<block2>...</block2>
<actor href='actoruri' mustUnderstand
='true' >
<block3 mustUnderstand="false">
...
</block3>
<block4 mustUnderstand="true">
...
</block3>
</actor>
<block5> ... </block5>
</header>
<body>
...
</body>
</envelope>
looks very conceptually messy if blocks 1,2,5 and <actor> are processed
per chapter 2 rules, with 3 and 4 being the business of the specification
for the Actor extension.
I too have been nervous about he complexity/benefit ratio of
intermediaries, but I think it's very late in the game to be having this
debate. We've had a year to get these things right, we're trying to get
to last call, and unless it's deeply broken I think we should tune it up
and go ahead. I'm not yet convinced that it's broken, or that doing it as
an extension actually works well. Thanks!
------------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
Lotus Development Corp. Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
"Martin Gudgin" <marting@develop.com>
11/16/01 05:39 PM
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>, "Mark
Baker"
<distobj@acm.org>
cc: <Noah_Mendelsohn@lotus.com>, "Doug Davis"
<dug@us.ibm.com>,
<skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
Subject: Re: Issue 146 proposed resolution
Why not this?
<actor href='actoruri' mustUnderstand='true' >
<myHeader1/>
<myHeader2/>
<myHeader3/>
</actor>
<actor href='someotheractoruri' mustUnderstand='true'>
<myHeader3/>
<myHeader4/>
</actor>
Gudge
----- Original Message -----
From: "Mark Baker" <distobj@acm.org>
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: "Martin Gudgin" <marting@develop.com>; <Noah_Mendelsohn@lotus.com>;
"Doug Davis" <dug@us.ibm.com>; <skw@hplb.hpl.hp.com>;
<xml-dist-app@w3.org>
Sent: Friday, November 16, 2001 7:40 AM
Subject: Re: Issue 146 proposed resolution
> +1 (sorry Gudge, only [-1,+1] 8-)
>
> I see no merit to that proposal.
>
> > Only as a mandatory extension and only by effectively redeploying
*all*
> > existing SOAP nodes.
>
> Right, plus we wouldn't be able to keep the existing attribute based
> syntax, since our mandatory extension mechanism is element based.
> We'd have to have something like;
>
> <header>
> <myheader id="foo" ... />
> ...
> <actors mustUnderstand="1">
> <actor ref="foo" value="http://...">
> <actor ref="some-other-id-to-another-header" value="http://...">
> </actors>
> ...
>
> Blech!
>
> MB
> --
> Mark Baker, CSO, Planetfred.
> Ottawa, Ontario, CANADA.
> mbaker@planetfred.com
Received on Friday, 16 November 2001 21:02:13 UTC