[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Removing Security of Attachments from Core Spec
I am increasingly unclear about what importance attaches to being in part 1 (“the core”) or part 2 (the periphery?) because of the increasing complexity introduced by conformance profiles.
Given my current understanding of how this is supposed to work, being in part 1 or part 2 is mainly a clerical matter, but with ramifications on what can be moved along for approval, and when it will be moved along.
What I am really interested in for ebMS 3.0 is a mandatory to implement profile that includes
1. robust security features
2. reliability features
3. interoperable wire formats and transfer protocol(s).
4. convergence with WS-* functionality when that has become available since ebMS 2.0
[Point 4 is is mainly a matter of using the SOAP:body for business data for simple cases, making use of WSS for security, using one or more WS approaches to reliability.]
It now seems that such a profile will be spread over functionality described in part 1 and part 2. I don’t think that ebMS 3.0 will have much b2b utility until the above mandatory to implement profile is agreed upon.
I would have preferred that the mandatory to implement profile for ebMS 3.0 be constructible from the first approved specification. This does not appear likely at present
I don’t follow how the WSS versioning bears on putting something in part 2. If we do these in parallel, I am finding it less obvious why we have a part 1 and a part 2?
I hope to be on the call where you can elaborate a bit.
From: Hamid Ben Malek
I know this has been discussed previously, but I'd like to bring it again on the table for discussion. I am suggesting deferring the security of attachments to Part 2 of the ebMS-3 Specification. The main reason for this is because the security of attachments is formally being part of WSS-1.1, whereas the core part of ebMS-3 spec only supports WSS-1.0. I don’t like the pick-and-choose approach (we can’t just pick one part of another version, but not support the whole version, or have a position between two versions). I understand the importance of security of the attachments for the business, but we can assure the audience that it will be covered in Part 2, which by the way can start before even finishing the core (we can start editing Part 2 in parallel to the Core draft if nobody minds that).