Re: [ws-rx] Concrete proposal for PR021

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

Sections 3.8 and 3.9: Additional
statements of the pattern "The RM [Source | Destination] MUST detect
and process any [*] header blocks that are piggy-backed on another message".

Is this really true? W/o a mU=1 the header can be ignored.
 I understand the sentiment you're trying to get across (the RMD needs
to be prepared for piggy-backed headers) but I'm not really sure there's
anything normative we need to say anything about it beyond what SOAP itself
says.  Technically, the sending endpoint could put any header it wants
in a message (not just piggy-backed RM headers) and those should be treated
no differently.  They may or may not be processed - but if marked
with mU=1 then they must be processed.  I think some non-normative
text might be more approrpriate - something along the lines of: 
  Since the choice of whether or not to piggy-back
RM headers is made by the endpoint sending the message, in order to ensure
optimal and successful processing of RM Sequences, endpoints that receive
RM-related messages should be prepared to process RM Headers that may be
included in any message it receives.

thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com

"Gilbert Pilz" <gpilz@bea.com>

01/05/2007 07:45 PM

To	<ws-rx@lists.oasis-open.org>
cc
Subject	[ws-rx] Concrete proposal for PR021

Attached is the concrete proposal
for point (2) of PR021. There are changes to sections 3.2, 3.8, and 3.9.
Most of the changes are editorial; I put all the material related to piggy-backing
into a common paragraph. The substantive changes consist of:

Section 3.2: Additional sentence concerning which party controls the use of piggy-backing.

Sections 3.8 and 3.9: Additional statements of the pattern "The RM [Source | Destination] MUST detect and process any [*] header blocks that are piggy-backed on another message".

- gp

<<...>> <<...>> [attachment "PR012-case2.pdf" deleted by Doug Davis/Raleigh/IBM] [attachment "PR021-case2-changes.pdf" deleted by Doug Davis/Raleigh/IBM]