See also the minutes of the meeting.
10:46 -!- hugo changed the topic to: TBTF face-to-face
10:56 <Yves> I hope my "magic" phone will remain non-magical today ;)
11:00 <Yves> damn
11:02 <hugo> we are not on the bridge yet
11:04 <Yves> ah finally it worked
11:05 <davidF> yves - are you on the bridge?
11:05 <Yves> yep!
11:05 <Yves> after 4 tries only :)
11:05 <davidF> what is the brdige number?
11:06 <hugo> Bridge: MarcH, Yves
11:06 <Yves> +xx-xxx-xxx-xxxx
11:06 <hugo> MIT: Noah, Hugo
11:06 <Yves> Meeting ID: xxxx
11:06 <Yves> (http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jul/0169.html)
11:07 <hugo> Akamai: Mark, Highland, David
11:08 <Yves> nice echo :)
11:11 <hugo> + Glen
11:15 <Henrik> Hugo, Chris is lost - could you give him a call at xxx xxx xxxx to tell him where you are
11:15 <Henrik> what is the bridge number?
11:15 <davidF> wow!
11:15 <Yves> +xx-xxx-xxx-xxxx
11:15 <Yves> Meeting ID: xxxx
11:16 <Henrik> calling...
11:17 <hugo> we are giving directions to Chris
11:19 <hugo> we are "driving" Chris Ferris :-)
11:19 <mnot-lapt> hugo - can you guys hear us?
11:20 <hugo> no, I put the line on hold
11:24 <hugo> DavidF gives the outline of the work for today
11:24 <hugo> ... goals
11:25 <hugo> ... dive into them separately
11:26 <hugo> Henrik: we should start with the framework
11:26 <hugo> -----
11:26 <hugo> Framework
11:26 <hugo> -----
11:28 <mnot-lapt> "The information needed to send a message and the information available
11:28 <mnot-lapt> when receiving as message is modelled abstractly as a set of named typed
11:28 <mnot-lapt> properties some of which may be representable as standard XML infoset
11:28 <mnot-lapt> entries. Some of this information will be mandatory for all bindings.
11:28 <mnot-lapt> Specifications for particular bindings and message exchange patterns can
11:28 <mnot-lapt> require additional such properties and can provide additionally for
11:28 <mnot-lapt> properties that are optional." (rough wording taken from July 30 TBTF
11:28 <mnot-lapt> telcon [1])
11:28 <Yves> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jul/0172.html
11:28 <hugo> +Chris
11:31 <hugo> Henrik: Concern: we should not diving into the "black box"
11:34 <hugo> Glen: if you want to reuse protocols features, you need to express how those features relate to the higher layer
11:35 <hugo> s/layer/concept/
11:38 <hugo> Noah: people (e.g. Lotus people) want to write applications without knowing what binding is going to be used
11:40 <hugo> ... one would explain what one wants (authentication, correlation, ...) and things should happen as such [ paraphrasing heavily ]
11:42 <Yves> the main thing missing for now is the description of the endpoint, URI scheme
11:42 <hugo> +Paul Denning here at MIT
11:43 <hugo> (can't zoom out more)
11:46 <davidF> markN speaks next
12:01 <mnot-lapt> EAST COAST: ONE AT A TIME PLEASE
12:13 * Henrik test
12:13 <Yves> pong
12:24 <Yves> for SMTP multicast is a mailing list ;)
12:29 <mnot-lapt> or one of those annoying people who puts a long list of people in the to: address ;)
12:30 <Yves> people are known so it is more multiple-unicast, ML are opaque like multicast
12:30 <mnot-lapt> mm, good point
12:30 <Yves> with SMTP both may be annoying ;)
12:36 <davidF> david speaks next
12:46 <Yves> What the XMLP processor should provide? the message, an URI (xmpl:http://myhost/myservice or xmlp:stockquote for example), context(?) (for MEP, session tracking), then define how the bindings will use that.
12:57 <davidF> a binding = an encapsulation of a message + a way of sending the message content + .......
13:19 <Yves> I have to drop off now, see you!
13:19 <Yves> (in 5mn max ;) )
13:22 <davidF> ;-)
13:22 <davidF> hello
13:34 <Henrik> Some ideas for what a binding author should think about:
13:34 <Henrik> What are the supported message exchange patterns
13:34 <Henrik> What are the security mechanisms supported?
13:35 <Henrik> How is fault handling done
13:35 <Henrik> How is endpoint identification handled?
13:41 * Frystyk test
13:41 <Frystyk> are you there?
13:41 <hugo> yes
13:41 <Frystyk> ok :)
13:42 <Glen> We're all going to be on IRC in a moment anyway.
13:44 <Noah> Hello from Noah
13:46 <chris> hi
13:46 <Glen> hola
13:52 <Henrik> Just to repeat the list of properties that a binding author has to consider:
13:52 <Henrik> what are the supported message exchange patterns?
13:52 <Henrik> what are the security properties?
13:52 <Henrik> what is the QoS assertions provided by the binding?
13:52 <Henrik> is the binding point-to-point or multi-point?
13:52 <Henrik> does it provide a mechanism for saying where to send a message?
13:52 <Henrik> does it provide any correlation mechanism?
13:53 <davidF> presumably the "null" binding has the value null for each of these propoerties?
13:53 <Henrik> yes
13:54 <chris> agreed
13:55 <Henrik> I forgot one: does it know how to handle faults
13:55 <chris> glen/noah say no
13:56 <Henrik> no to the list?
13:56 <davidF> or not to faults?
13:56 <chris> no to the handling/returning of faults
13:56 <davidF> s/not/no/
13:56 <Noah> Uh...I think we decided that the binding (now called) Raw is one way, doesn't transmit SOAP faults. It could conceivably give indications of failure to deliver, e.g. due to link down.
13:57 <chris> agreed
13:57 <Henrik> I meant to disambiguate between generating faults and where to send them
13:58 <Henrik> I agree that the raw binding is only one-way
13:59 <Noah> ...and I think we also want to note that there are conceivably errors which are known locally to the sender, which are not covered by the SOAP spec at all at this point. For example, if the link is down, the binding might tell the sender "I can't send your one way message."
13:59 <Noah> By contrast, I think that most SOAP faults are not deliverable in the case of a one way pattern.
14:00 <Henrik> I agree
14:00 <Noah> In any case, this is not a big deal. If you want to call them all SOAP faults, I guess that's OK.
14:01 <Henrik> I tried not to lock in on SOAP fault but to keep it more generic
14:04 -!- chris [~chris.fer@43-2-97.dynamic.lcs.mit.edu] has quit [Connection reset by peer]
14:05 <mnot-lapt> attributes that an underlying protocol which is request-response supplies:
14:05 <mnot-lapt> - correlation
14:05 <mnot-lapt> - client / server id (endpoint identification)
14:05 <mnot-lapt> - message ordering (I send a message, you send a message...)
14:06 <hugo> All: bridge number: +x-xxx-xxx-xxxx (xxxxxx)
14:06 <davidF> we're changing over -- let noah know!
14:06 <mnot-lapt> other general attributes:
14:06 <hugo> as soon as he is done :-)
14:06 <davidF> ok
14:07 <mnot-lapt> - connection initiation (NOTE: different than endpoint id; example, BEEP)
14:08 <Noah> Noah now knows, thank you!
14:08 * Henrik dialing
14:08 * davidF dialling
14:26 -!- chris [~chris.fer@43-2-97.dynamic.lcs.mit.edu] has quit [Ping timeout]
14:34 <mnot-lapt> DAVIDF talks next
14:36 <mitrepaul> I have to leave. Hope you converge soon.
14:36 <Noah> bye
14:36 -!- mitrepaul [~pauld@24-6-237.wireless.lcs.mit.edu] has quit [Connection reset by peer]
14:41 <hugo> mnot-lapt: can you take a picture of this diagram?
14:51 <mnot-lapt> hello?
14:51 <davidF> drop out!!!
14:51 <davidF> did we lose the bridge?
14:51 <Henrik> I am here
15:05 <davidF> noah- did you send the gif?
15:05 <hugo> he is still working on it
15:05 <davidF> ok
15:05 <Henrik> it might be better to wait until we understand both diagrams and how they relate
15:12 <davidF> we have now used 1/2 of our time
15:12 <chris> tick tock
15:14 <davidF> is the next step to decide on a list of properties? we could start with the properties necessary to define an http binding
15:18 <mnot-lapt> lost you again!
15:19 <chris> we're baaack...
15:24 * Henrik ping
15:25 <Glen> pong
15:26 <chris> doingggg
15:28 <chris> henrik, i think i agree...
15:30 <hugo> Diagram by Noah: http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0031.html
15:40 * davidCF test
15:47 * davidF test
15:56 <Glen> ping
15:56 -!- hugo changed the topic to: TBTF face-to-face / break for 20 minutes
15:57 <chris> hello
16:03 -!- chris [~chris.fer@43-2-97.dynamic.lcs.mit.edu] has quit [Ping timeout]
16:18 <Henrik> I had a very tough time connecting
16:19 <Henrik> I just sent a proposal out by email regarding the structure of a binding framework description - flame as appropriate :)
16:22 <Henrik> I just sent a proposal out by email regarding the structure of a binding framework description - flame as appropriate :)
16:23 <hugo> where did you send it?
16:23 <Henrik> to TBTF
16:24 * hugo doesn't see anything
16:25 <Henrik> In fact, if we merge it with Glen's outline at http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0333.html then I am happy :)
16:25 <Henrik> ups - had to sync my mail
16:33 -!- hugo changed the topic to: TBTF face-to-face
16:44 <Noah> Just to get this logged, I wanted to note the current discussion that even an envelope infoset prepared by an application for transmission can get changed by, for example, encryption.
16:44 <Noah> In the case where end-to-end encryption is to be done (using the public key of the endpoint), we should not expect to recreate the original envelope infoset at the intermediaries.
16:48 -!- Noah [~Noah_Mend@24-6-147.wireless.lcs.mit.edu] has quit []
17:03 * davidF reminds the tf we have 2 hours left
17:15 * Henrik says hi
17:15 <chris> hi;-)
17:20 <chris> hi paul
17:21 <mitrepaul> hi, just poping in for a minute to see if meeting was still going on
17:21 <chris> yes, you can dial in if you like...
17:22 <Henrik> proposed list:
17:22 <Henrik> What are the supported message exchange patterns?
17:22 <Henrik> What are the security properties?
17:22 <Henrik> What is the QoS assertions provided by the binding?
17:22 <Henrik> Is the binding point-to-point or multi-point?
17:22 <Henrik> Does it provide a mechanism for saying where to send a message?
17:22 <Henrik> Does it provide any correlation mechanism?
17:22 <Henrik> Does the binding know how to handle faults
17:22 <mitrepaul> have to go again. Thanks anyway.
17:22 <Henrik> (cut and paste from earlier - take with moderation)
17:24 * hugo is writing this down
17:30 * davidF is writing this on the board
17:31 * hugo will copy the board then
17:34 <mnot-lapt> tick tock tick tock tick tock
17:36 <chris> I hear Pink Floyd in my head;-)
17:44 <davidF> 75 minutes
17:46 * hugo sees David ready to jump on the phone
17:46 <davidF> i didn't realise the camera had moved!
18:07 <Noah> Noah has joined.
18:08 <Noah> Noah wants to log that even in the case of a one way message, information at the sender flows up to the sender, as well as down from it.
18:08 <Henrik> yes, I agree
18:09 <Noah> For example: I attempt a one-way send and there is no hardware link at all. Presumably the HTTP binding can define an error to be reflected to the requestor "I couldn't send your message...no hardware."
18:09 <Noah> Ultimately, we wind up with a distributed state machine. At each transistion we define (a) which properties are significant (b) what processing is attempted and therefore (c) what flows on the wire (d) what are the possible resulting transitions.
18:09 <Noah> Or something like that.
18:10 <Henrik> The diagram actually is very symmetric - when sending, the message flows down towards the bottom but can fail at any point. When receiving, the message flows up but can also fail on the way up
18:10 <Noah> Yup
18:10 <davidF> i can see that
18:10 <mnot-lapt> +1
18:10 <Noah> I'll try and edit the diagram (again)
18:11 <hugo> "Although SOAP might be used in combination with a variety of HTTP request methods, this binding only defines SOAP within HTTP POST requests
18:11 <hugo> "
18:12 <Henrik> right
18:13 <hugo> Hugo's list for one-way:
18:14 <hugo> MEP: one-way
18:14 <hugo> Method: POST
18:14 <hugo> Transfer-level URI: ...
18:14 <hugo> Content-type: {text/xml, ...}
18:14 <hugo> Envelope: .... + character encoding
18:14 <hugo> SOAPAction:
18:14 <hugo> HTTP status code: {200, ...}
18:14 <hugo> i.e. request-response's list with method fixed and message-role gone
18:14 <davidF> i think we also need to include error-specific info
18:40 <hugo> Linux NetMeeting stuff: http://www.openh323.org/
18:44 * Henrik says bye
18:49 * davidF says ciao