On 8/26/20 7:07 PM, Ashley Dixon wrote:
I meant (a), in the sense that you should probably write it up
in a more presentable fashion than a GitHub README page. You might
want to nicely typeset it in TeX or something to make it seem more
serious. Just a suggestion...
I'm sure there are those that will disagree with me. But I don't think
it's as important how professional things look as long as they are sound
ideas. Lest it be an ad hominem attack. Which, as previously indicated
is not a good thing.
Good ideas should be able to stand on their own. If Caveman's idea
turns out to be deemed better on it's technical merits, then the text vs
HTML vs TeX/LaTeX formatting shouldn't matter.
In which language are you intending to write the reference
implementation? I'd suggest writing it in a relatively low-level
language, so it's easier to read and port without making too
many assumptions.
I would probably argue that using a mid to higher level language or even
a pseudo code for documentation / explanation might be advisable. I
think that it's more important to get the idea out, in a way that it's
easily understandable and re-implementable by others.
Is it better to have the first implementation be crem de la crem and the
overall idea not be adopted? Or would it be better for the original
implementation to fade into history while the concept takes over and
surpasses current email solutions?
You really need to define more goals and non-goals; two non-specific
goals, and one non-goal really isn't enough to form an entire
specification.
I would suggest starting with a problem statement. Clearly document and
articulate what you think is wrong with the current email solutions.
After all, I believe that's the root of the motivation for this.
Once you have a clear problem statement, start developing possible
solutions. I encourage multiple -> many if not an order of magnitude
more than the problems.
Once you have multiple possibilities, then you can objectively compare
and contrast the possibilities to see which one is the best.
Additionally, I noticed that you have written that the "actual
message" will be restricted to UTF-8 with no HTML/JS/CSS, which you
collectively describe as "self-hating formats" (?). While I (and
most on this list) despise the use of the aforementioned formats
in e-mails to the appropriate extent, I struggle to see how you
are going to prevent them being transmitted using HillaryMail.
If there is anything that the industry is good at, it's encoding things
such that they can be transported by something that can't natively
support the unencoded thing.
All of the control codes of HTML are fully representable in ASCII,
which is a strict subset of Unicode. How are you going to prevent
people transmitting HTML over the protocol? It is up to the client
to parse the HTML into its intended aesthetic form; the server
has nothing to do with it. The only solution I could imagine is
rejecting all messages containing attachments with MIME types other
than plain-utf8, but is that really a good idea?
I think trying to restrict things will do more harm to the idea than the
idea itself would do good. It's likely to cause people to reject it out
of hand as why would they want to choose something that fights them?
I am interested, but gravely skeptical.
Well said.
I am not overtly opposed to the concept of replacing SMTP and enhancing
email. I just want to make sure that whatever eventually does replace
SMTP does so because it can stand up to technical scrutiny far worse
than anything I can throw at it. It should succeed because it really is
better, not because someone wants it to be better.
Historians will judge us and the decisions we make harshly, just like we
judge our previous technical brethren harshly for their decisions.
--
Grant. . . .
unix || die
