Mark Baker recently posted this question for us MEST folks: “how does MEST differ from the architectural style that would describe the architecture of Internet based email?” (please note that there is a more recent post entry on MEST, which does not explicitly talk about the confusing-to-some “process message” operation, from the one that Mark used).

The way I see it is that a protocol like SMTP could be used to implement applications around the MEST principles. And why not? It’s based on one-way messaging and it’s extensible through headers allowing composable protocols. The thing is, however, that there aren’t so many protocols out there which make use of the header mechanism to provide various levels of quality of service (e.g. multi-message-interaction security, reliable messaging, or even transactions, etc.). That doesn’t mean that the implementation technology is not adequate. It just means that no one has invested on building the suite of composable infrastructure protocols on top of which application protocols can be written. If we treat SMTP as a transfer protocol, then I don’t see why we couldn’t implement applications around it according to the MEST principles.

The same can be said for HTTP, if it’s treated it as a transfer protocol (not as an application protocol nor as a transport protocol). Its header-based extensibility mechanisms could be used to implement QoS protocols.

But then, we already have a transfer protocol on which the industry has invested and for which QoS infrastructure protocols already exist; it’s called SOAP 🙂

BTW… my apologies to those who are waiting either an email reply or another blog entry on MEST (Udi, I’ll be interested to see what you’ve done when you are over here). I know I promised them but it’s been a crazy time with my move so I haven’t got around it.