1. I'm not convinced that http/https is the best protocol. I agree
that it's the defacto standard, but if you're going to go through
this, there might be a better way. (Push, in particular, is a problem).
2. Stateless is wonderful, agreed.
3. I agree with JSON over XML, but what about binary data? That is
the weakest part of JSON, in my opinion.
4. I like where you're going with this, but I'm not sure this is the
exact right way to handle it.
5. Agreed.
6. how about SHA-1 hashes of content? Done properly, that would
eliminate any duplicate messages, and could make it very easy to
include other messages. This might also allow content to be
transfered between accounts only once, dropping bandwidth and
speeding delivery.
7. Don't know enough about MIME to comment.
8. According to your comments on this page, you're referring to long
polling. I agree that this use case needs to be addressed, but I'm
not sure that this is the way to do it. Perhaps multiple options here?
9. Good idea, but do you think that stemming/language differences is
going to be a problem? What about other types of content? attachments?
The biggest thing missing from this list is some sort of Public Key
Encryption. Anyway, it looks like a good start.
> 3. I agree with JSON over XML, but what about binary data? That is the weakest part of JSON, in my opinion.
What binary data? All attachments in emails are Base64 encoded. That's what MIME is all about.
> 6. how about SHA-1 hashes of content? Done properly, that would eliminate any duplicate messages, and could make it very easy to include other messages. This might also allow content to be transfered between accounts only once, dropping bandwidth and speeding delivery.
Developers should start to shy away from SHA-1 since it's already started to get broken.
>> 3. ugh. Hadn't realized that. I like IMAP even less, now. (Told you I didn't know much about MIME ;-)
>> 6. I wasn't intending it as a security mechanism, but as a way to know which bits you have and which you don't. Do you think SHA-1 is still a bad idea in that case?
I like IMAP even less, now. (Told you I didn't know much about MIME ;-)
IMAP might do some sort of MIME-handling, but MIME is part of the email spec, not the IMAP spec. Hating IMAP because of MIME is like hating cars because of the invention of the wheel (i.e. thinking that the wheel was invented as part of the production of the initial automobile).
Multipurpose Internet Mail Extensions (MIME) is an
Internet standard that extends the format of e-mail
to support:
* Text in character sets other than ASCII
* Non-text attachments
* Message bodies with multiple parts
* Header information in non-ASCII character sets
MIME is used to say things like 'this block of text is a base64-encoded file attachment, but also to say 'this block of text is encoded with this charset.'
If you use Gmail, try the 'open original message' option on emails that have attachments or multiple text parts on them (or even emails that have both a text and an html version of the content).
Dealing with MIME is part of dealing with emails in general, regardless of if you're interacting with an IMAP server, or composing an email to send to another user on the same mainframe (i.e. just moving files around).
That is a security mechanism. If I can inject a message with a hash that collides with something else in your queue, I can at least prevent you from seeing the original, or potentially spoof a message from someone else.
I know it depends on knowing hashes of other messages in the mailbox, but if the hashes are supposed to persist, that might not be a problem.
Duplicate suppression can be tricky. The overhead may not be worth the benefit, and the risk of message corruption is increased. Besides, if the mail is encrypted by the user, it may not even be feasible to do server-side.
1. I'm not convinced that http/https is the best protocol. I agree that it's the defacto standard, but if you're going to go through this, there might be a better way. (Push, in particular, is a problem).
2. Stateless is wonderful, agreed.
3. I agree with JSON over XML, but what about binary data? That is the weakest part of JSON, in my opinion.
4. I like where you're going with this, but I'm not sure this is the exact right way to handle it.
5. Agreed.
6. how about SHA-1 hashes of content? Done properly, that would eliminate any duplicate messages, and could make it very easy to include other messages. This might also allow content to be transfered between accounts only once, dropping bandwidth and speeding delivery.
7. Don't know enough about MIME to comment.
8. According to your comments on this page, you're referring to long polling. I agree that this use case needs to be addressed, but I'm not sure that this is the way to do it. Perhaps multiple options here?
9. Good idea, but do you think that stemming/language differences is going to be a problem? What about other types of content? attachments?
The biggest thing missing from this list is some sort of Public Key Encryption. Anyway, it looks like a good start.