Re: Use of MIME multipart for zero payload containers

[christopher ferris <chris.ferris@Sun.COM>]

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>