IRC log of soap-jms on 2009-10-27

Timestamps are in UTC.

16:00:19 [RRSAgent]
RRSAgent has joined #soap-jms
16:00:19 [RRSAgent]
logging to
16:00:21 [trackbot]
RRSAgent, make logs public
16:00:21 [Zakim]
Zakim has joined #soap-jms
16:00:23 [trackbot]
Zakim, this will be SJMS
16:00:23 [Zakim]
ok, trackbot; I see WS_SOAP-JM()12:00PM scheduled to start now
16:00:24 [trackbot]
Meeting: SOAP-JMS Binding Working Group Teleconference
16:00:24 [trackbot]
Date: 27 October 2009
16:01:59 [Derek]
Derek has joined #soap-jms
16:02:36 [Zakim]
+ +1.708.246.aaaa
16:03:03 [Zakim]
+ +0196287aabb
16:03:28 [mphillip]
zakim, aabb is mphillip
16:03:28 [Zakim]
+mphillip; got it
16:03:33 [Zakim]
16:04:12 [eric]
eric has joined #soap-jms
16:04:20 [mphillip]
16:04:33 [mphillip]
chair: Eric
16:04:48 [mphillip]
Scribe: mphilip
16:05:33 [mphillip]
Topic: 3) Review the agenda
16:05:42 [mphillip]
regrets: Phil and Peter
16:05:51 [mphillip]
Topic: Approval of prior meeting minutes
16:07:02 [mphillip]
Minutes from 13-10 approved
16:07:10 [mphillip]
Minutes from 20-10 approved
16:07:22 [mphillip]
Topic: Review action items
16:08:17 [mphillip]
Derek: - questions about non-normative MEPs - specifically robust in only
16:09:09 [Zakim]
16:10:17 [mphillip]
Derek: FAQ on non-normative MEPs could be very simple - just state that they are not prohibited, or
16:11:04 [mphillip]
Derek: FAQ could say that it is an extension / derivation of request reply
16:12:09 [mphillip]
Amy: The WSDL MEP definitions for "optional response" did not originate from Req/Resp
16:13:15 [mphillip]
Amy: Robust in-only is designed for connection oriented protocol - allows an error to be returned
16:13:40 [mphillip]
Derek: Not calling it req/resp - but it shares the replyTo with req/resp
16:14:47 [mphillip]
Eric: Suggest we defer until later
16:15:15 [mphillip]
Eric: - no progress
16:15:39 [mphillip]
Mark: - applied resolution for issue 4
16:15:55 [mphillip]
close action-109
16:15:55 [trackbot]
ACTION-109 Update the specification to reflect the change to Protocol 2021 assertion closed
16:16:13 [mphillip]
Eric: 112 still open
16:16:27 [mphillip]
Eric: Issue opened for 116
16:16:32 [mphillip]
close action-116
16:16:32 [trackbot]
ACTION-116 Correct the "soap" prefix reference in section 3.4.5 closed
16:16:47 [mphillip]
Eric: Issues opened for 118, 119
16:16:50 [mphillip]
close action-118
16:16:50 [trackbot]
ACTION-118 Review the spec for references, and propose resolution closed
16:16:52 [mphillip]
close action-119
16:16:52 [trackbot]
ACTION-119 Try to determine what is normative and how to generate test cases. closed
16:17:04 [mphillip]
Phil: - no update
16:17:13 [mphillip]
TOPIC: 5) URI specification:
16:17:17 [mphillip]
Eric: No update
16:17:28 [mphillip]
TOPIC: 6) Raised issues:
16:17:44 [mphillip]
Eric: Back to discussion on MEPs
16:17:57 [mphillip]
Derek: FAQ could just state that MEPs are not prohibited
16:18:45 [mphillip]
Derek: or FAQ could go into more detail about how the spec applies - e.g. use the same mechanism as req-resp for returning an optional response
16:19:16 [mphillip]
Amy: We would need a binding to specify a MEP
16:19:50 [mphillip]
Amy: If we want support for the robust in-only MEP then we must write up the binding
16:20:18 [mphillip]
Amy: (or someone must write it up)
16:20:57 [mphillip]
Eric: Don't see how robust in-only maps to JMS - would like to see a concrete proposal explaining the mapping
16:22:13 [mphillip]
Amy: Quite easy - take the in-only MEP, take the replyTo from the inbound message, and use it to send a fault if one is required... could use the return portion of our request-response MEP as a template for this
16:22:44 [mphillip]
Eric: When using asynchronous JMS how long do you wait for the fault before you decide that one isn't coming
16:23:31 [mphillip]
Eric: etc. - so would like to see a proposal
16:23:49 [mphillip]
Amy: Could do this with an "error window" property
16:25:42 [mphillip]
Amy: Can discuss the issues in an FAQ, but someone needs to write the MEP binding to have an interoperable MEP
16:26:57 [mphillip]
Derek: Would we need a new version of the spec if we added a new MEP
16:27:11 [mphillip]
Amy: Yes, we would need to go back to Last Call
16:28:04 [mphillip]
Amy: Alternatively we could add a new document - the "Robust in-only binding extension for SOAP/JMS" which would go through the specification process without setting the core Binding spec back to last call
16:28:55 [mphillip]
Eric: 3 options:- Put a note in FAQ; Revise the existing binding spec; or Add a separate spec. extension
16:30:50 [mphillip]
Amy: This would be a big FAQ extension, suggest we have a more general FAQ question which points to a normative Binding Extension
16:31:50 [mphillip]
Mark: Not sure of the need for a robust in-only MEP when using the inherently reliable async JMS transport
16:33:25 [mphillip]
Derek: Were the robust MEPs added to WSDL for JMS?
16:34:42 [mphillip]
Amy: Some of the motivation for more extensibility in WSDL 2.0 was pub/sub and the desire for more sophisticated MEPs
16:37:01 [mphillip]
Eric: Derek, could you make a proposal if this is something you feel we should support?
16:38:01 [mphillip]
Derek: Don't feel it is necessary - not a lot of JMS users will require this
16:39:30 [mphillip]
Amy: If someone wants this then they should submit a draft proposal to the SOAP/JMS Working Group. In the FAQ we could ask people to submit such a draft if they feel it is justified.
16:41:15 [mphillip]
RESOLUTION: Derek to write the FAQ Entry - Amy offered to review
16:41:47 [mphillip]
Eric: On to the raised issues:
16:44:30 [mphillip]
Eric: - Section 3.4.5 makes a reference to a non-existent soap prefix
16:44:49 [mphillip]
All agree to open this issue
16:45:44 [mphillip]
Eric: - References to RFC 3987 are incorrect - it is the IRI spec. but we now refer to URIs
16:46:03 [mphillip]
All agree to open this issue
16:47:35 [mphillip]
Eric: - Existing specification makes inconsistent use of references, acronyms - e.g. Java Messaging Service is defined as JMS but we do not make consistent use of the acronym throughout
16:47:51 [mphillip]
All agree to open this issue
16:50:07 [mphillip]
Eric: - WSDL statements about priority of properties are confusing
16:50:13 [mphillip]
All agree to open this issue
16:51:06 [mphillip]
Eric: - normative statement 3004 does not stand on its own (and has no normative keywords)
16:51:41 [mphillip]
Eric: Need to define where the XML elements for these properties should occur
16:52:16 [mphillip]
All agree to open this issue
16:52:31 [mphillip]
TOPIC: 7) Accepting proposals to close open issues
16:52:43 [mphillip]
16:53:45 [mphillip]
Eric: - this is a lot of small edits - everyone needs to read and review before we can close
16:54:16 [mphillip]
Eric: Please review before next week
16:54:25 [mphillip]
TOPIC: 8) Accepting applied resolutions:
16:54:39 [eric]
Email for issue #4:
16:54:47 [mphillip]
Mark: Applies to
16:56:05 [eric]
17:00:34 [mphillip]
Eric: There is duplication in section 2.2.4 - the bullets and third column duplicate Protocol 2021
17:00:56 [mphillip]
action Mark to remove the duplication from 2.2.4
17:00:56 [trackbot]
Sorry, amibiguous username (more than one match) - Mark
17:00:56 [trackbot]
Try using a different identifier, such as family name or username (eg. mhapner, mphillip)
17:01:05 [mphillip]
action mphillip to remove the duplication from 2.2.4
17:01:05 [trackbot]
Created ACTION-120 - Remove the duplication from 2.2.4 [on Mark Phillips - due 2009-11-03].
17:02:48 [Zakim]
- +1.708.246.aaaa
17:02:49 [Zakim]
17:02:49 [Zakim]
17:02:51 [Zakim]
17:02:51 [Zakim]
17:02:52 [Zakim]
WS_SOAP-JM()12:00PM has ended
17:02:54 [Zakim]
Attendees were alewis, +1.708.246.aaaa, +0196287aabb, mphillip, eric, Yves
17:03:08 [mphillip]
rrsagent, make minutes
17:03:08 [RRSAgent]
I have made the request to generate mphillip
17:03:14 [mphillip]
rrsagent, make log public
17:08:38 [eric]
eric has left #soap-jms
18:05:07 [Zakim]
Zakim has left #soap-jms