|
The meeting was held from 4:00 - 5:30 PM GMT Attendees Present
Regrets/Absent
Agenda
References [1] <http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0021.html> [2] <http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0021.html> [3] <http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0004.html> Discussion Several people had a hard time dialing in (busy call in number) but after a few minutes, all that wanted seemed to want to were be able to call in. Henrik made a request for 3 items
Stuart finished his two action items! :-) We postponed the discussion about scheduling another teleconf to the end of the meeting. RPC Conventions Stuart noted that he does not have any plans to add any more details about RPC conventions into the model document. Security We agreed to have a place holder in the document for security, but we would focus all current discussion on the model and the service abstractions and aligning the terminlogogy. The placeholder needs to suggest that security can be done either within the underlying protocols layers or even at the higher application layers. There will not be a significant core element of the XP layer that that needs to have a full blown security model and service. Security (encryption) can be a feature or a QoS element of the protocol, it need not be strictly a part of the core protocol. Henrik noted that users of XP will want to have hooks for authentication and encryption, but XP could surface those hooks from the services of the underlying protocols. Yves noted that security can be an added value but once caching is introduced, caching will become part of the core. We decided to postpone the rest of the discussion until the Intermediaries discussion. Overview of the Model Stuart had sent out new text and new diagrams. He is struggling to get alignment between the various sections of the Abtract Model and Requirement Document. Stuart noted the longer than expected length of the new model document. Most attendees had reviewed briefly, but not deeply. We decided to focus on the 3 diagrams [2]. Stuart read from his email that described the seeming contradiction between the model and the requirements document glossary and figures [3]. Henrick noted that "application" in the requirements doc did not imply "application layer" but, rather, any software element that used or helped out with XP processing. Also, the requirements doc did not intend to imply any layering. The design goal from the requirements document was that applications using XP can be sliced and diced in many ways with no "single binding" constraints being used. Stuart described the goal of the abstract model as "I have a notion of thinking of XP as being a service. If I want to use it, I look down on the service interface." The top, horizontal line, is a heavier line the the graphic to imply a service definition and abstraction boundary. Scott noted that above the line are entities that use the protocol; below the line are entities that implement the protocol. Henrick noted that application protocols sometimes define both 1) the message syntax and then 2) application layer semantics with certain message types. For example, HTTP defines both the message sytnax and then defines certain messages as well (GET, PUT, etc.) He wanted to suggest that for XP we just define the message syntax but leave message descriptions and message types up to higher level applications. We moved all of our attention to the 3 diagrams. We noted that diagram 3 shows at least 2 scenarios. One is a message sent from XP Application to a final destination using only XP Processors. Another scenario is an XP application that sends a message that is routed back up to some Application Intermediary which reformats a new message to send back down into the XP layer to then arrive at its final destination. Stuart noted that in his writing and thinking, his is having a hard time with the term "XP Message": is it the application piece or the XP piece or both? Scott moved the discussion to the Glossary terms: XP Envelope, XP Header, XP Boddy and XP Block. The application data are definitly XP Blocks but Henrick noted that application data XP blocks can be carried in both XP Headers and XP Bodies. What is the distinction then between headers and bodies? We surmised that perhaps headers are what most Intermediaries process. They can look through headers for blocks that apply to them and they need not process the whole body. Stuard describe a scenario where an application might send 2 blocks down to the XP layer. One block might be in the header. The other might be in the body. The XP Processor in the XP layer might add more blocks to the header in order to help route the entire message. At the far end, the XP processor bound to the destination XP application might remove the XP blocks in the header put their by its peer XP processor and not even raise it up to the XP Application. The destination XP application would receive (via the service interface) only the 2 blocks sent by the orginating XP application, one in the header and one in the body. We need to make sure that our protocol definition allows applications to make their own header semantics. We discussed the need to have both one-way and two-way message service abstactions between XP Applications and XP Processors. There was a significant discussion about sticking with only a simple "send-message" (one-way) type abstraction or adding a two-way request/response type abstraction as well. Any type of messaging semantics can be built on top of the simple "send-message" abstraction:chat, request/response, negotiation, multi-way, etc. Henrik seemed to be leaning towards the former while others seemed to think there was a need for both. Henrik noted that if an HTTP binding is accepted, the XP processor bound to that gets all of HTTP, not just some. For example, if it wanted to support the simple "send-message" abstraction it would have to do so using the request/response nature of HTTP without raising the response back up to the application. In that mapping, other XP messages would not be able to be sent until the first had been replied to with HTTP. In other words, ordered messages would result in an abstraction that does not guarantee or even imply such. We all agreed that given the underlying protocols, almost any XP semantic could be supported via creative mappings to those underlying protocools. We were all concerned that the XP sematics should NOT be the union of all features of all potential underlying protocols. The binding/mapping from XP to any of them would then be very difficult and complex and probably wrong. Scott asked: "In the abstract model will we have two service interface or just one (one-way only or both one-way and two-way)?" There was more discussion, but I don't think the question was answered with any kind of consensus. We discussed how request/response semantics could be mapped over SMTP. We discussed how one-way could be mapped over HTTP. Stuart brought the discussion back from implementation mapping concerns to the interfaces that should be modeled for the "appplication" looking down at the XP layer via the thick black line at the top of the figure. Yves noted that we should want to hide the bindings below the XP layer from the applications above the XP layer. Henrik indicated the problems with that noting how such things as the use of Basic Authentication could be carried through Application layer intermediaries not bound to HTTP. Yves noted that it could be up to the XP processor to decide how to handle such mapping problems. Henrik noted that it could just be a higher level Intermediary, even an application layer intermediary. He also noted the encryption example. The application could encrypt and then pass to the XP processor and not care if the underlying protocol was secure or not, or the application could pass the XP Block to the XP Processor and request that the communication be over a secur! e ! channel and the XP processor could use an SLL type connection. This was follwed by a longer discussion on Intermediaries, that I did not catch very well in the minutes, except to note that Stuart is trying to capture the discussion going on concurrently in Intermediaries thread within the Abstract Model which is hard because both are evolving simultaneously right now. Stuart noted that the idea of "binding context" is where most of this can be resolved in the Abstract Model. The Outbound context can be used to help the XP processor pick the correct binding. On the Inbound context, the XP processor can understand how the message got there. The binding context can also be used to pass on any authentication type information (context, credentials, certificates, etc.) Yves noted that he had a hard time reading the figures at first, but we need to have a much bigger discussion around intermediaries. Caching intermediaries might be at either layer. Stuart noted the example of a small handheld device that only speaks SMTP. In order to send it an XP message from an application that is bound to HTTP, there would need to be a XP/HTTP to XP/SMTP Intermediary bridge. We all agreed more teleconfs are needed. Conclusions
Action Items
|