Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)

[Grant Taylor]

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