Last Update: $Date: 2010-10-12 04:59:19 $
With the exception of one issue raised against the document, all have been resolved to the satisfaction of SOAP/JMS Working Group.
Almost all issues were raised by members of the working group, although sometimes as proxies for other people within the same organization as the person originating the comment/feedback.
Resolution summary below is one of the following:
Closed – issue accepted, addressed, and resolved to the satisfaction of the reporter
Agreed – issue accepted, addressed, and resolved, with no official word from the reporter
ID |
Raised by |
Details: Title/Comments |
Eric Johnson |
Title: Assertion Protocol-2013 is missing RFC 2119 language |
|
Commentary: Opened, resolved, application approved – xml diff. |
||
Eric Johnson |
Title: Assertion Protocol-2020 missing RFC 2119 language |
|
Commentary: Opened, resolved, application approved – xml diff and another diff. |
||
Eric Johnson |
Title: Assertion Protocol-2023 missing RFC 2119 language |
|
Commentary: Opened, resolved, application approved – xml diff. |
||
Eric Johnson |
Title: Protocol-2024 does not include RFC-2119 language, has large associated table |
|
Commentary: Opened, resolved, application approved – xml diff & diff |
||
Eric Johnson |
Title: Protocol-2035 is redundant |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Protocol 2039 redundant, missing RFC 2119 language |
|
Commentary: Opened, resolved, application approved – xml diff and diff |
||
Eric Johnson |
Title: Protocol-2041 is spurious |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Example in C2 contrary to Protocol-2029 |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Phil Adams |
Title: Clarify wording of assertions that deal with fault subcodes |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Phil Adams |
Title: Combine redundant assertions 2016 and 2017 |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Should SOAPJMS_requestURI be in the response message? |
|
Commentary: Opened, Closed with no action, as per 2009-09-08 meeting |
||
Eric Johnson |
Title: MIME multipart terminating boundary incorrect in Example C2 |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Extra space in Schema |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Apparently normative statements about WSDL are not written that way. |
|
Eric Johnson |
Title: WSDL section of spec uses RFC 2119 keywords inappropriately |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Section 3.4.5 refers to a non-existent "soap" prefix |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: References to RFC 3987 are incorrect, not consistent with expected use |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: consistency of references, acronyms |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Normative statements 3001, 3002, 3003 overlap and/or are redundant |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Statement 3004 lacks context, RFC 2119 keywords |
|
Commentary: Opened, resolved, application approved – xml diff |
||
|
Comment: Scribing error during IRC minute taking |
|
Mark Phillips |
Title: Errors in Appendix C2 - MTOM example |
|
Commentary: Opened, resolved, application accepted & accepted again – xml diff |
||
Mark Phillips |
Title: What to do with start parameter in contentType |
|
Commentary: Closed with no action. |
||
Mark Phillips |
Title: Precedence rules for jndiContextParameter |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Mark Phillips |
Title: URI example for jndiContextParameter |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Mark Phillips |
Title: Encoding URI parameters for use in WSDL |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Mark Phillips |
Title: topicReplyToName is missing from WSDL schema and the "Binding of Properties to URI" table |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Mark Phillips |
Title: In 2.6.2.3. the behaviout of the responding node is too prescriptive about the destination to which the response must be sent |
|
Commentary: Closed with no action |
||
Mark Phillips |
Title: The URI is not explicitly mentioned in the precedence rules for WSDL 2.0 |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Mark Phillips |
Title: soapjms:isFault typing is ambiguous and its value is weakened because it is an optional property |
|
Commentary: Opened, resolved, application approved – xml diff, diff, and diff |
||
Eric Johnson |
Title: Protocol-2015 too vaguely worded, probably unnecessary |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Phil Adams |
Title: Assertion 'Protocol-2014' is probably unnecessary |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Peter Easton |
Title: XML Schema should define fault sub-code QName types |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: WSDL 2.0 support not going to be properly tested by implementations, so should be non-normative. |
|
Commentary: Opened, resolved, application approved – xml diff & diff |
||
Title: Please don't rely on JMSMessageID for Protocol 2038 |
||
Commentary: One of our few “outside” comments not routed through an existing committee member. Opened, resolved, application approved – xml diff Approved by David Naramski. |
||
Eric Johnson |
Title: broken and useless reference to m:MaxTime in example in section 2.8 |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Editors list wrong |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Abstract includes RFC 2119 keyword, fails to mention WSDL |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Spurious unflagged assertion about all properties in section 2.2 |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: No need to say where a property MAY appear |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: jndiContextParameter has unflagged RFC 2119 keywords, at least one is spurious |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: replyToName has "SHOULD" assertion about where the message should be sent |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: topicReplyToName has two unflagged assertions, some inappropriate |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Unflagged assertions about message body and content type |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Unflagged assertion about ignoring XML encoding declaration |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Apparently redundant statements are about different versions of SOAP |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Protocol 2034 & 2040 are redundant normative statements about the message body format |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: JMSReplyTo description includes inappropriate use of "must" in section 2.6.1.1 |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Section 2.6.1.3 missing description of what to do on failure |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Unflagged SHOULD about JMSDeliveryMode - not normative |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: Section 2.7.2 restates constraints laid out in [SOAP 1.2 Part 3: One-Way MEP], and almost certainly shouldn't |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: @transport value assertion not flagged, should be |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: @location attribute assertion about being a JMS Destination, but not flagged |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Eric Johnson |
Title: No indication of which references are normative, and which are not, also, inconsistently referring to latest/specific version |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Mark Phillips |
Title: No complete WSDL sample in spec |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Mark Phillips |
Title: Problems with SOAP samples in Appendix C |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Derek Rokicki |
Title: No fault subcode is defined for soapjms:targetService |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Derek Rokicki |
Title: No fault subcode is defined for soapjms:soapAction |
|
Commentary: Opened, resolved, application approved – xml diff |
||
Mark Phillips |
Title: URI encoding explanatory text too restrictive |
|
Commentary: Opened, resolved, application approved – xml diff |
Peter Easton |
Title: soap-jms test-cases 0013, 0014, 0015, 0016 expected message delivery mode should be 2(PERSISTENT) |
|
Eric Johnson |
Title: soap-jms test-cases 1003 and 1103 should be reviewed perhaps have assertion references changed |
|
Peter Easton |
Title: We should have SOAP 1.2 one-way and two-way test cases that are non fault cases |
|
Eric Johnson |
Title: Since adding Protocol-2038 assertion, we now need test cases for non-null JMSCorrelationID |
|
Mark Phillips |
Title: Link to URI specification is incorrect |
|
Commentary: Opened We have left this issue open so that we can track new versions of the “jms” URI scheme as we publish them with the IETF as part of the efforts to complete their process |