Edward,
Sounds to me you have three technologies:
- XML structure for Web EMAIL representation (EXML)
- CLAIM: covers all client/server I/O requirements
(I saw where this is not the case, but thats
besides the point just to say I wouldn't go
to far to say it does)
- A DOM XHR SMTP-client component (XHR-SMTP)
- CLAIM: Allows replacement of existing web mail
interfaces.
- A SMTP server extension to handle XHR-SMTP transactions
and/or payloads with EXML content.
When augmented or integrated, you have the SAFE proposal.
If this is the understanding, I still don't see what problem it
resolves other than allowing for the design of pure SMTP browser based
clients.
The technology advancement here is XHR-SMTP to allow browser agents to
act as smtp clients. If so, this can be done today with a browser plugin.
Overall, your concern is that non-SMTP based web mail applications are
insecure. If so, I don't agree with that. Any system offering a web
mail interface is not design prohibited in interfacing with their
backend. These tend to be locked in and proprietary for good reason.
In fact, a XHR-SMTP would open the door to potential abuse. No
different than attempting to hack into proprietary system, but with
XHR-SMTP in place, the target market is wider to single source an attack.
That said, I think that if your broke up the proposal, it might be
worth considering. But I also think that you need to get away from
claims it will save any real problem. I don't see that.
XHR-SMTP can be generalized and not depend on EXML or the SMTP
extension. That would be a plus I think. EXML can be a plus too as it
be applied in existing interfaces with AJAX or JSON/P approach.
--
Sincerely
Hector Santos
http://www.santronics.com
Cheney, Edward A SSG RES USAR USARC wrote:
Hector,
For people who have been in the mail business for a very long time,
that is a pretty broad claim.
It is a broad claim. I have seen several different attempts at creating
a markup language for email, but none that fully function and support
the complexity of SMTP protocol compared to the simplicity of the HTTP
protocol. Such support would require conventions in an document capable
of supporting multiple various authors uniquely such as an email thread
without data cross-contamination from multiple contributions upon that
document. SGML/XML do not provide this capability.
When I was searching for prior art I found attempts at creating markup
languages that made some progress towards defining content, but rarely
did they make any attempt to absorb RFC 5322 definitions into structures
represented by their language. I never saw any of these prior arts
solve the problem of the prior paragraph. Most of the concepts
represented of my language are not original, even the name of the
language is not original, but still I had never seen anything that
provided the benfits of markup to represent all currently practiced
user-agent conventions of email.
So while there have been attempts at creating markup language for email
in the past none were either functional or solved the complexity of
challenges represented by email that do not exist for the web. That
does not mean my language is the best for the job, and I have never
claimed that it is. Until something else comes along with its own
unique solutions to common practices the language I wrote is the only
thing I would refer to as a full markup language for email where all the
prior attempts I have seen do not do the full job of the task.
The only one thing I am absolutely certain about is that there is no
standard for describing content in email. The closest such thing is a
suggestive statement from RFC 822, which suggests that content be 7bit
ANSI characters like the rest of the document. There is certainly no
standard for use of whitespace definitions for visually preformatting
content in emails for processing to user-agents, no standard for shoving
HTML into an email, no markup language standard, or anything else. I do
feel fairly confident that if there were a fully functional markup
language that it would have some appeal commerically and so its
existance would be commonly evident even if not in use.
From these conclusions and the hundreds of hours I spent doing research
over the more than 18 months I took to actually write the language I
feel pretty confident when I say my language is the first markup
language for email. I may honestly be wrong this statement, but I don't
think so. My language may not be the best choice for its job, but at
the moment its the only choice. I would say if my language is of poor
quality or fails at its job then pick another, but nobody else has
volunteered their own personal time away from work or family to write
such a thing. I don't believe my language should rest as the only one
of its kind and I hope that I may see some alternatives. It is only
from competing alternatives that I may truly know how flawed my attempt
is.
A JSON format could be considered more optimized for wire-data, and
this does exist and done after a XML version was tested and pushed
aside.
JSON is not a markup language or peer to XML, although a famed
client-side evangelist I know of commonly claims otherwise. JSON is a
serialized data storage mechanism and nothing more. XML is a
meta-language, which is a language for creating languages. XML is
commonly misused to act as a human readable data storage mechanism, but
in my opinion that is a gross abuse of the technology in complete
defiance of its purpose. JSON is not competition for XML and people who
evangelize such likely do not understand what XML is. JSON is in
competition with comma separated value format, but not XML. As a result
it is a poorly informed response to a bad practice that allows for this
reasoning of interchangability of JSON for XML.
In short, there is nothing new here.
You may be entirely correct. The language I created does contain some
patent pending features, so perhaps in three to five years after the
US Patent and Trademark office concludes an investigation we will know
for sure.
Thank you,
Austin