Closing Rel39

["iwasa" <kiwasa@jp.fujitsu.com>]

I believe Rel39 should be closed, since
this resolution was updated in the spec WD0.52 
at Section 3.1.5 at the F2F meeting in September.

Thanks,

Iwasa

--
REL-39 Spec 3.2.2 feature Design Accepted  Tom Rutt 
Title: ReplyTo 
Description: 
Why is it mandatory even if callback ack binding 
pattern is not in use?
Proposal is to make cardinality of the element 0 or 1 
rather than current 1. When discussing callback ack 
pattern, this element would be required (in text, not the 
schema). Current proposal does not match this description, 
covering only the first part. Current proposal also too wordy. 
ACTION ITEM to Tom: Update the proposal to cover both 
parts of agreement and to remove wordiness.

29 Jul 2003: Tom sent out an email attempting to resolve 
this issue in terms of acknowledgement MEP (ack pattern). 
Sunil raised issue about that ReplyTo is also used for faults. 
Tom wants to describe the binding pattern as applying to 
both acknowledgement and faults. Note: Must recognise 
that "fault" in this context is specifically about RM faults 
and does not change SOAP or underlying protocol behaviour.

In this meeting, Sunil worked to distinguish the RM ack 
pattern from the application MEP. For example, using one 
way MEP can only use acknowledgement or response 
pattern. General agreement that RM faults should be 
handled using the same pattern as an acknowledgement, 
if an acknowledgement had been requested.

General agreement that organizationally ReplyTo and 
AckPattern are related.

General agreement RM faults should be handled as specified
in the AckPattern element (and therefore AckPattern is 
orthogonal to AckRequested and deserves a new name).
Decouple AckPattern from AckRequested element
Rename AckPattern to Binding pattern
Couple BindingPattern and ReplyTo "organizationally"

Tom will update the words in his emails to reflect this 
update. Scott and Sunil will be included in a first pass 
at reviewing this text.

12 Aug 2003: Discuss Sunil's email. Solves question of 
how to decouple replying from particular reliability level
 
Proposal: 
Clarify definition:

3.2.2. ReplyTo Element
This OPTIONAL element is used to specify a different 
endpoint than the initial sender to reply to with an 
Acknowledgment or Fault Message. Higher level 
addressing or routing schemes MAY supercede the 
value of the From element when ReplyTo is not used 
to indicate the endpoint to receive an Acknowledgment 
or Fault Message. Higher level addressing or routing 
schemes MUST NOT supercede the value of the 
ReplyTo element when it is used.
The value of this element MUST be a URI as defined 
in [RFC 2396].

12 Aug 2003: See proposal in recent email with friendly 
amendment to delete "It is REQUIRED for guaranteeing 
message delivery. However this element MUST NOT 
appear in a non-Reliable Message."

Addendum 9-16

3.2.2 RMReplyPattern Element Change:

Original
Response : An Acknowledgment Message (or RM Fault 
message) MUST be sent back directly in the Reply to 
the Reliable Message. This pattern is not applicable for 
one-way application level MEP
Callback: An Acknowledgment Message (or RM Fault 
message) MUST be sent as a callback request, using 
the address in the ReplyTo element
Poll: An Acknowledgement Message(or RM Fault message) 
MUST be sent as a response to a poll request 

New
Response : Any Acknowledgment or RM Fault message 
the receiver needs to send in reply to this message (any 
message generated by the receiving RMP with RefToGroupID 
and RefToSequenceNo equal to the value of this message's 
GroupID and SequenceNumber, respectively) MUST be 
sent back directly in the Reply to the Reliable Message. 
This pattern is not applicable for one-way application 
level MEP.
Callback: Any Acknowledgment or RM Fault message the 
receiver needs to send in reply to this message MUST be 
sent as a callback request, using the address in the ReplyTo 
element.
Poll: Any Acknowledgment or RM Fault message the receiver 
needs to send in reply to this message MUST be sent as a 
response to a poll request. 
 
Resolution: Updated proposal carried with specified amendment. 
--