Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[JMAP] [interoperability] support blobId in Email/set create htmlBody + textBody properties #5405

Open
chibenwa opened this issue Feb 20, 2025 · 9 comments
Open

[JMAP] [interoperability] support blobId in Email/set create htmlBody + textBody properties #5405

chibenwa opened this issue Feb 20, 2025 · 9 comments
Assignees
@vttranlina

Comments

@chibenwa
Copy link
Member

CF

Have the option for the front to send an html body that exceeds say 1MB then it sould upload it, then reference it as a blob in its body parts.

We don't address the fact that the HTML is big, we cope with it...

Example:

POST https://jmap.linagora.com/uploads/<accountId>
Content-Type: text/html; charset=UTF-8
<HTML data follows>

=> Would return a blobId

Then in JMAP:

["Email/set", {
    "tempId1" : {
         "htmlBody": [{
              "blobId": "$blobId",
              "type":"text/html",
              "charset":"UTF-8"
            }]
     }
}, "#c0"]

Which is valid but currently not supported by Twake mail. I'm also expecting this to be required for inter-operability....
@vttranlina vttranlina self-assigned this Feb 27, 2025
@vttranlina
Copy link
Member

If we add blobId property in the parent htmlBody :
we face a scenario:
None(partId) and Some(blobId) => We cannot set specificHeaders (which should be retrieved from bodyValues by partId)

Therefore, I suggest moving blobId into bodyValues. It would look like:

          "htmlBody": [
            {
              "partId": "a49d",
              "type": "text/html"
            }
          ],
          "bodyValues": {
            "a49d": {
              "blobId": "$blobId",
              "isTruncated": false,
              "isEncodingProblem": false,
              "header:Specific:asText": "MATCHME"
            }
          }

@chibenwa
Copy link
Member Author

@vttranlina It is not open for design. What does the spec say? Is it allowed?

@chibenwa
Copy link
Member Author

Image

And of course the spec allow for it...

To be clear we should work around the technical difficulties and implement a spec compliance of this. Saying it conflict with part specific headers just look like a bad excuse.

@vttranlina
Copy link
Member

I checked RFC 8621.

The EmailHeader field should be inside EmailBodyPart, not EmailBodyValue as in the current James implementation.

Image

I'll try refactoring to determine if there’s a specific reason or if it's simply a coding mistake.

If successful, placing blobId in htmlBody/textBody (EmailBodyPart), as initially described in the ticket, should be fine.

@vttranlina
Copy link
Member

@vttranlina
Copy link
Member

@chibenwa Do we need to create a ticket for the mobile team?

@chibenwa
Copy link
Member Author

We need to support the old buggy value in addition to the new one during the transition period in order not to create a breaking change.

We also need to create an issue for the mobile team backlog.

@vttranlina
Copy link
Member

Issue for the mobile team backlog.

@vttranlina
Copy link
Member

draft pr:

jira: https://issues.apache.org/jira/browse/JAMES-4117

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vttranlina vttranlina

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@chibenwa @vttranlina