[i061] repeat of a formal proposal

[Doug Davis <dug@us.ibm.com>]

All,
  it hasn't made it to the issue
list (marc?) but here's my revised proposal for i061:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200601/msg00145.html

For issue i061, I propose:
After the first paragraph in the SeqAck section (currently section 3.6)
add: 
- - - - - - - - - - - - - 
While this specification discusses the ability to add, or piggy-back, a
Sequence Acknowledgement Header block to a message that is targeted to
the AcksTo EPR, the precise mechanism for determining when any particular
message is targeted, or not, to the AcksTo EPR is out of scope for this
specification. 

Using the WS-Addressing anonymous IRI in the AcksTo EPR may impact implementations.
When the AcksTo EPR contains the anonymous IRI, Sequence Acknowledgements
MUST be sent on the appropriate protocol binding-specific channel. For
example, in the HTTP case, Sequence Acknowledgements would be expected
to flow on the HTTP response flow. It is worth noting that this may result
in new SOAP messages being generated and sent in certain situations. For
example, if on an HTTP request flow the SOAP message contained a wsa:ReplyTo
that didn't use the anonymous IRI, then it is possible that a new SOAP
message may need to flow back on the HTTP response flow for the sole purpose
of carrying a Sequence Acknowledgement. Because the anonymous IRI is a
general purpose IRI that can be used by many concurrent RM Sequences, Sequence
Acknowledgements that are sent to the AcksTo EPR using these protocol binding-specific
channels SHOULD only be sent when it can be determined that the channel
is related to the RM Sequence. For example, Sequence Acknowledgements should
only be piggy-backed on HTTP response flows where the message that was
sent on the HTTP request flow referenced the Sequence in question through
the use of a Sequence or AckRequested Header block.
- - - - - - - - - - - - - 

thanks
-Doug