- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 5 May 2003 20:36:37 -0400
- To: "Mark Nottingham" <mark.nottingham@bea.com>
- Cc: xml-dist-app@w3.org
Mark Nottingham writes: > Hi Noah, Hi. You raise some interesting points, I think. > I should probably respond to this, as I pushed for > doInclude. > > I agree that doInclude does need to be handled > carefully, especially in respect to the processing > model and its ordering. However, I think that the > issues brought to light are common to many features > exposed as SOAP headers, not just this one. > Could you expand upon why you think that the processing > model would need to be re-run, and why multiple > applications views of the infoset would be required? To > me, inclusion seems like a very similar problem to > message encryption; you need to perform a particular > type of processing on the message before you can > continue processing other headers, so you decrypt (or > include, as the case may be) beforehand, and then > continue. I know that we've discussed this before, but > it may be helpful to have it written down... This point of yours gives me some pause, but let's be careful to work through this methodically: 1. We have indeed considered using headers for activities such as encrypt/decrypt 2. In most of the discussions I've seen, the decrypting node is modeled as an intermediary. No one node rewrites the input infoset and then reprocesses. The intermediary takes an input infoset, as a result of processing relays a modified one. In principle, the relay could be to a piece of software in the same physical machine, or even on the same thread in the same address space. 3. I would also agree that we give a lot of latitude to header-functions in altering the processing model, though I don't think we say anywhere that such processing can modify the input infoset in a manner that alters the input to the processing at the same node. My tentative conclusion from this is: the specification for the decryption header (or doInclude) could call for the equivalent of SOAP processing on the results of the decrypt (include), but the spec for that header would in some sense have to restate the SOAP spec. I'm not even sure if it's doable, at least in the case of decryption. What if decryption exposes an mU header you don't understand. It's at best a somewhat tricky thing to specify properly. 4. Here's the real point: just because it might be possible to spec things this way, doesn't mean it's a good idea to do this above the binding level. See below. > I'm uncomfortable with shifting the responsibility for > inclusion to the binding because it sets a precedent of > performing what could be accomplished by a header in > bindings, to avoid the complexities of integrating them > into the processing model; if this example is followed > by others, it may will lead to an explosion of > bindings. I think there's a very key point to consider: in my view, what's above the binding is portable across transports, and is visible to (some level) of SOAP application. Indeed, it's part of the contract between senders and receivers of envelope infosets. What's in the binding is private to a single hop, unless the bindings conspire to play games through intermediaries. My key point is: I don't want the applications to see the Include. Indeed, my understand of PASWA is that the whole point is that "attachments" are modeled by value as children. It's not the doInclude that bothers me, as I said, it's the xbinc:Include element. That violates the whole notion that PASWA models things by value. I think it also raises many, many architectural complexities. Does a signature sign the child data or the include element? Indeed, one of the claimed benefits of PASWA (and it's one I quite like) is that the infoset can be carried by bindings that don't play tricks: our own HTTP binding can send the character children. What happens if an xbinc:Include makes it over a "smart" binding to an intermediary, and then has to go through a regular HTTP hop? Putting the includes in the bindings (if at all) makes everything come out right. The first binding uses the Include optimization and sends the children in binary. The intermediary node relays the envelope through the regular HTTP binding, the implementation of which (we presume) calls for the characters in the children. This (we presume) causes conversion from binary form to canonical lexical. > I don't think this is "shifting" the responsibility On the contrary, I don't think we're shifting anything. The PASWA model is that the envelope is full of characters. The only time you can play the include game is if the binding is using a collection mechanism such as multipart MIME or DIME that allows for carrying multiple parts and referencing those parts with a URI. Since it's the binding that knows whether it's doing that, it seems to me that the binding starts out as the natural place to make the decision to do the tricky encoding. As I said in my original note. I don't have a strong objection if the binding signals it has done this using a doInclude header, as long as everyone realizes that is more or less private to the binding, and isn't visible from the outside anyway. I claim it should not be processed by the soap processing model, for the reasons given above. > Furthermore, decomposing the specifications (into a > binding that modifies the URI dereference function, and > and a header that activates the Include) gives us the > benefits of modularity and follows the principle of > least power; it may be that some people want to include > external representations, whilst others will want > attachments to not be evident in the message. There is a separate header that provides this separation of concerns, I think, and that is the swa:Representation element. that lets you get some transparency between attachments in the message and other web resources, and it lets all of them be accessed "by reference" using a URI. I have no problem at all with that one being in a header, and in fact I quite like what's proposed. > In any case, I agree very much that our discussion > should be framed by the terminology and concepts in > SOAP 1.2. Good. I think the choices that make sense to me are: * If there is consensus that I am right and that the xbinc:include should be a binding level function, then a PASWA redraft should be done to reflect that. * If there is still interest in perusing an xbinc:include/xbinc:doInclude visible at the actual SOAP processing level, then I suggest that someone do a PASWA redraft that illustrates how this can be done, in the form of a SOAP module specification, and making reasonably rigorous use of the mechanisms of SOAP 1.2. > Regards, > Thanks! Noah ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Monday, 5 May 2003 20:45:40 UTC