I also agree that we should remove the requirement that all messages
be encapsulated in a MIME multipart/related "envelope". We left this
in from the early days.
In cases where there is no payload, then there probably should be
only the SOAP:Envelope with a MIME media-type consistent with the
SOAP 1.1 spec (for now) which would be "text/xml" (with which I
have major heartburn, but that's what SOAP1.1 says, so we work with
what we have at the moment).
"application/xml" or even more suitably application/soap+xml would
be preferable IMO (see recent posting from Murata-san on xml-dist-app)
so as to be consistent with RFC3023 (and with 2048 before that).
Cheers,
Chris
David Fischer wrote:
>
> Good point, I agree. In the case of zero payloads, there is no multipart.
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> Sent: Friday, September 14, 2001 10:11 PM
> To: ebxml-msg@lists.oasis-open.org
> Subject: Use of MIME multipart for zero payload containers
>
> The MS spec seems to say that an ebXML message is always represented
> as a MIME multipart/related entity. There does not seem to be an
> exception for the case where there are zero payload containers: in
> such a case it looks like an ebXML message MUST be expressed as a MIME
> multipart with only one part. Is that right?
>
> I mention this because I was looking at Sun's JAXM EA2 implementation,
> and it seems to have logic saying that if it finds itself generating a
> SOAP-with-attachments message with zero attachments, it uses the
> original SOAP format, which does not use MIME multipart. This means
> that if you asked it to generate an ebXML message for which there are
> no payload containers, what it would generate would not be ebXML MS
> compliant.
>
> I brought this up with the JAXM group and got this response:
>
> Date: Fri, 14 Sep 2001 15:04:12 -0700
> From: Nicholas Kassem <nick.kassem@sun.com>
>
> Dan,
>
> Once again thanks for your input. I believe I now understand your point. In
> the JAXM context I don't think we will gain much by dwelling on the
> *interpretation* of the numerous relevant specs. The key issue is what is
> the canonical form of an ebXML 1.0 message in cases where there is only one
> part in a multipart/related message. Your contention is that the presence
> of an empty attachment (equivalent to no ebXML payload) may lead to
> interoperability problems. I'm not convinced, but be that as it may. So, we
> will include a facility in JAXM to *explicitly* use multipart/related
> packaging even in cases where it is logically redundant. Hope this helps.
>
> Nick
>
> -- Dan
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>