[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: PR Issue 8 - 15: [ws-rx-comment] re:Feedbacks to WS-RM PublicReview Draft
I propose breaking this into multiple PR issues as follows inline. If that is acceptable to the TC I'll report back to the issue filer with the relevant issue numbers.
-----Original Message-----
From: Sugamata [mailto:hsedi@attglobal.net]
Sent: Wednesday, October 18, 2006 5:58 PM
To: ws-rx-comment@lists.oasis-open.org
Cc: masahiko.narita@jp.fujitsu.com; kiwasa@jp.fujitsu.com
Subject: [ws-rx-comment] re:Feedbacks to WS-RM Public Review Draft
Dear WS-RX WG members,
We reviewed WS-ReliabileMessaging Committee Draft 04 among eBusinss Asia
Committee.
And we would like comment some feed backs for the documentation.
I resend our comments in line of this message.
Sincerely,
Hisanao Sugamata
ECOM, Japan,
Chairman,eBusinss Asia Committee
==================================================================================================
2006/10/18
eBusinss Asia Committee
Feedbacks to WS-RM Public Review Draft
PR Issue 8
---
There is interoperability issue with this specicication, since it doesn't
define underlying protocol bindings (e.g.,HTTP bindings). The spec or its
profile should explicitly define underlying protocol bindings.
---
1.Public Review Draft (Committee Draft 04)
http://lists.oasis-open.org/archives/tc-announce/200608/msg00005.html
2.Feedbacks to the Committee Draft 04
PR Issue 9
---
2.1 This specification dose not define how to realize "Duplicate
Elimination" and "Message Ordering". It is a serious issue for industry
organizations in Japan and Asia to adopt the specification.
We strongly recommend to define them to make various implementations
interoperable.
---
PR Issue 10
---
2.2 It is not clear whether AckRequest message can be sent independently or not.
The 3.8 describes:
"The RM Source MAY request an Acknowledgement Message from the RM
Destination at any time by including an AckRequested header block in any
message targeted to the RM Destination."
In detail, is the following message which doesn't include
<wsrm:Sequence>, allowed
to send? If so, the above sentence should explicitly describe it. See the
first four lines in Section 3.9.
<soap:Envelope>
<soap:Header>
<wsrm:AckRequested>
<wsrm:Identifier>http://example.com/test</wsrm:Identifier>
</wsrm:AckRequested>
</soap:Header>
</soap:Envelope>
By the way, the section 3.9 describes:
"The RM Destination informs the RM Source of successful message
receipt using a SequenceAcknowledgement header block. The RM Destination
MAY Transmit the SequenceAcknowledgement header block independently or it
MAY include the SequenceAcknowledgement header block on any message
targeted to the AcksTo EPR."
And it is clear the SequenceAcknowledgement can be sent independently.
---
PR Issue 11
---
2.3 Line697 Editorial
"see Section 3.5" should be "see Section 3.8" ?
2.4 Line667 Editorial
"see Section 3.1" seems not appropriate. It should be other appropriate section.
---
PR Issue 12
---
2.5 Line 704-709
The following sentences needs to be refined or requires examples.
" When the RM Source specifies the WS-Addressing anonymous IRI as the
address of the AcksTo EPR, the RM Destination MUST Transmit any
SequenceAcknowledgement headers for the created Sequence in a SOAP envelope
to be Transmitted on the protocol binding-specific channel. Such a channel
is provided by the context of a Received message containing a SOAP envelope
that contains a Sequence header block and/or a AckRequested header block
for that same Sequence identifier."
Maybe some examples help reader understand what it meant.
It is not clear whether the SequenceAcknowledgement must be sent on
*its* back-channel of the underlying transport protocol.
e.g.,
Here is the following scenario:
1.CreateSequence has "Anonymous" value for AcksTo element.
2.RM Source sends a message A with AckRequested on HTTP Request.
3.RM Source sends a message B on HTTP Request.
Question:
In this scenario, does RM Destination have to send Sequence
Acknowledgement for message A on the HTTP Response in 2, but disallow to
send it on HTTP Response in 3?
Or does the spec allow to send it on the HTTP Response in 3?
The spec is not clear about the above scenario. The spec should clarify it.
---
PR Issue 13
---
2.6 Line339-348
It is not clear what the following sentences means:
CreateSequence\AcksTo = wsa:anonymous
Does it mean the SequecenAcknowledgement must be on the HTTP Response
to the original message? If so, it is beyond the WS-Addressing definition,
I believe.
By the way, the spec doesn't allow wsrm:Anonymous to be used in AcksTo.
If the spec doesn't allow wsa:anonymous in AcksTo, then it should be
explicitly described
---
PR Issue 14
---
2.7 Section3.9 and Appendix B
Needs explanation of ws-addressing composability.
It is not clear how ws-addressing/soap request message and response message
maps to AckRequested and SequenceAcknoweldgement message.
---
PR Issue 15
---
2.8 Section3.10
It is not described how you can identify whether the RM destination is
polling a message. This could be in RM policy assertion.
---
--
----------------------------------
Next Generation
Electronic Commerce Promotion Council
( ECOM, Japan)
TEL: 81-3-3436-7568
Hisanao Sugamata
-----------------------------------
This publicly archived list offers a means to provide input to the
OASIS Web Services Reliable Exchange (WS-RX) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: ws-rx-comment-subscribe@lists.oasis-open.org
Unsubscribe: ws-rx-comment-unsubscribe@lists.oasis-open.org
List help: ws-rx-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/ws-rx-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]