Welcome, Guest. Please login or register.

Do you support this?

No
5 (27.8%)
Yes, Version 1.1
0 (0%)
Yes, Version 1.2
1 (5.6%)
Yes, Version 1.3
12 (66.7%)

: 18

: [Feature Request] Multipart Message (Draft: V 1.3)  ( 12707 )

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • : 1251
  • Karma: +74/-7
  • bitmessage.ch and timeservice operator
    • AyrAs Homepage
[Feature Request] Multipart Message (Draft: V 1.3)
« : April 10, 2013, 03:32:57 AM »
I request messages to be sent in (some sort of) Multipart fromat.
The Protocol Specification is compatible with the current Message format and integrates into the body part (V1.1-1.2).


Multipart Message Declaration Draft V1.1
This document suggests a simplified MIME multipart Format for the Bitmessage Protocol
It is to be considered a Draft. Anybody may sugest changes and additions to this and it will be included in the declaration.


Message and part declaration
A Message is declared using a one Line Text in the folowing format:


Multipart: -----X-ID_PART-----


Description
ID_PART: string, made of printable ASCII chars. The String must not occur in the message at any part except the part declaration. Maximum Length: 32 Chars
X: number specifying how many Messages Attribute follow this part declaration. Range: 0-99
A Multipart Message must have this as the first line to be declared as multipart. The line is repeated after each Part to mark its end.
Message and part declarations are Case sensitive.
Each part begins with the same line specified in the first line of the message and ends either with the same string (if another Part is folowing) or the end of the message. There is no empty part at the end of the message.
In other words: All Multipart: -----X-ID_PART----- Parts are identical (except for X)


Attribute declaration
After each part declaration the folowing lines may be used to define the part attributes. There must be exactly as many attributes as specified in the part declaration

Content-Type: image/png
Name: lookAtThis.png
Encoding: PLAIN

