DF: We are lacking terminology. What is the scope of this thing? The scope has been approached by SW and Noah. The first question to answer is to try and define what the things we are dealing with are. Let's try and paint a picture.
HFN: Simple picture: SOAP core (envelope + extensibility mechanism). On top of that, bunch of things: extensions (blocks), not really layering, that can provide functionnalities. Underneath, underlying protocol which also provide functionnalities. E.g. the protocol defines an application, services. The top stuff can be used to build services. The underneath part is not in the SOAP processing model.
GD: Same concepts. Envelope + extensibility and the stuff below. Set of semantics that people might want to implement. You want to leave space for people to come up with what they want. Binding: gets the message from one place to another. Destination needs to be given. Need a framework. [..] We should be thinking about MEP.
MN: How ambitious do you want to get with the description of the binding?
HFN: [..]
GD: Have the description of the functionnalities. Boundary between lower level and higher level.
DF: [..]
HFN: 2 parts have to be described. Fundamental requirements to the envelope: it needs to encapsulate the whole message. Second, it needs to preserve the order within the envelope. Needs to be described. Also a set of more general services: correlation, destination. If those concepts are defined, it should be described how SOAP could take advantage of those.
MH: Connection management, etc, should be described too.
CF: Interoperability is important. It should be crystal clear how to construct software which would be able to communicate with other software. I agree with what Glen is going after: what does the application see from the SOAP processor? I like the infoset view. There might not only be one binding; there can be many bindings (e.g to HTTP).
DF: Requirements document says 2 things. 502: we are going to specify both a one-way and a req-resp MEP. We are also required to define a normative default HTTP binding. Yes, that does not proclude you to use a different one.
SW: Agree with Glen and Mark. We want to be able to delimit patterns.
GD: The application should be able to realize that a correlation block is not needed if the underlying protocol provides this capability.
OH: Not exactly sure where we should go. Should know what functionalities are provided by the binding and which ones need to go as a block. [not sure?] Get to the guys who have already bindings and see what they use, see what we need.
HM: Gathering all the features and functions around MEP, and putting the missing feature in the envelope?
DF: Building stuff from the bottom or from top?
MN: Protocol and messaging framework. Other set of messages expressed in underlying protocol. Worried about having a mapping between the two. Encapsulation is important. Underlying protocol imposes constraints (e.g. HTTP needs request-response). Should not map capabilities to specific functions.
DF: Own picture: can use number of transports. Need some characterization of the services available from the transport: HTTP easily used for one-way + req-response. MEP is a characteristic that we can define. OTOH, mapping any feature to extensions might be problematic (e.g. req-resp over UDP). What happens when there is a perfect mapping? What happens when there is not? Example: find characteristics of HTTP (current: one-way); what are the other things involved. I don't think that we need to map every feature. Don't have the time to describe all the features.
HFN: We do not have a requirement for every MEP over arbitrary underlying protocol.
OH: It is not up to us to define lots of bindings. Need to explain how to describe them. Infoset approach is a powerful interoperability tool.
HFN: HTTP gives you a variety of services. If somebody uses HTTP, it is to take advantage of those services. Same for UDP. Should not have to say how req-resp works over UDP.
OH: People should be able to define their binding the way they want, even if it is specific to them.
HFN: We should not encourage people to have 15 HTTP bindings.
OH: It's not about encouraging them; we can't prevent them from doing it.
DF: We have to provide a "default" HTTP binding, one that we are recommending.
MN: We should encourage people to extend it.
HFN: I don't understand what you mean by adding things to the bindings.
DF: We are trying to provide a general description. Example: Our binding will probably not have any notion of QoS. People should be able to use a feature that we did not use. In a more general way, people should be able to make use of features that we did not use.
HFN: Can you tell me that it means [....] HTTP has a mechanism to indicate where messages are going. We can have the binding define where the message is going?
OH: SOAP messages have to go to a URL. This URL has to be translated into an endpoint.
MH: HTTP binding uses SOAPAction for endpoint.
GD: SOAPAction is useful.
DF: [...]
HFN: We are trying to find places were SOAP has not been clear and clarify them.
MH: We should get rid of SOAPAction.
HFN: SMTP and SOAP are different. It is important to say that we take advantage of the underlying protocol's cool features, but the binding is pretty simple. We should not redifine what SMTP is.
MH: For SMTP, req-resp can be achieved with a Reply-To header. How do you use the features?
HM: We should examine the feature of each protocol [..].
GD: At the SOAP level, you don't care about the HTTP details. 2xx means success, and you don't care about xx.
DF: We should try with the HTTP binding. Come up with a description of a number of features. If you are going to send a one-way message, what does it mean for each of these services? Where does the target location go in HTTP? And then go to another binding. Then compare descriptions. The commonality is the basis for our formalism. HFN is concerned that it is going to force underlying protocol to do unnatural things.
HM: Those examples should be done in parallel.
GD: Infoset idea is in this commonality: abstract representation going from protocol A to protocol B.
HFN: Let's take the typical HTTP to SMTP transition. It is not easy to do. E.g.: how do you carry authentication accross?
GD: HTTP is req-resp. There is no need for correlation id. Then I might need one along the way. Binding might stuck correlation id in the envelope.
HFN: That's fine. There exists a set of cool useful blocks. However, what is the scope of this particular thing? E.g. security. We would need a SOAP block. However, it is not in the same bucket as how do you ship messages around.
DF: We are not going to normatively define all those things. Correlation could be put up as an informative example.
GD: I think that correlation should be done a normative.
DF: It would be good to have concrete examples.
ACTION: OH to do a TCP binding.
ACTION: GD to try to sketch an infoset version of a binding (e.g. HTTP).
ACTION: CF to make a more formal description of the HTTP binding.
ACTION: HM to do an SMTP binding.
CF: Other thing we need to do how one goes about describing another binding.
DF: First concrete instances, and then abstract description. We are shooting for Wednesday.
$Id: 13-binding-minutes.html,v 1.1 2001/07/13 22:49:23 hugo Exp $