+1 for not being bug-compatible; a key value of open source impls is sticking to the stds strictly!
Sanjiva. On Mon, 2005-07-18 at 15:20 +0600, Thilina Gunarathne wrote: > Earlier I replied to a incorrect thread...Pls bare with me If you > receive this twice ...... > Hi, > It seems we are going to be *bug-compatible* with WSE3.0 > CTP....Below mentioned is a bug in WSE3.0 in the way it > handles Content- ID's. > > > I'm *-1* on changing the way Axis2 handles content-id's for > the sake of interoperability with WSE...... IMO we should > stick to the standards..... > > > > Following is an extract from " Content-ID and Message-ID > Uniform Resource Locators" RFC specifying how to convert a URL > to a content-id.... > > > A "cid" URL is converted to the corresponding > Content-ID message > header [MIME] by removing the "cid:"; prefix, > converting %hh hex- > escaped characters to their ASCII equivalents and > enclosing the > remaining parts with an angle bracket pair, "<" and > ">". For > example, "mid:[EMAIL PROTECTED]" corresponds to > > Message-ID: <[EMAIL PROTECTED]> > > > According to what I saw in WSE3.0 CTP, it's mime generator is > not doing any of the above mentioned things. They are putting > the raw URL as the content-ID > > Following is a message part captured from WSE CTp... > > > Content-Type: multipart/related; > boundary=--MIMEBoundary632572390051733984; > type="application/xop+xml"; > start="cid:[email protected]";; > start-info="text/xml; charset=utf-8; > > ----MIMEBoundary632572390051733984 > > content-id: cid:[email protected] > > content-type: application/xop+xml; charset=utf-8; > type="text/xml; charset=utf-8"content-transfer-encoding: > binary<soap:Envelope> ...... > <GetChartResult> > <xop:Include > href="cid:[email protected]"/> > </GetChartResult></soap:Envelope> > > ----MIMEBoundary632572390051733984 > > content-id: cid:[email protected] > > > > According to the RFC above should be > > content-id: <[EMAIL PROTECTED]> > > > When it comes to interoperability I feel these are the most > important thigns MTOM implementors have to take care. > > URL to the RFC: > > http://www.ietf.org/rfc/rfc2111.txt > > > Regards, > ~Thilina > > > > > On 7/16/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Thilina, > > well, i ended up fixing geronimo. i've updated the > geronimo jars to > snapshot. (you may need to build them from svn till > they update the > snapshots for maven). If you have any other problems, > let me know. > > thanks, > dims > > On 7/15/05, Davanum Srinivas <[EMAIL PROTECTED]> > wrote: > > Thilina, > > > > best way to do this is to get patches to geronimo. > Could u spend say > > 30 mins and let me know? we need to get geronimo > fixes in ASAP. > > > > -- dims > > > > On 7/15/05, Thilina Gunarathne <[EMAIL PROTECTED]> > wrote: > > > Hi all, > > > Today when i tried to run the MTOM test cases I > found out that they are > > > failing and MTOM is not working :( . I know this > is unavoidable with the > > > changes we are doing to other modules, unless we > have a way to test MTOM. > > > > > > I think it's better If we can come up with a way > to run MTOM test cases > > > whenever we are doing a commit. (For the moment > MTOM test cases have been > > > excluded due to unavailability of JavaMail & > Activation). A separate maven > > > goal, for which we guarantee to the presence of > java mail & activation, will > > > be a fine solution for this. If not we'll > continuously face this problem... > > > > > > Devs, > > > Till we have a mechanism to test MTOM pls be > carefull with ur > > > changes.......Specially OM and Transport > packages.. > > > > > > ~Thilina > > > > > > -- > > > "May the SourcE be with u" > > > http://www.bloglines.com/blog/thilina > > > > > > -- > > Davanum Srinivas -http://blogs.cocoondev.org/dims/ > > > > > -- > Davanum Srinivas -http://blogs.cocoondev.org/dims/ > > > > > -- > > "May the SourcE be with u" > http://www.bloglines.com/blog/thilina > > > > > -- > "May the SourcE be with u" > http://www.bloglines.com/blog/thilina
