On 8/26/20 2:33 PM, Caveman Al Toraboran wrote:
as for the name "hillarymail", nothing against her.
I would suggest using any reference to Hillary Clinton. I believe her
name is too politically charged to use it in good faith.
it's just that i heard so much about hillary's mails up to a point
all mails started to feel as if they belong to her.
Almost everything I heard about it seemed to be negative. What little I
heard that wasn't negative was simply neutral.
My opinion is that the name (independent of H.C.) and H.C.'s association
would cause me to choose a different name.
I'd suggest something that describes what it does.
Note: I've not ready your proposal yet. I've earmarked to do so when I
have more time.
i intend to eventually write a reference implementation either way
(hopefully). specially that this seems to me very easy to implement,
yet it seems also powerful.
"seems" is the operative word. I think you will find that there is MUCH
more to it than what I think you think there is.
not sure what "formal r.f.c." means.
(a) if it means a less ambiguous description, then "yes, but at a
natural pace based on demand" (in the spirit of occam's razor).
How does Occam's Razor or Parsimony apply to this?
(b) if it means an r.f.c. submitted to isoc/ietf, then "no".
RFCs are decidedly outside of ISOC / IETF.
i think we should ignore standard bodies for awhile since they seem
to be ignoring us.
Those sentiment / attitude is concerning to me.
Just because you don't like something or disagree with it is not in and
of itself a reason to ignore or avoid it. Especially when it is (RFCs
are) the well established process to do something in the Internet community.
imo that's a parsing error on your side. to me "idiot" didn't refer
to smtp/pop/imap users.
I would strongly suggest anything that can be construed as an ad hominem
attack.
it rather referred to those those who can't use address books or
bitcoin.
I think those are two very different things. Address books have existed
for a long time and are included in all prominent devices / email
clients in one form or another. The same can't be said about bitcoin.
either way i've just replaced "idiots" by "people". "idiot" wasn't
justified either way.
There's no place, much less need for ad hominem attacks in standards
documents, be they formal, e.g. ISO, IETF, or non-standards based, e.g. RFC.
i mean easy for both,
I find the goal of easy for the user to use and easy for the developer
to develop to be almost diametrically opposed to each other. In my
experience, it's either been a pay it forward once (developer) or pay it
back perpetually (user).
Which are you prioritizing? The developer or the user?
I would strongly suggest the developer pay it forward so that the end
users don't have to perpetually pay it back.
but subject to the constraints specified under "goals" and "non-goals".
e.g. if becoming easier would cause the protocol to end up needing
to trust a sys admin, then that's not acceptable.
Elaborate on what "trusting a system administrator" means and why it's
not acceptable.
I think you will find that there are regimes that will not allow
technology that they can't see into and observe. As such, they will
dictate that the technology trust the system administrator (regime).
Lest they ban the technology.
but if it is possible to make it easier while still satisfying
the constraints (goals/non-goals), then that's a good step forward
(perhaps draft one?).
The requirement to go from informational RFC to standards track RFC is
multiple independent implementations. So not only do you need to get
your implementation working, but you also need to get someone else to
completely independently create their own implementation and it must be
interoperable with yours. Anything less and you'll never achieve
anything but an informational RFC status. And you will need a standards
track RFC status to get the big players to even think about entertaining
the notion of this.
--
Grant. . . .
unix || die
