Talk:Reverse MX

The outline looks good. I worry that the article may get too long, however. Use the references and links to external articles whenever you can to defer discussion of details. What we need here is a summary that will interest students and others who are not expert in email systems. I moved the link you added on the main page to the External Links page, and put it in proper format, with an annotation, as recommended by CZ.

Another worry is that we have to be careful about getting partisan. I would not used Microsoft's name, except in the most factual, neutral context. You might want to think about changing the section heading under "Reasons for failure" from "SPF and Microsoft's attitudes" to "Competing protocols" or "Commercial pressures". Let the facts speak for themselves. Readers getting down to this level in our "Email system" cluster will be very capable of drawing their own conclusions.

This is a bit of technology history I find fascinating, and I hope we can do a good job on it. It addresses not just what happened four years ago with the failure of one proposal, but what is wrong with our email system today.
--David MacQuigg 16:59, 22 November 2009 (UTC)

Hadmut, I just read the first draft of your article, and my worry is confirmed. The article needs to be shorter. See the article Sender_Policy_Framework for an example, and the articles on other authentication protocols under Email_authentication/Related_Articles.

I also worry that we may have a problem with the CZ policy on self-promotion. I just got a note from one of the other editors who read your first draft and had this concern about what he read. It is sometimes difficult to separate good writing from self-promotion, especially when an author is writing on a technology he helped develop. Take a look at these articles for guidance: - - - CZ:Policy on Self-Promotion - - - CZ:Neutrality Policy

I know that writing a short article may be more difficult than a long one, and I don't want to add any more difficulty to your task. If you prefer, just continue your original plan, and get all the facts on paper, then I will write a proposed distillation of the most important and fundamental points.
--David MacQuigg 12:38, 23 November 2009 (UTC)

David, this is a matter of the given task. I was asked to write the article in a way that allows technical readers to understand why RMX was developed that way. Obviously that might result in a long article, but the history of RMX was long as well. The question is, whether the article should give just an overview or summary, or whether the article should allow readers to technically follow the design decisions.

Highly delicate is your request about how to mention Microsoft. Your proposal might sound more neutral, but would actually tamper with the history. The reason why RMX, SPF, Sender ID were declined by the open source community, was actually the attitude of Microsoft, their patent application, their claim to get licence registrations by every user of any mail system and the dispute on the 2004 IETF conference in San Jose (which I attended personally). Microsoft has not been neutral. Describing the facts in the way and with the wording citizendium requires, it would mean to tell wrong facts.

It is not possible to write a correct article about RMX with the length of the SPF article, because RMX is not just a technical proposal. At the end it became a part of IRTF/IETF history and an important example of how and why security measures fail. If the article should allow readers to learn from, as you requested, the article should cover the point with some level of completeness.

At the moment, I am not sure how to proceed, since there are contradicting requirements. Especially that CZ-pages you cited about self-promotion seems to be problematic, because, after all, I am writing here an article about my own work and how it had been treated by IRTF/IETF. It is not obvious how I am expected to write about my own work and what I did without sounding self-promoting at the same time. CZ not even allows me to link to my own web pages. Part of the history is that all these derived proposals have been published as RFCs, but not mine, although all were based on RMX and even did cite it. The drafts are available on my web page only.

So, before I spend more time to write an article that will partly or completely be deleted later, please clarify with the other (hidden) editors what exactly is the goal of that article and how I should write to both conform with the CZ requirements and being correct at the same time. Hadmut Danisch 21:11, 23 November 2009 (UTC)

Let me add some thoughts as another Computers Workgroup Editor, who is not an email specialist but does have IETF and IRTF experience. I would say that the first purpose is not to give the history of RMX, but to provide an introduction to someone not prepared to leap into the RFCs. For example, when I've written about [IP address]]ing, BGP, OSPF, and DNS, my first intent was to give a basic explanation understandable to a computer science undergraduate. Especially in routing, I can give a great deal of history, but it hasn't been a high priority.

I see no reason, in a history section, not to link to drafts, especially when those drafts are no longer archived by the IETF and they do contribute something to history. It is possible, I think, to write about history without overemphasizing one author; where IETF WG drafts exists, I'd prefer to see them linked than individual contributions. If anyone wants to make an issue of linking to personal copies of drafts that were in the IETF/IRTF, I'm perfectly willing to add to the IETF article as to why this may be the only way to retrieve the relevant information.

There's nothing inherently wrong with mentioning the work of individuals when relevant. During the IPng (i.e., pre-IPv6), two of the contestants were SIP (Steve's Internet Protocol) and PIP (Paul's Internet Protocol), as opposed, say, to TUBA (TCP and UDP over Bigger Addresses). (Now I'm trying to remember the fourth proposal). Howard C. Berkowitz 21:24, 23 November 2009 (UTC)