[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Use of MIME multipart for zero payload containers
I agree also. I've added it to the change list. This is a worthwhile clarification/simplification. David -----Original Message----- From: christopher ferris [mailto:chris.ferris@Sun.COM] Sent: Monday, September 17, 2001 8:16 AM To: David Fischer Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org Subject: Re: Use of MIME multipart for zero payload containers 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> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC