James Mime4j
  1. James Mime4j
  2. MIME4J-109

Support for MIME Parameter Value and Encoded Word Extensions

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.5
    • Fix Version/s: 0.8.0
    • Component/s: None
    • Labels:
      None

      Description

      See RFC 2231.

      Mime4j should be capable of correctly decoding and encoding these extensions.

      1. rfc2231.patch
        12 kB
        Rustam Aliyev

        Issue Links

          Activity

          Hide
          Rustam Aliyev added a comment -

          Is there any work done on this? I need support for this RFC, so I need to decide whether to write my own patch or just wait. Also, any chances to get it in 0.7?

          Show
          Rustam Aliyev added a comment - Is there any work done on this? I need support for this RFC, so I need to decide whether to write my own patch or just wait. Also, any chances to get it in 0.7?
          Hide
          Oleg Kalnichevski added a comment -

          There are currently no plans to include this feature into 0.7. The best change to get it incorporated sooner is by contributing it to the project.

          Oleg

          Show
          Oleg Kalnichevski added a comment - There are currently no plans to include this feature into 0.7. The best change to get it incorporated sooner is by contributing it to the project. Oleg
          Hide
          Rustam Aliyev added a comment - - edited

          Attached patch adds RFC 2231 implementation against trunk (1087933). It's basically ported JavaMail implementation but was cleaned up.

          Some notes/limitations:

          • Was implemented as a part of org.apache.james.mime4j.field.ContentDispositionFieldImpl and thus applicable only for Content-Disposition parameters. This should be further made abstract to cover Content-Type as well. (not clear whether any other fields should have this)
          • Decoding done inside ContentDispositionFieldImpl. I don't see how this could be taked outside since there could be encoded and not encoded segments of one parameter.
          • This patch does not cover section 5 of RFC (Language specification in Encoded Words)
          • Tested on Java 6, may not be compatible with previous versions.
          Show
          Rustam Aliyev added a comment - - edited Attached patch adds RFC 2231 implementation against trunk (1087933). It's basically ported JavaMail implementation but was cleaned up. Some notes/limitations: Was implemented as a part of org.apache.james.mime4j.field.ContentDispositionFieldImpl and thus applicable only for Content-Disposition parameters. This should be further made abstract to cover Content-Type as well. (not clear whether any other fields should have this) Decoding done inside ContentDispositionFieldImpl. I don't see how this could be taked outside since there could be encoded and not encoded segments of one parameter. This patch does not cover section 5 of RFC (Language specification in Encoded Words) Tested on Java 6, may not be compatible with previous versions.
          Hide
          Oleg Kalnichevski added a comment -

          Folks

          JavaMail source appears to be licensed under multiple licenses: CDDL-1.0, BSD, GPL-2.0, GNU-Classpath

          http://kenai.com/projects/javamail

          This list includes BSD which as far as I understand should be ASLv2 compatible. Nonetheless, I am not sure, though, we could (or should) copy bits of code from JavaMail.

          What do you think?

          Oleg

          Show
          Oleg Kalnichevski added a comment - Folks JavaMail source appears to be licensed under multiple licenses: CDDL-1.0, BSD, GPL-2.0, GNU-Classpath http://kenai.com/projects/javamail This list includes BSD which as far as I understand should be ASLv2 compatible. Nonetheless, I am not sure, though, we could (or should) copy bits of code from JavaMail. What do you think? Oleg
          Hide
          Stefano Bagnara added a comment -

          While I see "BSD" in the licenses list at that page from my knowledge Javamail is distributed only under the GPL+Classpath exception and CDDL licenses. Each source file header says this, and each downloadable artifact I found reports either the CDDL or the GPL license.

          Is there any resource apart the "license" text on kenai that says that source code can be used under the BSD?
          I found this page and a comment from Shannon:
          http://kenai.com/projects/javamail/forums/forum/topics/604-JavaMail-licensing
          ----------------------
          I think you're confused.

          Only parts of this project are licensed under the BSD license. In particular, the demo source code
          is licensed under the BSD license to allow the most flexible reuse.

          The majority of this project is licensed under the CDDL and GPL licenses.
          ----------------------

          I guess we can't accept this patch.

          Show
          Stefano Bagnara added a comment - While I see "BSD" in the licenses list at that page from my knowledge Javamail is distributed only under the GPL+Classpath exception and CDDL licenses. Each source file header says this, and each downloadable artifact I found reports either the CDDL or the GPL license. Is there any resource apart the "license" text on kenai that says that source code can be used under the BSD? I found this page and a comment from Shannon: http://kenai.com/projects/javamail/forums/forum/topics/604-JavaMail-licensing ---------------------- I think you're confused. Only parts of this project are licensed under the BSD license. In particular, the demo source code is licensed under the BSD license to allow the most flexible reuse. The majority of this project is licensed under the CDDL and GPL licenses. ---------------------- I guess we can't accept this patch.
          Hide
          Rustam Aliyev added a comment -

          How much of the code do you need to rewrite for it to be considered as not copied? The logic is really straightforward and there isn't many parts you can change. Is there any kind of best practices for porting code between incompatible licenses?

          Show
          Rustam Aliyev added a comment - How much of the code do you need to rewrite for it to be considered as not copied? The logic is really straightforward and there isn't many parts you can change. Is there any kind of best practices for porting code between incompatible licenses?
          Hide
          Stefano Bagnara added a comment -

          The best practice is "to not port code between incompatible licenses"

          You probably shouldn't have looked at incompatible licensed source code before implementing it. From my understanding even if you refactor every single line your work will be a derivative work and so will have to respect their license. You should forget what you saw in javamail source code and implement from scratch by just reading the RFC.

          I'm sorry for this, but we do this to make sure our users receive what they are looking for (Apache licensed code with no side-effects).

          Show
          Stefano Bagnara added a comment - The best practice is "to not port code between incompatible licenses" You probably shouldn't have looked at incompatible licensed source code before implementing it. From my understanding even if you refactor every single line your work will be a derivative work and so will have to respect their license. You should forget what you saw in javamail source code and implement from scratch by just reading the RFC. I'm sorry for this, but we do this to make sure our users receive what they are looking for (Apache licensed code with no side-effects).
          Hide
          Andrzej Rusin added a comment -

          I saw something like this in the wild:

          Content-Type: application/octet-stream; name==?UTF-8?B?MDAwMDAwNDguUERG?=

          and the name got not parsed in the content-type parameters.

          Is it possible to do something about it? Esp. that RFC 2231 allows that...

          Show
          Andrzej Rusin added a comment - I saw something like this in the wild: Content-Type: application/octet-stream; name==?UTF-8?B?MDAwMDAwNDguUERG?= and the name got not parsed in the content-type parameters. Is it possible to do something about it? Esp. that RFC 2231 allows that...

            People

            • Assignee:
              Markus Wiederkehr
              Reporter:
              Markus Wiederkehr
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development