OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Encapsulation suggestions [Re: [ebxml-msg] Updated requirements listfor your perusal]


I'm not sure you were on the call when #7 was discussed.  A number of issues were raised during that discussion.  For example, many have described the S/MIME features as an older option with interoperability problems (no, I don't have the details).  Much of the requirements in this area should shortly be supported using XML Encryption.  I'm probably forgetting something.

Some time back, the TC voted at the Sun / Commerce One bi-coastal meeting to reject the encapsulation feature as Drummond submitted it.  I seem to remember some specific issues raised about encapsulation such as the semantics of the information carried in the external (not encrypted) SOAP Header.  At least some of the issues mentioned above were also raised during that meeting though the vote may have gone that way due to the late submission of material.

Finally, since the Miami meeting did not have a quorum, we can certainly open the issue again.  I'd suggest postponing that discussion for a little while -- until XML Encryption is a W3C Recommendation and we've considered its impact upon our specification.

We didn't discuss encapsulation in the context of number 26.  We did talk about how HTTP itself already supports (gzip?) compression of the entire message.  If I remember my MIME, individual parts may also be compressed for transfer via email or HTTP.  For myself, I'd worry about the same semantic questions with encapsulation and the many complicating factors introduced if it were used here.  Again, the Miami meeting was the beginning and not the end of a discussion.


Cliff Collins wrote:

I would like to see #7 not pushed to "NO". Maybe I missed discussion on this but I think it is valuable and should be included in an optional section. It's a method that already has at least 3 implementers from the last round of Drummond testing.In addition, I think the encapsulation model should be examined for doing compression (#26). This allows for shrinking the message at the MSH level. Doing things to payloads directly has the same problem SMIME had in MS 2.0. It's unclear whether the BP or the MSH should "undo" the operation when the message is received. Encapsulation also allows for compression and SMIME to be done on the same message and it results in some very nice performance improvements.Cliff

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC