IRC log of xmlprotocol on 2005-11-30

Timestamps are in UTC.

16:33:26 [RRSAgent]
RRSAgent has joined #xmlprotocol
16:33:26 [RRSAgent]
logging to
16:33:37 [cferris]
I am on conflicting call as well
16:34:07 [dhull]
dhull has joined #xmlprotocol
16:34:21 [mikeem]
mikeem has joined #xmlprotocol
16:34:48 [Zakim]
16:35:14 [Zakim]
16:35:19 [Zakim]
+ +1.858.831.aaaa
16:39:58 [h_scribe]
16:40:09 [h_scribe]
Two new members: Glen Daniels
16:40:15 [h_scribe]
David Hull
16:40:17 [Zakim]
+ +1.514.878.aabb
16:40:24 [h_scribe]
- F2F
16:40:39 [h_scribe]
Mike: trying to have F2F at W3C Tech meeting.
16:40:52 [h_scribe]
However scheduling problems due to other group meetings
16:41:18 [h_scribe]
Solution: saturday after TP.
16:42:23 [anish]
anish has joined #xmlprotocol
16:42:33 [h_scribe]
3. Minutes
16:42:49 [Zakim]
16:42:54 [h_scribe]
16 november: no pushback, minutes approved.
16:43:51 [h_scribe]
4. Action Items
16:44:01 [h_scribe]
Anish: pending
16:44:12 [h_scribe]
Mike: pending
16:44:23 [h_scribe]
Mike: done
16:44:45 [h_scribe]
Noah: done
16:44:59 [h_scribe]
5. Administrative
16:45:26 [h_scribe]
Yves: PP and charter, vote still going on.
16:45:37 [h_scribe]
1 week for PP. Then 1 more week for new charter.
16:45:49 [h_scribe]
Probably finished by EoY
16:46:14 [h_scribe]
(may need to respond to charter comments)
16:46:40 [h_scribe]
7. MEP issue
16:48:35 [h_scribe]
Glen: 1 of main questions: shall MEP exists? And if yes, at what layer?
16:49:11 [h_scribe]
What to do with a WSDL MEP? HTTP has a build-in req-resp paradigm, other protocols may have other paradigm.
16:49:34 [h_scribe]
No consensus about where MEP lives.
16:50:23 [h_scribe]
1 way to see it, is that as SOAP MEP is close to a WSDL MEP.
16:51:06 [h_scribe]
Other way: SOAP MEP is an abstraction of a protocol MEP. HTTP has req-resp, SOAP req-resp MEP that binds to HTTP req-resp.
16:51:30 [h_scribe]
In first case 1 WSDL MEP binds to 1 SOAP MEP that binds to multiple protocol paradigm.
16:51:50 [h_scribe]
In second, 1 WSDL MEP binds to multiple SOAP MEP linked to protocol paradigm.
16:53:21 [h_scribe]
With a SOAP MEP close to HTTP transport, no need of 1-way MEP. Only need req-resp MEP with optionnaly empty response.
16:53:27 [h_scribe]
Think that MEP should stay.
16:53:59 [Zakim]
16:54:02 [h_scribe]
Yves: HTTP natively does have ability 1-way stuff with empty response.
16:55:21 [h_scribe]
Dave: good summary of where things are.
16:55:45 [h_scribe]
Dave: agree that SOAP MEP are usefull abstraction and should be close to transport level.
16:56:09 [h_scribe]
Dave: SOAP MEPs describe what a protocol can propose.
16:56:42 [h_scribe]
Tend to think that every transport should provide a 1-way MEP.
16:58:24 [h_scribe]
To map WSDL MEP to SOAP MEP, it makes sense to have 1-way for everything, even HTTP.
16:59:20 [h_scribe]
Glen: fundamental difference is about where you bound your decision?
16:59:47 [h_scribe]
Dave: no, question is how do we model the way it is signaled.
17:00:26 [h_scribe]
1 approach: in case of HTTP, allways send a response (even if empty). Other way, use 1-way.
17:00:49 [h_scribe]
Glen: choice may be done late.
17:01:29 [h_scribe]
Dave: if define both (req-resp and 1-way), have to build them well, because have to distinguish them at response time.
17:02:18 [h_scribe]
Noah: new pb that can not decide at binding level from the outbound message which MEP is used.
17:02:49 [h_scribe]
Need to do it compatibly with existing REC.
17:02:57 [h_scribe]
Dave: possible to do it.
17:03:29 [h_scribe]
Dave: when define 1-way for HTTP need to have it compatible with req-resp.
17:04:01 [h_scribe]
Noah: can have spec level compatible, but need to have it with software implementations.
17:04:16 [h_scribe]
May have a problem with current implementations.
17:04:57 [h_scribe]
Only way do it, is to add some marker.
17:05:18 [h_scribe]
Means that this new stuff will not be compatible with current implementations.
17:05:34 [h_scribe]
Think it is an incompatibility.
17:06:10 [h_scribe]
But thinks probably a murkier, because many implementations have ignored the REC on this point.
17:06:28 [h_scribe]
Noah: this is not an errata, but a change, because nothing is broken.
17:08:26 [h_scribe]
Noah: case with 2 responses (ack to original sender + true response) common?
17:08:42 [h_scribe]
Marc: Does not append like this.
17:09:54 [h_scribe]
Noah: 1 way: add something in message to say that 1-way MEP is used.
17:10:14 [h_scribe]
Marc: could assume that if not there, then req-resp.
17:10:32 [h_scribe]
Noah: yes: allows compatibility with current REC.
17:11:41 [h_scribe]
Noah: 2 way: create a new MEP, somewhat incompatible with current MEP: send a SOAP message with perhaps a response.
17:11:57 [h_scribe]
Noah: 1st way is compatible, 2nd not.
17:12:27 [anish]
q+ to ask why adding a http header makes it compatible, as opposed to something in the SOAP message
17:12:47 [h_scribe]
Noah: say in spec for new binding, that it is largelly compatible with existing binding, but not completely compatible.
17:13:06 [cferris]
I'm wondering if maybe what is needed is just a oneway SOAP MEP that is NOT supported by HTTP but possibly by other underlying transports such as TCP or BEEP
17:13:16 [h_scribe]
Noah: 3rd option is just to ignore compatibility and rewrite current binding.
17:13:29 [h_scribe]
Noah: 4th option is to use the uberMEP option.
17:13:42 [cferris]
I am actually thinking that maybe we got it right... that for HTTP, there should always be a response SOAP envelope even if it is empty
17:14:22 [cferris]
I am increasingly concerned about the conflation of SOAP MEP and WSDL or higher-level MEP
17:14:31 [cferris]
I think it is a mistake to conflate them
17:14:36 [cferris]
they are completely orthogonal
17:14:47 [dhull]
We mean *not* to conflate them (at least Glen and I)
17:14:59 [h_scribe]
Anish: if we add HTTP header, would not break compatibility. What about using a SOAP header? WSA make it clear whether there will be response or not.
17:15:06 [dhull]
E.g in-out -> either req-rep or two one-ways, depending
17:15:08 [h_scribe]
Noah: think that it is a good point.
17:15:12 [h_scribe]
Can turn question over.
17:15:27 [marc]
i *really* dislike the idea of sending round empty SOAP messages, what is the point ?
17:15:38 [h_scribe]
HTTP header: very early signalling that compatibility is broken.
17:15:38 [dhull]
they might not always be empty
17:15:41 [cferris]
17:16:06 [h_scribe]
Making SOAP depending on WSA is not good.
17:16:10 [dhull]
17:16:11 [marc]
getting two separate response SOAP messages is just adding complexity with no benefit IMO
17:16:17 [cferris]
well, what I dislike is disalowing a SOAP envelope in cases where the WSDL says oneway
17:16:25 [h_scribe]
Feels more natural that the binding knows about transport.
17:16:27 [Zakim]
17:16:49 [h_scribe]
More a matter of taste, whether or not making the HTTP binding dependant on WSA header.
17:17:05 [dhull]
E.g, BEEP request, BEEP "OK" response includes [message id] to say exactly which message it's ack-ing
17:17:23 [h_scribe]
Glen: in spec, 2xx has a blank significance.
17:17:27 [dhull]
(that was aimed at Marc's objection to empty SOAP messages)
17:17:32 [marc]
right so there's no need to repeat that in a SOAP payload
17:17:39 [h_scribe]
Therefore is it OK to fix this.
17:17:52 [dhull]
(? [message id] *is* a SOAP thing)
17:18:18 [marc]
i missunderstood, i meant the BEEP level correlation
17:18:32 [GlenD]
GlenD has joined #xmlprotocol
17:18:36 [h_scribe]
Chris: pb: what WSDL says is at application level. Nothing to do with real message exchange.
17:18:53 [dhull]
That's another way to do it. Maybe better. IMHO there is still an open question as to how WSA MAPs relate to analogous transport-level things
17:19:18 [h_scribe]
SOAP req-resp MEP maps nicely with HTTP messages.
17:19:58 [h_scribe]
People are binding WSDL MEP with SOAP MEP. Is it necessary?
17:20:09 [h_scribe]
Need to make clear what a MEP means.
17:20:27 [h_scribe]
Noah: part of thing to do is to help people to be organized.
17:20:49 [h_scribe]
Intersting thing about SOAP MEP is that allows to make statement about multiple transport.
17:21:27 [h_scribe]
Allowed to remove the transport details from the application.
17:21:53 [h_scribe]
In many cases, it means that SOAP MEP maps pretty close to transport level.
17:23:05 [h_scribe]
Chris: if you have multiple MEP supported by a transport, what signals what MEP to use.
17:23:46 [h_scribe]
Noah: a year ago, seems natural to know from outbound message what MEP is used. Not more the case, with WSA use-cases.
17:24:00 [h_scribe]
Dave: you know what case you have by the response you get.
17:24:06 [anish2]
anish2 has joined #xmlprotocol
17:24:44 [anish2]
+1 to not including blank soap messages
17:24:58 [h_scribe]
Chris: putting blank soap message is not good.
17:25:48 [h_scribe]
Dave: there were cases where it was usefull to send back a SOAP OK message, with something more in it.
17:26:15 [h_scribe]
Not only say: OK I got this 1-way message, but also for e.g. something about reliability.
17:26:48 [cferris]
please attribute "Chris: putting blank soap message is not good." to Marc
17:26:56 [h_scribe]
Anish: if sending back some information, would'nt that be SOAP req-resp?
17:27:14 [h_scribe]
Dave: it could still be a 1-way message at application level.
17:27:47 [Montreal]
Montreal people are going to head out....
17:28:15 [h_scribe]
17:28:25 [h_scribe]
Mike: Christmas schedule.
17:28:44 [Zakim]
- +1.514.878.aabb
17:30:32 [h_scribe]
Mike: 28 dec is off.
17:31:08 [h_scribe]
Mike: probably do 21 dec.
17:31:28 [h_scribe]
Mike: will do 4 jan.
17:32:13 [h_scribe]
- Test collection errata.
17:32:23 [h_scribe]
Anish: one issue is a type.
17:32:30 [h_scribe]
17:32:36 [h_scribe]
Mike: already discuss?
17:32:41 [h_scribe]
Anish: yes.
17:32:50 [h_scribe]
Mike: what is needed to do?
17:32:58 [h_scribe]
Anish: need to agree how to fix it.
17:33:23 [h_scribe]
Mike: take this next week.
17:33:42 [h_scribe]
Mike: If any pushback for the resolution, make it this week. Will make decision next week.
17:34:27 [h_scribe]
action: mike to put e-mail to list for sending response to proposed changes to test collection issues.
17:34:39 [Zakim]
17:34:40 [Zakim]
17:34:40 [Zakim]
17:34:40 [h_scribe]
Mike: call adjourned.
17:34:44 [Zakim]
- +1.858.831.aaaa
17:34:50 [Zakim]
17:35:19 [mikeem]
I was just looking for that
17:36:01 [Zakim]
17:36:02 [cferris]
rrsagent, draft minutes
17:36:02 [RRSAgent]
I have made the request to generate cferris
17:36:18 [cferris]
rssagent, list actions
17:36:31 [cferris]
zakim, please list actions
17:36:31 [Zakim]
I don't understand 'please list actions', cferris
17:36:33 [anish]
rrsagent, make log public
17:37:32 [mikeem]
Yes - it is in the html
17:37:38 [mikeem]
Thanks guys
17:37:39 [cferris]
17:38:01 [cferris]
looks like there were errors generating the minutes... not sure how that gets cleaned up
17:38:09 [cferris]
been away too long:-)
17:38:33 [mikeem]
I'll manual elide when I insert minutes
17:38:41 [mikeem]
17:39:27 [anish]
rrsagent, show actions
17:39:27 [RRSAgent]
I see 1 open action item saved in :
17:39:27 [RRSAgent]
ACTION: mike to put e-mail to list for sending response to proposed changes to test collection issues. [1]
17:39:27 [RRSAgent]
recorded in
17:40:58 [cferris]
17:41:00 [cferris]
cferris has left #xmlprotocol
17:45:46 [dorchard]
dorchard has joined #xmlprotocol
17:48:31 [dorchard]
anybody here?
18:13:15 [mike]
mike has joined #xmlprotocol
18:35:00 [Zakim]
disconnecting the lone participant, Dave_Hull, in WS_XMLP()11:30AM
18:35:02 [Zakim]
WS_XMLP()11:30AM has ended
18:35:04 [Zakim]
Attendees were Marc_Hadley, Dave_Hull, Canon, +1.858.831.aaaa, +1.514.878.aabb, Anish, Pete_Wenzel, Chris_Ferris
18:45:17 [noah_montreal]
noah_montreal has joined #XMLProtocol
18:46:29 [noah]
noah has joined #XMLProtocol
18:48:13 [noah_montreal]
noah_montreal has joined #XMLProtocol
18:48:17 [noah_montreal]
noah_montreal has joined #XMLProtocol
20:01:57 [Zakim]
Zakim has left #xmlprotocol
20:23:39 [noah]
noah has joined #XMLProtocol
20:28:21 [noah_montreal]
noah_montreal has joined #XMLProtocol
21:43:14 [noah_montreal]
noah_montreal has joined #XMLProtocol