RE: [ebxml-dev] EbMS interopability: Content-type start parameternot mat

["Andy Evett" <AEvett@cleo.com>]

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
>