[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - AS4-profile-v1.0-wd20.odt uploaded
I have uploaded a candidate AS4 spec (AS4-profile-v1.0-wd20.odt) from wd19, that implements most of Pim’s recommendations, remaining from Sander’s (in wd19). 1- Compression property with value "true" instead of empty string for XML schema compliance. Did the update that requires the “Compressed” property to have a value (I believe the Example in 3.1 was the main culprit?). Also it seems we never introduced the “Compressed” property used in the example (so I did). 2- MIME type value in property for a compressed attachment required instead of recommended. Done by Sander. 3- Add note that a compressed payload must be in a separate MIME part and not in the SOAP Body Added a simple note in 3.1. 4- In AS4 5.1.8.(a) and 5.1.8.(b), clarify use of receipts with simple SOAP messages, where the SOAP envelope is not in a part with a content identifier, and has no MIME content ID, so here there can be no part identifier. Done by Sander. 5- In AS4 5.1.8.(a) and 5.1.8.(b), note that it is impossible to generate a valid ebBP reception awareness We have to decide what note to be added in 5.1.8 for this. 6- In AS4 5.1.8.(a) and 5.1.8.(b), decide on ebbp:MessagePartIdentifier format for a payload part in SOAP body that is implicitly identified by absence of an "href" attribute as described in ebMS3Core. Should we just require something like a string “soap:body”, for readability? (not done yet) 7- Clarify that an identifier of a payload in the SOAP Body is a stored as an attribute value on the SOAP Body element, not on the contained document root (AS4 interop). Not sure I understand this: the soap Body could have several payload parts actually, and the @id attribute is at the root of each one of these (not on the Body element). See example in Appendix C2 of Core V3. 8- Discuss the format of the identifier (xml:id or wsu:Id). It seems to be @id (not @Id) see examples in core V3. 9- Bad references to SOAP 1.1 instead of 1.2. Done by Sander. 10-Guidelines on values for mpc (message partition channel) attributes. Pullrequests do not have ebMS metadata, so a partner that sends documents to multiple partners using Pull mode must assign them to different channels, unless we want to require support for the "selective pulling" feature of Part 2 in ebMS. Here I think it would be better to add as an optional extra feature (for a Sender), support for sub-channels. We have defined this feature in Part 2 for intermediaries only. We can refer to it as an (optional) extra feature, as it was initially defined for a multi-hop context but can easily be considered in a single hop case here.. See new proposed section 3.5. 11- Support for Two Way MEPs. This is not needed for EDIINT, but in essence allowing an MSH to set the value for RefToMessageId adds minimal complexity to an implementation. It allows AS4 to be used also for SOA-style, request/response interactions. I think Sander addressed this (just as an option) with a simple note. IMPORTANT: regarding support for compression: - The question whether light AS4 clients – in particular “minimal” client - should support compression (meaning also attachments, and msg properties) is still controversial in my view: if we want to “certify” very light clients and devices, I’d be in favor of keeping the “minimal client” conformance level low, i.e. not requiring these features. - So my uploaded draft reflects this option (low bar for “minimal client” conformance level). See the conformance Clause: to be discussed. NOTE: a small issue not fixed yet: the ref to V3 Part 2 is using a different acronym in the ref section ([ebMS3ADV]) than in the body of the spec (ebMSP2) Thanks Jacques From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]