On 2012-11-30, Derek Martin <inva...@pizzashack.org> wrote: > > I agree; good reasons for the existing standards have been put > forth. Arguments against those standards and said reasons have > contained fallacious logic.
This is the first such claim. No one has yet called out any fallacy in logic with regards to allowing the reader to control the width. OTOH, this does not mean you cannot claim it now. If you think it's a fallacy, explain, and perhaps you'll have something. Until then, you can't win a debate by citing points that were not expressed. >> > Nearly all of them have been proposed by people of limited and brief >> > experience, people without substantial experience in large and >> > diverse environments, people who do not understand how email >> > actually works, people who do not grasp the scalability issues >> > involved, people who have never read the RFCs, people who have never >> > used more than one email client or operating system, people who make >> > the serious mistake of reading their email with a web browser, >>=20 >> This is a false cause fallacy. =20 > > False. This is not a statement of cause, No, it is in fact a statement of cause. You're just not finding it because it was not an /explicit/ textbook form of "A is the cause of B". But it does in fact imply A from B, and it's backwards, and therefore a logical fallacy. > and not even an attempt at one. Indeed it was not thought through. That's part of the problem. > It is an observation of fact, with an *implied* consequence: > people with inadequate experience are unlikely to be qualified to > make useful suggestions. False cause. Yes, poor choices is a consequence of an inexperienced background. The reverse is not necessarily so, so it's a lost cause. It's a red herring because it fails to explicitly state a cause effect, and the implied cause-effect is a false cause. >> Advocates on either side could make this same errors in judgement,=20 > > Absolutely. However the advantage which those on the side of the > established standards have is that their position is, almost > universally, backed by those who actually do have the knowledge and > experience to know better. Actually being a proponent of a particular standard only indicates indoctrination. It takes a deeper understanding to see the failures of a standard and support a platform to promote advancement of the standard. >> > people who simply want to do what they want to do because their >> > world view is myopic and selfish, >>=20 >> Actually it's quite the contrary. Now before going into that, first >> you should understand a proper tool can make composition equally >> simple, regardless of wrapping style. =20 > > This point is irrelevant, because the craftsman can use only the tools > available to him. Nonsense. The craftsman /makes/ tools. The craftman who only uses what's available is no craftsman. Not that it matters- to make standards driven by tools is like writing requirements based on the code -- it's backwards. > Or he can invent his own; except that if he needs someone else to be > able to work with the product of his labor, then he needs to make > certain his product is capable of being used by the tools they want > to use. Otherwise he may find himself sitting alone in his workshop > with a product no one wants (SEE BELOW). The chicken-egg problem you claim is delusional. You do not need a partner to make a product. A single individual or single organization can even craft a whole suite of tools from scratch if they so please, and they can be the first to do so. > There are literally thousands of tools exist for handling e-mail, > and NONE OF THEM WORK THE WAY YOU WANT. This is conventional wisdom. Again, the merit of a standard should not be bounded by the capability of existing tools. > So not only to you need to establish a new standard, but you need to > update all the existing tools to support it. No you don't. Tools become deprecated. Accept it. > As a practical matter, the benefit of whatever difference in format > you're about to suggest is vastly outweighed by the monumental > amount of work required to make the world support it (AND SEE > BELOW). I disagree. This is trivially simple text manipulation. Your perceived effort is only monumental because you believe every tool in existence must be updated. And you believe this in a world where many tools are non-compliant as it is, in some cases due to lack of maintainer motivation, and in other cases by design. This is no reason to resist improvements on standards. > Any of the points you make which follow from this one are therefore > invalid as a practical fact, regardless of whether they may be > correct from the perspective of formal logic. An opinion cannot be "invalid", only a fact can. If I've stated a matter of fact that you want to challenge, feel free. This is why I like quoting. It enables readers to know what you're talking about. Dodging this approach by hiding what you're referring to only exposes the weakness in what you're saying. That is, pointing to a glob of text and saying those facts are not practical is useless for everyone. It does not further your point. >> Etiquette varies based on the domain (e.g. where you are). =20 > > However for mailing lists, the 72-character line wrap and > conversational quoting are fairly universal, for previously > discussed good reason. Which mailing list? This is like saying "for restaurants, tipping is appropriate".. but if the restaurant is in Japan, you're setting yourself up for embarrassment. If by "mailing lists" you are talking about the mutt-users mailing list, and the procmail mailing list, then I would agree. >> > What we do not see are any of them advancing cogent, carefully-made >> > arguments for change. That is NOT to say such arguments don't exist: >> > perhaps they do. Perhaps there are changes that *should* be made. >>=20 >> Then you have not been paying attention. The point was already made >> on this list just a few days ago to use an unambiguous syntax that >> gives each reader the freedom to choose how wide their text is (as >> opposed to being force-fed the authors choice), and this point remains >> irrefuted. =20 > > I just refuted it. When, just now, in this very post? Again, you say an argument was made when it was not. How did you refute it? Please quote yourself in this case. This strategy of hiding behind blanket statements without quoting is a recipe for disaster. There was an *attempt* at refuting that particular argument (not just now, but earlier). I'm not sure if that's what you're referring to. Someone pointed out what they thought was an ambiguity. But then I posted a syntactic difference between the two types of expression. Which of course settled that point because no one contested that. You are still free to reply if you think something was overlooked. >> Detail on how to completely remove all traces of ambiguity was >> given, and so far uncountered. > > Only because I got sick of replying to your nonsense. You gave up. That will fail you every time. > It's incompatible with existing tools. That's an entirely different argument. It does have some marginal merit (see my next paragraph), but in no way does this further your position with regards to syntactic ambiguity. > It is unlikely to be adopted *by anyone*, because it does not > provide a sufficiently substantial benefit to warrant the monumental > effort to be implemented globally. Actually tools that already comply with the format=flowed standard in a sensible way do not need modification for rendering. It's a freebie.. They will already correctly render the format that I've proposed (that is, apart from the unlikely event that they crash when they encounter an LF). Nor would they need modification for composition, because they can compose in whatever standard they already support. And that's assuming some impractical utopia where no tool ever deprecates. As a practical matter, tools become obsolete as standards and conventions change and the tool does not keep up. > It must additionally be an entirely separate format than used by any > of the existing plain text formats, as otherwise if you attempt to > use it as one of the existing standards, it will immediately break > ALL EXISTING TOOLS. That is itself a hindrance to adoption. The standard should drive the tools, not the other way around.
