XMLP Working Group Transport Binding Task Force Meeting: 2 August 2001, 11am-7pm EDT

See also the minutes of the meeting.

IRC log

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