Next in thread →
Next in month →
RE: [ebxml-msg] Comments on Working Draft 06
Ric: -----Original Message----- From: Ric Emery [mailto:] Sent: Tuesday, November 15, 2005 1:39 PM To: Subject: [ebxml-msg] Comments on Working Draft 06 Here are a few minor editorial comments on Working Draft 06 701-702: 'In particular, this specification requires that header blocks supporting message reliability and security be understood by an MSH.' I am a bit uncomfortable with the word 'requires'. It gives me the feeling that it is required that an MSH implementation must support multiple Reliability Module specifications. <JD> agree: I think we need to work in parallel on a comprehensive Conformance section that would spell out what is required and what is not. So the main body of the spec should not have to make such meta-statements. Even keywords like MUST, SHOULD, MAY should only be used where we are sure they will not conflict with possible conformance profiles. 844 - ' ebXML Messaging 3.0 does not define any extension elements for a SOAP Body' Is this necessary to say? If extension elements were defined we should point that out. Why point out the absence of defined extensions? <JD> I guess that was to underline the contrast with ebMS2... But just the title of this small section is confusing. Maybe we can remove 4.1.3.6 and put back this sentence in previous section? 1201-1202 - 'If a CPA is referred to by the eb:AgreementRef, the number of conversations related to this CPA must comply with CPA requirements. The value of eb:ConversationID MUST uniquely identify a conversation within the context of this CPA'. Good information, but i am not sure it belongs here. Seems to me that since CPAs are not required the CPA related implementation details may not belong. Though I could be convinced otherwise. <JD> Right. It is more a matter of compliance of an implementation to this referred CPA than to ebMS spec. Agre to remove. 1266 - 'of the purpose or intent of the message' Should the word 'message' be modified to 'payload'? <JD> yes. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Next in thread →
Next in month →