Yes, as editor I made the change as decided by the group.
Now as a member of the group, I am objecting to this change on the
grounds that it violates our v1.1 charter. If we need to revote, then
let's. I know we never change our mind but. . .
Regards,
David.
We agreed to make this change, narrowing the scope
of the existing syncReply attributes.
----- Original Message -----
Sent: Monday, 19 November 2001 12:56
Subject: RE: [ebxml-msg] Re: SyncReply Module
This is a totally new requirement which violates our v1.1
charter. I have no problem with extending the ebXML headers with
namespace qualified elements but now you are talking about extending our spec
for situations where WE are the extension headers to something else.
This is something we might visit for v2.0 but it is FAR BEYOND our v1.1
charter.
- David.
IMO, it is important that it not be
precluded, or else it really isn't
SOAP.
Cheers,
Chris
Rich Salz wrote:
3BF96936.2C49DD0D@zolera.com type="cite">
How can there be SOAP nodes in our path which do not understand MessageHeader? How would it route/forward?
It might treat the ebXML message as opaque data, and use something like the new SOAP-Routing protocol. Something like MH --> "Signing Service" --> "Logging Services" --> MH...
I don't know how important it is to be able to do that. /r$
|