=================
Note: Currently Open Email Metadata is explorative, incomplete and has no existing implementations.
Send your emails with attached metadata so recipients can create complex behaviours such as displaying notifications, integration and search. Let's make email semantic!
===
These are some things that are very possible if Open Email Metadata is adopted today:
- get notified of when a product will be delivered and when it is dispatched
- get cross platform desktop and mobile notifications, tailored to whatever device you are on
- take back control over your notifications
- subscribe and unsubscribe to email newsletters from one interface
- set up complex rules to react to different situations
- get notified when someone replies to your forum or blog posts
- receive notifications of what you bought, how much it cost
- …and much more!
If you operate a service, why should you use OEM?
- make your emails more useful - your emails will be useable in ways you never imagined
- you will automatically support any new services and applications that spring up from supporting a given OEMS.
- send emails that customers are more likely to engage with
- add uniqueness and added value to your services at little effort on your part
- send bills, updates to your ToS by emails
===
Open Email Metadata is conceptually simple. When you create an email with your service, you append one or more attachments that conforms with the following OpenEmailMetadata standards. This ensures that any receipients will be able to interpret the data and act upon it.
- Your email has a
multipart/alternativepart. - Metadata is attached as a MIME attachment.
- The metadata MUST be attached as application/json. (OEMFormat Identification needs clarifying)
===
The following are some early metadata formats. OEM does not define how the following formats be used - it is completely up to the consumer to decide.
This is a very basic itemised receipt that assumes a fixed currency and tax included per-item.
{
currency: "GBP", /* iso4217 code */
items: [
{name: "Widget", quantity: 2, price: 100 },
{name: "Foo", quantity: 2, price: 50 },
{name: "First Class Delivery", quantity: 1, price: 8 }
],
total: 308
}
Considerations:
- tax
- item description
- Specify an expected delivery date in
dateFormatformat.
{
expected: {
date: ["23/12/2012", "24/12/2012"]
}
}
- Specify a dispatch date in
dateFormatformat:
{
dispatched: {
date: ["23/12/2012", "24/12/2012"]
}
}
- Specify the date the terms of service has been updated.
termsOfService: {
updated: "15/11/2012",
needsAccepting: true,
url: "http://website.oem/terms"
}
- Notification that you have received a reply.
reply: {
name: "",
url: "",
replee: ""
}
- Receive a bill.
bill: {
amount: 300,
currency: "GBP",
status: "paid"
}
// todo
// todo
===
In the above examples, there is no links between metadata where it would be beneficial for there to be. It is undecided how this could be implemented. There are no standard mechanisms in JSON that support linkage between JSON. There are a number of opportunities available:
- Require producers of metadata give a unique identifier (IRI)
- Use a known attempt at linking JSON metadata HAL, JSON-LD, JSON Reference
For example, an Itemised Receipt might want to refer to a Bill and vice versa. An Invitation and Reply may wish to refer to an individual or organisation in a consistent way. This is a case where XML lends itself well such as with Friend of a Friend. (See OEM Serialization)
- What if a user has not received an email with an existing ID?
- Forces a client to keep a record of previous metdata. No longer idempotent.
- Would they be able to re-fetch it? The IRIs could also be re-retrievable but this goes outside the intent of this standard.
===
There are hopes to support application/xml and application/x-www-form-urlencoded but this will have to wait until there is an obvious way to serialiser metadata to all three formats that is not serialiser dependent. For example, there are multiple ways to encode arrays in application/x-www-form-urlencoded and conversions between XML and JSON.
This remains to be seen.
Content-Typeparameters.- MIME Custom headers
- Envelopes
Clients tend to ignore multipart/alterantive emails if they do not support the Content-Type. This allows the OEM to be invisible to clients that do not support OEM.
===
You are completely free to use the established formats above in any way you can imagine but you'll need a way to read the above data.
- node.js: Use emailjs to send emails. Use node-imap and mailparser to fetch and read emails.
- php: Use swiftmailer to send OEM. Horde IMAP to read.
===
The clientside framework is a standard application that runs on a user's machine and handles OEM. This application is extensible and decides what to do with the OEM that is received. This is effectively mailcap for OEM.
- Plugins and programs are written to interpret the OEM in different ways. (See the examples list.)
- Some applications might want to send your OEM to third party services, such as a recommendation website that collects your preferences over time. Users decide who to send OEM to.
- Where do you process OEM?
- Integration with the mail client
- Could be hosted in and run within the email client. (Too client dependent.) Thunderbird, Outlook plugins that automatically extract OEM from emails.
- Could run as a separate process with a standard API.
- An application that executes a given program or script for a given OEM. Acts a registry for each OEM handler.
- Some features make sense in the email client and others in a separate process.
- Mail Proxy that intercepts OEM.
- Standalone
- Could be web based to take advantage of the web ecosystem. (Do people want to run a complete web stack?)
- Basic OEM utility that checks emails and extracts data and does not integrate with the email client.
===
What possibilities might OEM give rise to?
Whenever you receive a bill, your accounting software adds the item to your records.
Game lobby software that uses your email identity to set up planned online games.
Your shopping software lets you track all your purchases from different companies from one place and lets you know when everything will arrive.
Use multiple social networks from the same interface.
See all your recommendations from different vendors in one place.
Ask your email more meaningful questions.