In response to DF's "Header Proposal" NM suggested a way forward: For any supported Message Exchange Pattern (MEP), a binding must be provided with an envelope template plus any additional information necessary for local state. Authors of a binding specification are responsible for co-ordinating any such input. The envelope template is the "most envelope-like thing" provided by an application to a binding.
HFN suggests that a binding (1) is identified by a URI, (2) has properties that are identified by URI's, (3) doesn't specify much else.
A "big question" the TF seems to be tackling is what is the relation between the information provided to a binding and the information that the binding puts down the wire? It is suggested there is either (a) a very close mapping betwen them , or (b) a relatively loose mapping. The answer to this question has implications for the existence of properties or other concepts that are common across bindings.
The TF worked on identifying things that are common between bindings, i.e. things that would be described in a "binding framework".
Actions decided:
DF: Sent out the proposal. Surprised by the feedback since the conversations I had on the phone were pretty posiitive. The sketch sent out yesterday was meant to capture recent conversations, including a new processing model. The intent was not to provide a concrete syntax, and it
NM: I looked at your proposal, which goes in the sense where the group is going. The Noah+Glen+Highland proposal was characterizing things that were not only modeled in the envelope, but outside it. We are getting mixed reaction for that. I am wondering if we went too far, and suggest starting like this: binding specifications must tell you the following: envelope template for each properties, plus specify the information which must be maintained locally. I.e. getting us back from the business of adding some information outside the envelope and transporting that "somehow".
DF: last call: we thought that we had had some consensus regarding the description of a binding. We actually didn't have this agreement, so Chris proposed to send a proposal for a few properties. You have come up with something closer to what Chris was suggesting.
NM: so you wanted to build up the architecture by experimentation. I am not trying to oversimplify things, but maybe just having specs saying what information is required and how it is maintained locally is enough. For example, we anticipate that bindings will act on a property called the MEP.
GD: generic case: give a SOAP envelope and say "here, this is exactly what I want to send".
NM: part of what we need to talk is about the contract with the piece of software (e.g. "I will call you back and tell you that it failed").
[..]
GD: 2 visions:first one, the application gives the envelope (a bunch of characters) that it want sent, and the binding is like a pipe; the second one is more fuzzy: the application expresses intent. We have been working on the second one.
HFN: There is a fair amount of controversy on whether this is the right direction. Given the time constraints, we have been trying to back away because we are not going to get any consensus. I think that it is a nice idea, but we are not going to get consensus. I think that both model are perfectly valid. I think that we shouldn't try and make a choice between both.
NM: we should think about the case of the intermediary with 2 different bindings.
HFN: I think that it's a hard case and that we shouldn't say anything about it.
NM: it should be addressed at some point.
[..]
NM: it sounds that the binding framework doesn't offer any commonality at all.
HFN: actually, it is possible that some common properties might be floating around in different bindings.
NM: should those properties be handled in the envelope or should they be handled in a binding specific way?
HFN: You can put whatever you want in the envelope and have the binding envelope. [..]
DF: What is the potential for being able to describe properties accross two bindings? How much of this is possible?
HFN: I don't think that we have to come up with a document talking about common properties, listing them. However, we can come up with a binding with useful properties that people will be tempted to reuse.
NM: There is a difference between pushing people to define properties and going a step further: writing a binding framework defining what it means to have common bindings. It seems that you don't want to say a lot about the body.
HFN: The envelope is something which will have to be provided. The envelope is encapsulated, and something is done with it.
NM: For me, the goal is to transfer the envelope, not to encapsulate it.
HFN: I don't think that it makes any difference, since we cannot know if the envelope has moved.
NM: I think that the spec does talk clearly about messages going from node to node, and the binding's duty is to move the messages. I think that encapsulation is almost orthogonal to that.
DF: It sounds as if we have agreed that one common thing for all the bindings is that they are provided with an envelope. What else can we say about this thing?
SW: The envelope is not enough.
DF: What is this envelope?
GD: It is an infoset.
NM: If there is encryption, if you look at the first intermediary, it might not be what you were expecting.
DF: Do we call that thing a property? Or do we say that "Bindings are provided an envelope".
NM: A correct binding specification must tell you how it will moved things. If not, I think that it is not a binding specification.
HFN: It might be difficult to talk about nodes.
NM: Nodes need roles, and the specification must describe how to go from one node to another one.
HFN: They might not be in the same address space.
NM: Maybe, but they act as a role as defined in the SOAP specification.
[..]
NM: What about SOAP faults? Should I model it as a locally generated fault SOAP message.
HFN: Problem: does it also act as a special actor? We have no mechanism in HTTP for saying that the URI is actually not the final recipient.
[..]
NM: Bindings have to be written to deal with the intermediary case as well as the single hop case. The binding specification for HTTP should say, for example, whether the SOAP intermediary is considered as the final destination.
DF: Could a binding say that it doesn't handle the intermediary case?
NM: That's conceivable. You could say that all bindings supporting req/resp should recreate the value of the property isRequest. Maybe it will be responsible for something else, such as creating a nextUri property.
CF: I consider the binding as being this stupid piece of software moving messages from one place to another.
NM: Chapter 2 doesn't have a hop-by-hop view of the world. The application seems to me like logic which is abose the SOAP spec. But the SOAP spec talks about relaying information between intermediaries.
DF: We need to generate some text for the face-to-face meeting: common things in bindings.
ACTION: Henrik to draft some text for the binding framework by Thursday EOB.
Next telcon: 8am Pacific time.