MmsAttachment::content could be either a text or a blob

[vicamo]

Recently Mozilla has issues (bug 883017, bug 880648) regarding text encodings of MMS attachments. By W3C File API, a Blob has only mime type and no further information like text encoding available. The API client may not decode that blob correctly without these detailed parameters, and the API implementation may not encode that MMS PDU with all necessary parameters for message inter-change as well.

To solve text encoding problem with minimum work, we may allow MmsAttachment::content to be either a text or a blob:

1. when API client sets MmsAttachment::content to a text, the underlying implementation may choose an appropriate charset for text encoding and carry that chosen charset in the encoded PDU,
2. when API implementation receives a PDU and finds some attachments are of text mime types, the implementation decodes these attachments to a string rather than a blob.

[airpingu]

Hi,

Just helping clarify what Vicamo is going to do. The current MMS attachment is defined as below:

dictionary MmsAttachment { DOMString? id; DOMString? location; nsIDOMBlob content; // If the content blob is a "text/*" type, the encoding for text should always be "utf-8". };

We're hoping to change it to:

dictionary MmsAttachment { DOMString? id; DOMString? location; jsval content; // Can be nsIDOMBlob or DOMString. };

---

I have one concern on this. What's happening if the clients still want to assign the |content| with a "text/*" MIME type blob? The API implementation would still face the same issue of not knowing the encoding of the text blob. Right? I don't think this issue can be perfectly solved by this new design. I'd suggest another design as below:

dictionary MmsAttachment { DOMString? id; DOMString? location; DOMString? encoding; nsIDOMBlob content; };

This design exposes an |encoding| parameter to let the client have a more flexible way to specify the encoding of the content blob no matter it's a "text/*" MIME type or not.

What do you think?

Gene

[efullea]

Why cannot we specify the encoding as part of Blob's content-type attribute? See how the definition of this attribute in [1] points to [2] and this RFC provides the following example: Content-Type: text/html; charset=ISO-8859-4
[1] http://www.w3.org/TR/FileAPI/#dfn-contentTypeBlob [2] http://tools.ietf.org/html/rfc2616#page-124

[vicamo]

Oops! Just don't know that's allowed. Thank you. :)