The Drummond Group has been
conducting interoperability tests for ebMS2 for 8 years now (which has
included Cleo and Oracle), and as far as my reasearch has shown, we
have no history of this being an interop issue -- at least one that
required any sort of special "consensus item" discussion and resolution.
Sander Fieten wrote:
Hi guys,
there’s a error in the example in section 2.1.2 of the V2 ebMS spec
with regard to the value for Content-id. The example shows the cid
[incorrectly] without the angle brackets (“<“ “>”) in the start
parameter of the Content-Type MIME header field of the multi part. The
Content-Id MIME header of the related part however has the cid enclosed
in brackets.
Should we correct this? It seems that it can lead to confusion (see the
mail below).
Regards,
Sander
------ Forwarded Message
From: Andy Evett <AEvett@cleo.com>
Date: Mon, 5 Oct 2009 15:24:51 +0200
To: Julien R <jurenit.jurenit@gmail.com>,
Michael O'Connell <mike@flame.co.za>,
Sander Fieten <sander@fieten-it.com>
Cc: <ebxml-dev@lists.ebxml.org>
Subject: RE: [ebxml-dev] EbMS interopability: Content-type
start parameternot matching content-id
Hi all,
Cleo chose to follow the example in the ebMS specification. LexiCom
does accept incoming messages with or without the enclosing '<' and
'>' in the start parameter, but for outgoing messages LexiCom will
leave off the enclosing characters.
I do see though that even the ebMS specification itself is inconsistent
as examples in Appendix B show the syntax suggested. If this is
causing interoperability issues, please contact support-ec@cleo.com
and we will look at adding a formatting option.
Regards,
Andy Evett
Cleo Communications
-----Original Message-----
From: Michael O'Connell [mailto:mike@flame.co.za]
Sent: Monday, October 05, 2009 8:08 AM
To: Sander Fieten
Cc: Julien R; ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] EbMS interopability: Content-type start
parameternot matching content-id
Hi Julien, Sander
According to the Content-ID and Message-ID Uniform Resource Locators
Spec http://www.ietf.org/rfc/rfc2392.txt
the use of content-id <> is
defined as:
A "cid" URL is converted to the corresponding Content-ID message
header [MIME] by removing the "cid:" prefix, converting the %
encoded character to their equivalent US-ASCII characters, and
enclosing the remaining parts with an angle bracket pair, "<"
and ">". For example, "cid:foo4%25foo1@bar.net" corresponds to
Content-ID: <foo4%25foo1@bar.net>
Also,
Content-ID: <messagepackage-123@example.com
<mailto:messagepackage-123@example.com>
>
Looks a lot like a MS-Word interpreted paste of a email-like string.
Hence, perhaps, the mailto: attribute?
Regards,
Michael O'Connell
Flame Computing (FMS)
On Mon, 2009-10-05 at 14:39 +0200, Sander Fieten wrote:
> Hi Julien,
>
> I think you’re right about that both the Lexicom product and the
> example in the ebMS v2 specification do not comply with RFC 2387.
The
> cid given as the start id should exactly match the one used in the
> Content-Id MIME header. So in both cases the value of start
parameter
> should be enclosed in “<“ and “>”.
>
> I assume the value “SOAP” is here as an example and was not in the
> real message as “SOAP” does not comply with RFC 822 regarding the
> formatting of message id’s?
>
> Regards,
> Sander
>
>
> On 05/10/2009 14:13, "Julien R" <jurenit.jurenit@gmail.com>
wrote:
>
> Hi all,
>
> We are testing the EbMS product Lexicom (Cleo
communications)
> and found the following issue:
>
> The Content-type start parameter value doesn't exactly
match
> the content-id value: The < and > symbols are not
present in
> the content-id. Example:
>
> Content-Type: multipart/related; type="text/xml";
>
boundary="--------CLEOebXML.Boundary.1253712627668.yradnuoB.LMXbeOELC--------";
start=SOAP
>
> First lines of body:
>
----------CLEOebXML.Boundary.1253712627668.yradnuoB.LMXbeOELC--------
> Content-Id: <SOAP>
> Content-Type: text/xml
>
> We think Lexicom doesn't follow RFC 2387 because the
> content-id and start parameter should match exactly.
>
> We have also checked the EbMS v2.0 specification and it
> contains the following example in section 2.1.2 message
> package:
> Content-Type: multipart/related; type="text/xml";
> boundary="boundaryValue"; start=messagepackage-123@example.com
>
> --boundaryValue
> Content-ID: <messagepackage-123@example.com
> <mailto:messagepackage-123@example.com>
>
>
> Here the start and content-id parameters also do not
match. We
> believe this is a mistake in the EbMS specifications.
Further
> in Appendix B there is an example where the start and
> content-id do match exactly.
>
> I want to know how this should be implemented and how other
> EbMS products implement this.
>
> Best regards,
> Julien
>
------ End of Forwarded Message
|