Tom Rutt wrote:
> Sunil Kunisetty wrote:
>
> >>
> >>
> >> <JD> I understand that this messageHeader serves a purpose in Responses,
> >> but still that seems quite contrived: we apparently use it only for
> >> matching
> >> the ReplyPattern elements between req and resp.
> >> I believe our design would be tighter if we added the returned
> >> ReplyPattern
> >> to the RM:Response element, as Sunil hints at as a possible alternative.
> >>
> > +1 ;-)
>
> I take this to mean that you, Sunil, have no problems with the reply not
> having its own message ID.
Yes, that's correct.
>
>
> If such is the case, an alternative to putting the reply pattern in the
> respons is to have a separate header element
> defined for a poll response. This new heeader could have a schema to
> convey fault info as well as a list of delivered messag ids.
>
I don't think we need a different Header element, a simple optional attribute
would suffice.
>
> >>
> >> Further, I believe the ReplyPattern element in a request, would be
> >> more at its
> >> place in the RM:Request element, as it should be associated with the
> >> element
> >> that has "request semantics".
> >
> > +1
> >
> >>
> >> Doing so, the MessageHeader element would only contain ID and general
> >> message info,
> >> and would only need be included in "reliable messages", as
> >> the second sentence in 3.1. clearly suggests already (at odds with
> >> current usage).
> >> Later on when we have RM:Response piggybacking on business messages,
> >> the info in
> >> messageHeader would be totally orthogonal to the info in RM:Response.
> >>
> >> jacques
> >>
> >>
>
> --
> ----------------------------------------------------
> Tom Rutt email: ;
> Tel: +1 732 801 5744 Fax: +1 732 774 5133
