RE: [ebxml-msg] Intermediary I-cloud "requirements" draft

Whew, I will respond to excerpts.

Excerpt 1

Here are some of the goals (not axioms!) that we have been discussing for building various I-clouds. It is too early for axioms IMO.

[Hamid]: I don’t know if you are joking with your comment (not axioms!) or you are serious. If you are joking, I need not comment on this. If you are serious, I may need to clarify what I meant by axioms: When I was talking to Sander, I used the term axiom in a “joke” way (not a serious talk). The meaning of my joke was that the design principles should be considered as axioms (meaning that they are extremely important holy law that can never be broken or violated). Indeed, the axioms come after the goals have been specified. Once we know the goals, we write down the axioms (the design principles) that any solution must conform to in order to be an acceptable and a very good solution to standardize. I thought the goals were already specified, otherwise why would we be discussing Sander’s solution on the conf call? If the goals are not yet defined, then Sander should not even propose a solution. In any case, I am very glad that we are starting to tackle the “goals” topic, and I wish I can get more and more information on this topic so that the solution we will propose would be the best. Thank you for providing such an information, but I still have some questions about it as my comments below will show you…

We have use cases from CDC and EU,and these of course are a source of our “requirements” The goals I listed were features that have come up as we have been reviewing solutions for portions of the use cases. The features are those whose absence has counted against solutions and whose presence was a “good thing” (sm).

I have a very iterative view of the design process, so I think talk of axioms is bogus worship of a logician’s reconstruction of mathematics. And I don’t think the iterative solution process we are engaged in benefits from setting down “axioms’ – we don’t know that the models we can build (out of the specifications we are building upon) can simultaneously satisfy your “axioms,” and many of the things you are setting down are not understood the same way and are not at all self-evident.

Routing

a. intermediary cloud can remap an original sender’s message types to a new recipient without the original sender changing its configuration

[Hamid]: First of all, I will be very grateful that you define terminology very precisely before any talk. I never heard the term I-Cloud (or intermediary cloud), and it should be defined before you propose the goals. This is not just for this term, but any terms you will be using in the list of goals need to be defined with great precision and on the front. I will assume here that you mean a chain of Intermediaries (or a network of intermediaries) unless I am mistaken.

Yes. a set of intermediaries where their connections are not of importance

Second, I am not sure I really understand your sentence (and forgive my stupidity). What do you mean by “remap” and what do you mean by “type”? Remap a message type: does that mean changing the type of a message to another type?

Type of message means the kind of collaborative information it contains. Service and action indicate a message type, for example. Remap refers to a change in the routing map, where messages from an original sender of a given type go to a new recipient, but nothing has changed in the configuration of the original recipient relevant to sending the message of that type.

(an Intermediary receives an “Ack” type of message, and it changes that message to something else like an ebms3 user message piggy-backed with the Ack or maybe to another type of message?

What do you mean “to a new recipient”? The original sender is sending for example a user message with a To-Party equals to “sun.com”, and your I-Cloud is giving the message to a receiver that might not even be the party with the name “sun.com”?

b. intermediary should strive to maintain transparency by not modifying message excessively

[Hamid]: I am against any modification of the message being passing through the Intermediaries. “Not excessively” is a very vague word (and very dangerous to use). It does not give a measure of what kind of modifications are allowed. My position on this is very clear: I don’t allow any Intermediary to modify the message.

Precisely my point is to indicate that, contrary to your view, transparency is a “more or less” thing in various dimensions. I could not accept your very clear (but mistaken) “requirement” because it would mean that intermediaries would have to violate the SOAP processing model.

Transparency aspects

a. original signatures remain unbroken (and probably need to be designed to withstand some I-cloud modifications)

[Hamid]: Sometimes, there is a huge difference between theory and practice. In theory, we can elegantly state that signatures should be designed to not be broken easily. In practice, it is extremely difficult for a SOAP node to know whether the modification it wants to do may or may not break existing signatures. The position on this should be very clear by simply not allowing modifications of the message except the headers that are only intended for the Intermediaries. Your sentence I-cloud modifications smells lots of trouble and it scares me a lot. There is only one type of modification (not modifications): the Intermediary may remove the header that is intended for the Intermediaries only. Only the last Intermediary may remove such a header.

Well, we could say sign the SOAP body at most. Then only badly behaved intermediaries would break the signature. And we would want to know about that. We have also discussed allowing intermediaries adding and modifiying headers, like the WSS header. That may or may not be useful for certain proposed solutions. I say take it a case at a time. The wholesale prohibition you espouse is extreme, and is not directly motivated by features of the use cases.

b. reliability assurances are preserved to the extent possible – end to end if possible

[Hamid]: There is no problem with this goal. We were aware of this, and it was taken care of in our solution.

c. data confidentiality is preserved (and may also need to be designed/constrained to enable I-cloud presence)

[Hamid]: I agree with data confidentiality, but I don’t agree that as a sender, I should constrain my confidentiality just because my message will go through intermediaries as opposed to peer-to-peer. The design of Intermediaries architecture should take into consideration that a sender is free to encrypt everything (except the headers that are intended for Intermediaries only).

It is within the realm of acceptable goal satisfying solutions that we allow routers to read information and use it in routing decisions. If those kind of solutions are adopted, it would be good to say that encrypting those headers would be a bad thing and that original senders should be warned not to configure certain headers to be signed.

Endpoints

a. Core conformance endpoints (original sender and ultimate receiver) should not need to modify behavior [at all | excessively].

The sender and receiver are not modifying their behavior at all (this was implicit in axiom 5 J)

The notation hints at a disjunction at this point, because I am uncertain whether some “modifications” (like telling the sender not to encrypt headers used for routing) may be appropriately part of a good enough solution.

b. MSH intermediaries will have special conformance profile

[Hamid]: Totally agree on this: an “Intermediary” is a separate role by itself, and it obviously deserves a conformance profile.

SOAP intermediary

a. A MSH intermediary is also a SOAP intermediary, but may be constrained in certain ways by SOAP (probably underconstrained by SOAP Intermediary rules)

[Hamid]: Intermediary rules only cover the nature of the processing itself: that is what are the actions an Intermediary should do as part of the “header processing”. This is outside the SOAP spec.

b. A MSH SOAP intermediary can be targeted by headers and those headers removed.

[Hamid]: Yes that is the case. The last intermediary is the one who can remove those headers.

Not sure we have consensus on the last intermediary remark. All intermediaries have to remove them when targeted. SOAP allows the intermediaries to put them back in. Result: change consisting of no change.

c. Addition of headers must be carefully scrutinized with respect to Transparency aspects.

[Hamid]: What type of addition of headers you are talking about? Do you mean an Intermediary may add headers that are not even intended for Intermediaries but rather intended for an MSH or a Reliability module for example (like sending a create sequence as Sander’s diagram is illustrating)? The answer is no. Intermediaries are not allowed to add headers that are not intended for them. There will be no transparency if the message can be modified in weird ways.

Why is the answer “no”? I understand that your answer is “no” but that is not part of the use cases.

I think that adding a header might be allowable if it helps define a solution.

ebxml-msg message