Gentoo Archives: gentoo-user

From: Grant Taylor <gtaylor@×××××××××××××××××××××.net>
To: gentoo-user@l.g.o
Subject: 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?)
Date: Fri, 28 Aug 2020 00:03:17
Message-Id: 816edad4-14dd-b286-d382-8400179edd56@gentoo.tnetconsulting.net
In Reply to: 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?) by Ashley Dixon
1 On 8/27/20 11:55 AM, Ashley Dixon wrote:
2 > Well said; thanks for the correction.
3
4 Of course. My intention is to positively contribute to and learn from
5 the community.
6
7 > Mathematical notation can be seen as a tightly coupled analogue
8 > to this sort of typesetting: the same book that introduced
9 > Algebraic expressions (Cossike numbers) and the equals sign ('=')
10 > into the English-speaking world also suggested the use of
11 > the word "zenzizenizenike" to represent `x^8` [1]. Solid ideas
12 > will stick due to, as you said, their own merits; the form of the
13 > representation is generally redundant.
14 >
15 > Nevertheless, as xkcd so brilliantly explains, TeX inspires a level
16 > of blind trust in the content of a document [2]. As long as you avoid
17 > proposing standards in the form of an animated GIF, you're probably
18 > going to be OK. ;-)
19
20 I wonder if this is a side effect of the fact that TeX / LaTeX is a
21 difficult markup language to work in and takes considerably more time
22 and effort than simple text. As such, there is a good chance that the
23 idea that someone takes the time to express in (La)TeX is probably more
24 completely thought out than simple text. After all, why would someone
25 spend the time and exert the effort to finely polish a half baked idea
26 in (La)TeX?
27
28 Disclaimer: I'm speaking in general and do not mean to imply anything
29 towards Caveman's efforts. It takes gumption to go against the status quo.
30
31 > I concur, but this was about the reference implementation.
32
33 Do you mean reference as opposed to initial. Meaning that the reference
34 implementation has had some time to grow and evolve and be optimized.
35
36 Fair enough.
37
38 > It would be impossible to make the initial implementation the crème
39 > de la crème of all implementations, unless the protocol was never
40 > intended to expand.
41
42 With what little I know about statistics, I think that there is a very
43 small but still greater than zero percent chance of it happening. It's
44 just *EXTREMELY* unlikely. ;-)
45
46 > We do see some reference implementations being used as the de
47 > facto choice for supporting many standards, such as Apache Tomcat
48 > as the ref. imp. for Java Servlets, but as the name would
49 > suggest, reference implementations are only intended to be used
50 > as a reference to developers of future implementations.
51
52 I don't think anything precludes the use of the reference implementation.
53
54 Given that things grow and evolve, I think it means that the reference
55 implementation needs to be used /somewhere/ for the people maintaining
56 it to gain experience and knowledge germane to said reference
57 implementation. Granted, this can be a small subset and does not need
58 to be on the front lines.
59
60 > Moreover, these ridiculous restrictions only encourage various
61 > implementations to deviate from the standard, adding their
62 > own non-standard extensions like "HillaryMail HTML support".
63 > Implementation developers are always going to add stupid things to
64 > their software (just look at the GNU `typeof` introspection mess),
65 > but the standard text itself should certainly not encourage
66 > such behaviour.
67
68 Indeed.
69
70 I also think that it's important to keep in mind that sometimes there
71 are external limitations that dictate what can and can not be done.
72 Like the fact that communications circuits were not guaranteed to be
73 8-bit clean when email (RFC 822 and what predates it) and SMTP (RFC 821
74 and what predates it). It's not any more fair to blame the authors of
75 RFC 821 for not supporting 8-bit than it is to blame Sir Tim Burners-Lee
76 for not including encryption when he developed HTML and HTTP.
77
78
79
80 --
81 Grant. . . .
82 unix || die

Replies