(in no particular order)
David Fallside (Chair)
Stuart Williams (scribe)
Chris Ferris
Marc Hadley
Mark Nottingham
Highland Mountain
Glen Daniels
Oisin Hurley
David F: Review current status: Guess we all have the binding proposals from email. We could start by looking at the two HTTP write ups from Chris and MarkN respectively.
Glen: I started to look at correllation id thing with Chris.
David: I think that we had two HTTP binding examples : MarkN and Chris... you did those.
David: We have these two from MarkN and Chris and we need to work on how we bring those together.
David: It was suggested to me in the last few days that if we were to have a mini-F2F then we could get some high bandwidth work done. Who could particpate?
Various: Travel is likely a problem.
viz East coast: Mnot(?), Glen(yes), Hugo(yes?), Stuart(?), Marc(?),Highland(?), Yves(?), Chris(yes), Oisin(no-regardless).
MarkN: When...
Hugo: When... next 3 weeks IETF (London)..
David: Any others going to
London?: Mnot(yes), Glen(?no)
Hugo(yes), Stuart(yes), Highland(?), Yves(yes), Chris(?), Oisin(ditto).
David: Re: The issues list. I'd like this group to propose resolutions for the Issues that Chris identified. With more detailed schedule we have until 2nd/3rd week of august to wrap this up. Get through a bunch on the calls and wrap up remainder at F2F. Also would like a first proposal for a binding by end of this month (a week).
Glen: A particular binding or an binding architecture?
David:
Highland: Take binding examples that have been worked and generate a binding architecture.
David:... we didn't really reach any closure on the two HTTP bindings that we have. Would like to come out of this telecon with agreement on how to merge HTTP binding proposals from MarkN and Chris.
Glen: ...
David: Sounds like you guys have given some thought to specific instance of a binding and to what that means in general.
Glen: <Glen stubs toe!> The basic idea is very similar to where
Mark Jones was going... The idea is essentially to describe the features underneath
the XMLP layer in a similar way to how we describe extensions sitting above
the XMLP layer... named semantic eg... request/response pattern, message id...
represent these in the XMLP Infoset. References blocks that implement requiste
semantics and may be reflected into XML explicit XML serialisation... or could
be implicit in the operation of the underlying protocol. HTTP message correlation
example - ie binding declares how it implements some particular set of XMLP
infoset features....<all paraphrased>. This does not mean that we have
to define every single thing that a binding might do... the definition of a
binding can pick and choose, but new features might mandate
the definition be described in terms of
new XMLP Infoset items that can then if they are
intended to be leveraged into other bindings.
David: Chris anything to add?
Chris: No... that pretty much got it.
Glen: So how does this fit with people's thinking. I know that there are folks with previously expressed concerns.
David: So this means that we might take some hybrid version of Chris and MarkNs HTTP binding description expressed in terms of an infoset...
Glen:....
David: For example, MarkN references as bunch of features...
Glen:...
David: So the generalised architecture of a transports binding is a fairly small hop from here... eg. a template for a block?
Glen: yes... I think it's also important that we define the concept of a message exchange pattern... the binding (sometimes?) needs to know what kind of message pattern is in use. In SMTP for example, the message pattern might exist at a higher layer.
Glen; This certainly has not been thought through all the way.
David: Mark (N) so your HTTP binding was notable in its sparseness compared to what Glen/Chris are describing....
MarkN: It certainly sounds appealing, but I am concerned about how much of the world it requires us to define...
Glen: Can you give some more details re:your concerns... I'd really like to get away from the idea that we have to define everything.... in particular I'm only concerned with defining the things we need to define to do the things that we want to do right now.
David: So... what is Infoset here, because you talk about not sending the infoset over the wire. I think about this from the POV of schema.. Re: XML Schema primer, describes things in terms of angle bracketty XML serialisations examples, but main Schema part 1 (structures) is all in abstract XML infoset terms.
MarkN: So what we're talking about is...
David F: What I understand is, eg. say a correlation id would define say a block that defines how you do correlation... but because we are only defining it at the infoset level we don't say that it has a particular serialisation. How the binding choose to do this is up to the binding. The framework we provide provides you different ways to do this.
Glen: However, I think defining a normative serialisation for these
things is important so that in those cases where serialised into the message
it happens in a 'standard' way (??did I get that right?? right
- the idea is that the extension is defined in terms of the block exchanges
which happen, and if we want the extension to be usable in an interoperable
way across multiple bindings, we should define a normative serialization).
If we could relate this to XMLP modules and
mandate implementation-level APIs that would be
clear, but we can't do that we have to be more abstract than that. (this
last bit came from the concept that often some of the infoset items which frame
a particular protocol event may be expressed implicitly in terms of the APIs
which are called - in other words "ret = call(method, args)" is probably
an RPC, but "send(message)" probably isn't.)
MarkN: So corellation id works ok like that, what about MEPs do they work like that?
Glen: General MEP's... no.... specific MEP's possibly... ie. for particular defined patterns we could define Infoset items and mechanism. (I think this was a comment about not wanting to define all message patterns, just the couple that we're chartered to do)
Glen: ... so there will either be a response or a fault...
Glen: There's possibly an edge case for circular paths... say initial hop via HTTP transitioning to say SMTP... how do I generate a response message with the correct correlation-Id , even more problematic if the path is circular (ie. disticnt return path).
Hugo:
Glen: ... it's possible the most I might expect as an immediiate response is a ack.
MarkN: This is getting into application MEPs that are different from transport MEPs.
MarkN: So do we want to get into that... that the output of this group gets into abstracting the trasnport out to this level.
Glen: ...No... I think the work of this group say captures how you do hop-by-hop request/response. If you want to do more round-robiny things... that's goes at a higher layer.
MarkN: So the RPC folks want end-to-end request response... how do we do that?
Chris:... pause... So i'm thinking about the case where the originating client thinks it's doing implicit correlation.....
Glen: So that's perhaps down to the intermediary... depending on whether that's kind-of linear... I'd posit that if an intermediary forwards the message and expects a response via a different channel, it would need to know that.
Hugo:
Glen: I think that the ability to'implicify' things is very important and if you are 'forced' to serialise all these features all the time we loose out on various optimisations.
Glen: And... the same kind of thing works for higher level extensions to... Glen give an example.
Glen: The simple way to do end-to-end message correlation is to always serialise a message ID.
Chris: yes that's fairly straightforward. Things get trick say with things like security...
Glen: ... so if we have some cryptograpich signature HTTP authenication mechanism, I can say that the my HTTP binding supports this...
Chris: So there's going to be some kind of registry where these things are defined?
Glen: Out of scope.
David: Agreed
MarkN: So where are the use cases....? I just wonder how useful all this is?
David: I thought that this was a discussion about what may be possible on an implicit/explicit basis in transport binding and message? Is that what you were suggesting Glen?
Glen: No...
David: is it enough for us to note the issue in an HTTP binding, eg that if something were to happen such that a binding 'eats' the message id to make it implicit if something further down the line needs a message ID a cautionary note might cover the case?
<failed to keep up>
MarkN: I just don't know if the mapping is that clean. If the HTTP binding periodically eats say a message ID, we have already discussed situations in which an HTTP binding doing that would cause things to break
MarkN: You also mention endpoints...
David: So you would stay away from defining endpoints too?
MarkN: So I incorporated some ideas that Oisin floated on loose bindings (see email).
David: If I read you correctly, the concern is that the further down you go... the more pandora's boxes you open en-route.
MarkN: yes... so there are many underlying protocols that are already completely specified. SOAP is a (business) protocol construction toolkit....
Glen: Except that one of the goals of this is that things should be able to pretty readily interoperate.
MarkN: Right... but what does interoperate mean ;-)
Glen: ...So one of the things that you want to be able to do is to avoid the MxN matix of SOAP features and underlying protocol capabilities....
MarkN: I'd be a little careful... there are toolkits around that just to HTTP.
Glen: ...supercool block semantics example... in the same way you should have some way of defining this is the standard RPC message pattern... by virtue of that the standard SMTP binding then behaves in this way...
MarkN: ...the way I had been reading this is that folks make these choices at the time the define a service (instance?) rather than at the time the specify the software(?).
Glen: Yes I think I see that.
DavidF: ...not sure that I do... Mark are you suggesting....
MarkN: It seems that what Glen is suggesting is maybe
Glen: What I think you are talking about is an 'exploded' version of what I was suggesting. eg... there is this intermediate description
[ the above conversation between Mark and I was, IIRC, about the difference between specifying all of the block-passing in the message as a result of service configuration (i.e. "I'm configured as an RPC service, so I know that I use the CorrelationID block/extension") vs. specifying some slightly higher-level ("intermediate" above) indication of what message patterns, etc are in use, which then imply the usage of particular blocks (i.e. "This message is using the standard req-resp MEP, therefore there is a CorrelationID, whether implicit or explicit") ]
Highland: ....so we're putting pandora's box at deployment time?
MarkN: Yes... I think that you can certainly do that...
DavidF: How much work do you think that is Glen/Chris.
Glen: I think that the biggest piece of the work is working out what are the things we want to specify... giving them names. Once we've done that I think that we can make very rapid progress. We've been dancing around these issues for a while. I recognise that we have limited time.
David F: I note Mark that in your proposal you have two services that you define message correlation and endpoint identification...
MarkN:
DavidF: Are those the only two things that you have as none optional? There are others that are more optional in some sense? That would start to answer Glen's question.
Chris: Yes... that what I was beginning to think to reading Oisin's TCP writeup. Particularly for RPC we need something like correlation ID and you also need to know where the message is supposed to go.
MarkN: So maybe that's what we need to do...
DavidF:
Glen: So I think that this only really becomes complicate when we have to deal with both application level MEPs and transport level MEPs. At some layer somebody has this knowledge that the message goes out through some point that doesn't provide implicit correlation - and I still need to be able to relate this message to that message....
Maybe the answer is that you can't do your RPC like that (implicit req/resp) if you expect the message to go out on HTTP and the response to come back via HTTP.
<Call breaks up...>
DavidF: so... endpoint identification can we talk about that...
Glen: So there are two kinds... eg TCP IP/port and more abstract like 'actor' and I assume that somebody is going to keep a mapping....
David: Presumably we need to capture the who and the where.
Glen: so I gues the question is do we need to specify the where.
DavidF: So I was wondering whether we'd have an infoset item for the where part of the destination.
Glen: i don't think that that (where rather than who?) is so important.
David: Is there a risk that someone else goes out and does this?
MarkN: Yeah... so SOAP-RP is already out there and does this... correlation is different because RPC needs it.
Glen: ...as to whether we need to explicitly spec the form (of where)... I don't think that we need to do this. I think for message ID I think we'll loose interop. On destination, I don't think I need a normative serialisation.
Chris: I think that the abstract model has already captured a bunch of this in terms.
David: The am goes a bit further in that it talks of events (versbs).
Marc: Yes I was going to bring that up, the verbs are important.
???: Could you go into that a little further.
Marc: Yes...example of http tcp/channel management.
MarkN: So what are you saying.
Marc: That theres more to the binding than just what goes in the messsage - end-point management.
MarkN: So HTTP does that already, why to we have to do that.
Marc: Yes, but TCP doesn't...
MarkN: So we then have to replicate a bunch of stuff that happen in other application protocols.
Marc: ... yes... also BEEP has similar needs.
Glen: Envisage this as an infoset that runs up and down the stack.... and for some of these things that you can pull one of these out into some particular namespace and a particular serialiastion.
MarkN:
Glen: ...there are some kind of patterns that might arise between abstract, explicit and implicit mechanisms....
Chris: So the MEP becomes and item in the infoset so that we can talk about. it....
Glen: yes... eg. if I can reference RFC822 then we I can give it a name... that's the kind of thing we want to be able to do. [In other words, by saying "this msg is RFC822 compliant", I have a fixed external reference point (the RFC) which indicates the semantics/syntax of what is expected. Saying "this message follows MEP <URL>" is similar, and also lets programs talk about these things]
Chris: Re: Loose/tight binding.... referenicing say MEPs and say exclusively using POST etc.
David: So we can name an HTTP binding that exclusively uses POST and other people can provide other (differently named) HTTP bindings that use other things than POST, but that new binding gets constructed within the binding framework that we provide.
MarkN: I agree... taking the view of this as an infoset, but being clear that not everything has to get serialised out to line.
David: Can we take your(MarkN) and ChrisF's proposals and the various thoughts on infoset and generate a merged proposal?
MarkN: I think we should try....
Glen: I think that's a great idea...
David: I these Infoset ideas are a way of bringing together some the ideas in the Abstract Model.
Glen: I think that defining two MEPs is necessary: Linear Request/Response (same return path);
Mark: Application or Transport MEPs
Glen: Transport:.... I want two things, I want the correlation ID and I want message patterns... (missed something); [Sorry, don't recall exactly what this was]
Glen: ...the HTTP binding provides this facit if it is being used with this MEP, therefore any message being sent over the HTTP binding with this MEP will not serialise this facit.
David F: MUST NOT, MAY NOT,... variations?
Glen:
MarkN: If I read you correctly, people defining services,... this MEP is characterised by the fact that responses are received on the same connection.
Glen: So the application only needs to know that it's doing application level request/response. It trickles down and somehow may get translated to linear request/response....
MarkN: I think I'm beginning to see some possible problems...
Glen: Can you be more specific...
MarkN: ...maybe to do with circular paths...
Glen:
Stuart: When could we resolve that the path is not circular?
Glen: Somewhere in the middle... eg with SOAP-RP.
Chris: But, maybe I'm misunderstanding something here, but you don't have any control... you don't know....
Glen:... we have to be explicit about some of these abstract things
Chris: So if we're working in infoset terms then we're asking the folks that are doing say SOAP-RP, we're asking them to that in the infoset terms that we define?
Glen:
Chris: further elaboration....so when the message is being assembled there is a correlation id and the binding would know what this thing is....
MarkN: departs and asks about subsequent call.
DavidF: should figure out how to go forward from a more practial standpoint.
Glen
Highland: I like the way this is going, but I think that we need to look at some use-cases.
Glen: Have you looked at the use cases we have already.... in the requirements doc.
DavidF: I think John Ibbotson gave us a bunch of ebXML based scenarios. I agree that there are going to be multiple MEPs and we are not going to have to define them all over every transport.
Chris: So on MEPs I think it was MarkN that identified one-way push, one-way pull, client request/response, 1-N....
David: In our requirements we said that we would do one-way and request-response.
???: But there is a difference between application and transport MEPs.
Glen: ....
David: ok... so we have correllation id, MEP... general distinction between app and transport for all MEPs?
Chris: So... looking at BEEP there is a null transport response....
Glen: So you could imagine an application level RPC mapping to a multicast transport request/response where you'll accept a response from whichever endpoing responds first.
DavidF: Other characteristics?
Chris: Endpoint....
David: I thought that we'd retracted from that...
Chris: ...well we have the to and the from....
Glen: So do we need to know these???
Chris: So lets imagine that I'm using multiple TCP connections I might need to know so that I can match things up....
DavidF: So how about we start with correlation and MEP as a first step, then we can look at it later to see if we need endpoint ident.
Glen: .... so the only things that we need to pull into infoset land is corellation id and MEPs.
DavidF: So can I have a volunteer to work forward from Chris's document.
Chris: So when's our next call?
David: Thursday/Friday?
....
David: How long before you and produce a 1st draft?
Glen/Chris: discussion of relatioship between correlation write-up for RPC-TF and this this action.
Glen: So here's a n MEP and it's request response and the contract is
that you provide an MEPID and that you get
that exact ID back in a response.
Chris: I can certainly do it for Wednesday.
Action (Chris): To produce draft merge of HTTP binding proposals for Wednesday 25th July
DavidF: So Thursday...? 11am Pacific July 26th. 2hrs? c
Stuart: Also closure on possibility of F2F...
DavidF: Looking to get a lot of our work done before 10th Aug anyway.
Action:(All): Investigate for 8th Aug F2F in London.
DavidF: Will get a bridge for Thursday.... Could use mini F2F for proposed resolution of issues.