Description
Content-Type: MIME-String specifying the content type. If it is missing, text/plain is assumed for backwards compatibility.
Name: This string specifies the suggested file name when saving the part to disk. This name can also be used, when referencing to this part inside a message (for example a text/html part may reference to a png image inside the same message). When saving a file the Application should convert this into a valid file name on the specific OS.
Encoding: String, that specifies how the content is encoded. This may either be PLAIN, BASE64 or a user defined value. Minimal Implementation of a client is PLAIN and BASE64. If not specified, PLAIN is assumed. PLAIN is 8-bit raw data, where BASE64 is the Base64 encoding specified in rfc4648 (http://tools.ietf.org/html/rfc4648)
Custom Attributes: A message may have any number of custom attributes.


General Rules for Attributes and Values:
An Atrribute contains only Letters, Numbers and dashes, it is followed by a colon, a space and its Value. Maximum Length of an Attribute (without colon and space) is 32 Chars
A Value can be made of any printable character of the UTF subset. It ends with a Line break. Maximum Length (without Line break) is 1024 Chars.
A Line break must be the same as used withhin message content to avoid confusion of the decoder.


Fallback
While not required, the first part should always have no attributes and therefore be a text-only representation of any html or rich text content, or at least a simple text saying, that this is a multipart-only message and a client upgrade may be required.


Example Message

Multipart: -----0-TROLOLOL-----
Hello this is an example Text you will not even see if you look at this with HTML
Multipart: -----2-TROLOLOL-----
Content-Type: application/octet-stream
Encoding: Plain
Name: multipart.fake
Some random Data
Multipart: -----0-TEST-----
more random data
Multipart: -----3-TROLOLOL-----
Content-Type: text/html
Encoding: Base64
Name: secret.html
WW91IGxvc3QgdGhlIGdhbWUh

In this example, the "TEST" Multipart is considered as part of the data, because "TEST" does notmatches "TROLOLOL" fro the first line.


MMDD V1.2
Requires: 1.1
Draft 1.2 suggests removing the Number from the Multipart splitter and add an empty line after the last Attribute.




MMDD V1.3
Requires: 1.1
Optional: 1.2 (recommended)
Draft 1.3 Suggests using encodingType 3 for multipart which is currently undefined. It brings the advantage for clients to identify Multipart Messages easily without watching for the first line in the body. But it also removes the Text-only fallback suggested in 1.1
« : May 24, 2013, 07:01:08 AM AyrA »
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

Ruhe

Re: [Feature Request] Multipart Message
« #1 : April 10, 2013, 07:27:38 AM »
Even if I currently don't know if I need richtext at all (100% of all my E-Mails are pure plain-text), a very good and professional posting!

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • : 1251
  • Karma: +74/-7
  • bitmessage.ch and timeservice operator
    • AyrAs Homepage
Re: [Feature Request] Multipart Message
« #2 : April 10, 2013, 07:48:41 AM »
"Rich Text" is a bit misleading because it refers to http://en.wikipedia.org/wiki/Rich_Text_Format which is something different. What BitMessage does is HTML.
The Text should be changed to "view as HTML" or "view as formatted Text" or users will globally start using the wrong term.
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

SkyN

  • Newbie
  • *
  • : 25
  • Karma: +2/-0
Re: [Feature Request] Multipart Message
« #3 : April 10, 2013, 02:58:33 PM »
it is necessary, but may not be reinventing the wheel http://en.wikipedia.org/wiki/MIME

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • : 1251
  • Karma: +74/-7
  • bitmessage.ch and timeservice operator
    • AyrAs Homepage
Re: [Feature Request] Multipart Message
« #4 : April 10, 2013, 03:49:25 PM »
it is necessary, but may not be reinventing the wheel
I am aware of it but do not want the full specification because it just contains too much overhead. MIME was developed for 7 bit ASCII so all of its encodings are not needed in bitmessage. For a proper MIME implementation you can start read the 20 RFC files now. Things like UTF8 and 8 bit transfer need to be specified for each part if you want to use it proper in bitmessage. MIME requires you to encode binary data in base64 if you want to follow the standard.
If you now think we could just ignore these few things for bitmessage you gonna have a bad time because then you need to write the MIME component completely by yourself because you wont probably find a good small MIME component that ignores the standard.
If you have to write it yourself you also can define a standard which exactly fits your needs and doesnt suffers from overhead you don't need. My standard draft is similar to MIME on purpose because it is halfway readable and understandable by standard users.

My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

Atheros

  • Lead Bitmessage developer
  • Administrator
  • Sr. Member
  • *****
  • : 381
  • Karma: +57/-3
Re: [Feature Request] Multipart Message
« #5 : April 10, 2013, 04:39:58 PM »
Plain data can contain line break characters so that wouldn't work by itself. It could be prepended with a var_int denoting the length perhaps.

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • : 1251
  • Karma: +74/-7
  • bitmessage.ch and timeservice operator
    • AyrAs Homepage
Re: [Feature Request] Multipart Message
« #6 : April 10, 2013, 06:29:27 PM »
The specification in the draft does not gets messed up, when a text contains line breaks because a part splitter contains a number specifying the number of tags, so there is no confusion between a tag and plain text. The Length of a part can be calculated by counting the bytes between two splitters. The only exception is the last part. it runs until the end of the message. This can be calculated with the message length specified already in the current release of the client.
This custom MIME draft works completely without the declaration of any length or part size because it is not required and can be abused to confuse clients, crash them or make them execute viruses.
« : April 10, 2013, 06:33:20 PM AyrA »
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

Atheros

  • Lead Bitmessage developer
  • Administrator
  • Sr. Member
  • *****
  • : 381
  • Karma: +57/-3
Re: [Feature Request] Multipart Message
« #7 : April 11, 2013, 12:24:05 PM »
The specification in the draft does not gets messed up, when a text contains line breaks because a part splitter contains a number specifying the number of tags, so there is no confusion between a tag and plain text.

That doesn't make any sense.

Atheros

  • Lead Bitmessage developer
  • Administrator
  • Sr. Member
  • *****
  • : 381
  • Karma: +57/-3
Re: [Feature Request] Multipart Message
« #8 : April 11, 2013, 12:29:41 PM »
Also your specification contradicted itself by saying that "A Value can be made of any printable character of the UTF and UNICODE subset. It ends with a Line break" but that "PLAIN is 8-bit raw data".

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • : 1251
  • Karma: +74/-7
  • bitmessage.ch and timeservice operator
    • AyrAs Homepage
Re: [Feature Request] Multipart Message
« #9 : April 11, 2013, 02:25:29 PM »
"value" refers to a value of a header and not the content it describes. The content itself can be raw 8 bit binary. the encoding (plain, base64) describes the content. since UTF-8 and Unicode use both the full 8 bit spectrum of a byte, there is no difference between a raw image and a text. if you want we could also define "BINARY" as an encoding, but the content type tells already if it is some sort of text or if it is binary data.
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

Atheros

  • Lead Bitmessage developer
  • Administrator
  • Sr. Member
  • *****
  • : 381
  • Karma: +57/-3
Re: [Feature Request] Multipart Message
« #10 : April 11, 2013, 02:35:26 PM »
Ok, So how do we know when the binary data ends?

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • : 1251
  • Karma: +74/-7
  • bitmessage.ch and timeservice operator
    • AyrAs Homepage
Re: [Feature Request] Multipart Message
« #11 : April 11, 2013, 04:33:12 PM »
it ends either at the end of the message or at the next multipart boundary, depending on what comes first. This is also the reason you can specify the string inside the first line of the multipart message, so you can choose one that does not occurs inside any binary data. It may actually occur, but should not be able to be a valid multipart data, so just because the string "TEST" is included anywhere in the message it is not forbidden to take, except you would cause any intentional parts with it. (this is why I propose the five dashes at the beginning because it is very unlikely to have exaclty this string on a single Line (including the "Multipart:" string)
« : April 11, 2013, 04:37:22 PM AyrA »
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • : 1251
  • Karma: +74/-7
  • bitmessage.ch and timeservice operator
    • AyrAs Homepage
Re: [Feature Request] Multipart Message
« #12 : April 11, 2013, 04:40:18 PM »
Let me give you an example:


Multipart: -----0-TROLOLOL-----
Hello this is an example Text you will not even see if you look at this with HTML
Multipart: -----2-TROLOLOL-----
Content-Type: application/octet-stream
Encoding: Plain
Multipart: -----0-TEST-----
Hello
Multipart: -----3-TROLOLOL-----
Content-Type: text/plain
Encoding: Base64
Name: secret.txt
WW91IGxvc3QgdGhlIGdhbWUh

The message contains a binary data object, that contains a valid Multipart block, but since the string in the part definition does not matches the string in this block it will not be mistaken as a part splitter.
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • : 1251
  • Karma: +74/-7
  • bitmessage.ch and timeservice operator
    • AyrAs Homepage
Re: [Feature Request] Multipart Message
« #13 : April 12, 2013, 07:28:49 AM »
The Draft has ben lifted from 1.0 to 1.1

Changes:
- Adding of length restriction for Multipart splitter Headers and their values.
- Changed the Example to show how wrong parts are avoided.
- Replaced 1.0 with 1.1 in the Version tag
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

Atheros

  • Lead Bitmessage developer
  • Administrator
  • Sr. Member
  • *****
  • : 381
  • Karma: +57/-3
Re: [Feature Request] Multipart Message (Draft: V 1.1)
« #14 : April 12, 2013, 04:59:20 PM »
Ok. That makes sense. Thank you.

Why is there a text/html content type? Wouldn't this be exactly the same thing as application/octet-stream if the data is text/html data?

How do we send a basic message that will show up in the UI as a normal message (possibly with attachments)?

What is the point of the integer inside the part declarations? That integer makes it more difficult to scan the text looking for the next part declaration marker.