OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: PR Issue 12 Anonymous and AcksTo EPR scenarios


PR Issue 12 seems like a subset of PR Issue 8 which we closed with no action as it was about underlying protocol bindings which are out of our scope.

I don't believe we can provide the requested examples below for the same reason. I suggest we close with no action.

If possible it would be nice to recommend not only to follow up with the RSP WG where the protocol bindings are in scope but to answer the question for the scenario below in our response. My proposed answers are inline below.


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?
MG: The spec requires that an Ack be returned for AckRequested. It cannot be specific to the details requested here regarding the underlying transport binding. One would expect the Ack on the HTTP response on 2. The spec does allow for sending an unsolicited Ack on 3 as well.
         Or does the spec allow to send it on the HTTP Response in 3?
MG: Yes.
         The spec is not clear about the above scenario. The spec should clarify it.
MG: Unfortunately we cannot due to our restriction from being explicit about underlying protocol bindings. For concerns of RM over HTTP the WS-I RSP WG is an appropriate forum to discuss this further.

---

-----Original Message-----
From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Thursday, October 19, 2006 12:09 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] PR Issue 8 - 15: [ws-rx-comment] re:Feedbacks to WS-RM Public Review 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]