Hello Dennis,
i have created https://issues.apache.org/jira/browse/CXF-7857 to better
track this is in the release notes. Could you remove the fix-version 3.2.7
and 3.1.17 from CXF-7317?
Cheers,
Thomas
--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Nevermind, I see it's already backmerged.
Colm.
On Fri, Sep 28, 2018 at 3:44 PM Colm O hEigeartaigh
wrote:
> Hi Dennis,
>
> I want to call a vote on 3.1.x today if possible - can you backmerge this
> fix?
>
> Colm.
>
> On Fri, Sep 28, 2018 at 12:39 PM Dennis Kieselhorst
> wrote:
>
>> > I
Hi Dennis,
I want to call a vote on 3.1.x today if possible - can you backmerge this
fix?
Colm.
On Fri, Sep 28, 2018 at 12:39 PM Dennis Kieselhorst wrote:
> > I think the problem is the example in the specification, which do not
> comply
> > to this definition. But this is already covered
Hello Dennis,
thank you for this.
Do you know detail about the release date of CXF 3.2.7?
Just a small formal thing: Does it make sense to have a explicit issue for
this rollback to make this more transparent in the release notes of CXF
3.2.7 that this issue was rolled back?
Thank you,
Kind
> I think the problem is the example in the specification, which do not comply
> to this definition. But this is already covered since year 2000 *by a errata
> for RFC-2392*
> https://www.rfc-editor.org/errata/rfc2392
>
> This errata contain the correct example that comply with the text:
>
>
>
Hi Dennis and Thomas,
I'm having the same problem. I get the exception on receivers side
/No attachment found for content ID
'91cc49c9-18ff-4542-9347-1f2ee0478589-1@urn:ihe:iti:xds-b:2007'/
I figured out, that the received message contains the following attachement
id
Hello Dennis,
i will try to explain my interpretation.
The important sentence in RFC-2392 is:
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 especially
Hi Thomas!
> Now the question: What is correct and why? From my understanding the fix with
> CXF-7317 was wrong and violates rfc2392.
> But maybe someone else could clarify this why CXF-7317 is still ok.
Can you elaborate a bit more on your interpretation of RFC 2392?
There is an example in the