MHonArc v2.5.2 -->
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]
|
Cliff,
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.
thanx,
doug
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