Re: [wsrm] detailed proposal to remove Message Header from Poll message and to merge MessageHeader and Request elements

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

> It seems that the original reason for keeping in a separate/external 
> header (MessageHeader) elements that could possibly be "reused" from 
> other SOAP extensions(like message ID) does no longer hold, as all 
> elements inside MessageHeader need be under control of the RMP and 
> have very specific meaning for RM.
>
> In that case I have no problem merging MessageHeader with RM Request.
>
> Also OK with the rest of the proposal, except for one more renaming I 
> suggest:
>
> Collapsing MessageHeader into RM:Request emphasizes the term "Request":
> I find the name RM:Request a bit confusing.
> A request usually expects a "response". But RM requirements don't always
> ask for responses such as an Ack.
> Plus, "Request" and "Response" are quite overloaded terms, and when 
> used with an RM meaning, they seem to imply a "binding" with a similar 
> MEP (WSDL), where in fact they should remain orthogonal. An RM:Request 
> could apply to a WSDL "response" as well.
>
> I propose to rename RM:Request into RM:Requirement.
>

Perhaps rename "RM:response" as "RM:Reply" as another alternative, and 
keep RM:Request.

I would prefer to use the RM:MessageHeader name if we do not use request.

> Jacques
>
>
>
> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Friday, February 20, 2004 1:43 PM
> To: wsrm
> Subject: [wsrm] detailed proposal to remove Message Header from Poll
> message and to merge MessageHeader and Request elements
>
>
> Proposal to resolve New issue on need for MessageHeader in Poll Request:
>
> If a poll request is not piggybacked on a reliable message request., it
> does not need a message header. There is no meaning to expiry time for
> the poll request, and there is no need for a message id for the poll
> request itself.
>
> It would simplify the protocol if the poll request message, which is not
> itself piggybacked on a new reliable message request, does not include
> the request header.
>
> In addition, this change would allow the Request header to be merged
> with the MessageHeader, so further simplify the protocol processing.
>
> <JD>I was fine with removing the Message Header from Poll / Ack / Fault,
> but merging MessageHeader with Request is going far beyond that...
> In any case, it seems that we need to keep a "request-response - 
> neutral" element
> to hold values that are common to all reliable messages (expirytime, 
> ID, seqnum)
> Also I thought we had decided to
>
> Detailed Changes Required:
>
> Lines 873 and 874 have the following Sentence:
>
> “
> A RMP MUST include a MessageHeader element in a Reliable Message, a
> PollRequest
> message, an Acknowledgment message, or a Fault message.
> “
>
> Change this to the following:
>
> “
> A sending RMP must include a MessageHeader element in a Reliable message.
> “
>
> lines 900 and 901 state the following:
>
> “
> The RMP MUST include the MessageId element for Reliable Message,
> Acknowledgment
> message, Fault message and PollRequest message.
> “
>
> This needs to be changed to the following:
>
> “
> The sending RMP must include the MessageID element for a reliable 
> message.
> “
>
> Merge the existing section 3.2 into Section 3.1. add the three child
> elements “ack requested”, “DupicateElimination”: and “MessageOrder” at
> the end of the MessageHeader.
>
> Rename the new merged section 3.1 to be “Request Element”
>
> Change all occurences of “Message Header” to “Request Element in the
> entire document.
>
> <JD> Isn't that too much? Isn't that just intended to mean the 
> ReplyPattern element
> will now be included in Request Element (for requests) and Response 
> element (for responses)?
> </JD>
>
> Remove the “InvalidMessageHeader” fault from the tables in section 3.1
> before line 954
>
> Merge the explanatory text after line 1266 in table 18 from the
> InvalidMessageHeader fault into the InvalidRequest fault: as follows:
>
> “
> InvalidRequest -
> This fault is sent when the Request element is wrong or invalid.
> Examples are:
> 1.When any of the mandatory elements such as MessageId, ExpiryTime,
> ReplyPattern are missing
> 2.SOAP:mustUnderstand attribute is missing
> 3.When AckRequested, DuplicateElimination or MessageOrder elements
> appear twice
> 4.SOAP:mustUnderstand attribute is missing
> “
>
> .Change the message format pictures in Section 3 to take MessageHeader
> out of the poll response message.
>
> Change the message format pictures in Section 3 to merge MessageHeader
> and Request element into a new Request element.
>
> Lines 1099 thru 1101 , in the existing section 3.3 state the following:
>
> “
> A sender MUST include the PollRequest element only in the PollRequest
> message as shown in
> the Figure6. The PollRequest message contains two direct child elements
> for SOAP Header
> element. The one is MessageHeader element, and the other is the
> PollRequest element.
> “
>
> change this to the following:
>
> “
> A sender MUST include the PollRequest element only in the PollRequest
> message as shown in
> the Figure6. The PollRequest message contains the PollRequest element.
> “
>
>
>
>
>
>
> -- 
> ----------------------------------------------------
> Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744 Fax: +1 732 774 5133
>
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133