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)

I'm a Constable (and Author), not an Editor, and am here just as an unofficial bystander. I just want to say that there is *nothing* per se, that limits the length of *any* article. Except common sense, I suppose. We probably don't want 40,000 words about a single episode of a Simpsons television show. But, as I'm pretty sure that our founder and Editor in Chief wrote on the Talk page of the Ayn Rand article, if it takes 60,000 words to set out the proposition clearly, then write the 60,000 words. Other Editors may have other ideas, of course, and it would vary from individual article to individual, but, for the moment, don't be put off by worries of length. Hayford Peirce 21:45, 23 November 2009 (UTC)

I suggest we split this into two articles - technical and historical. The technical part can be similar to the other articles under "Email authentication". What does the protocol do, and what are its limitations. The historical part can be a subtopic under "Email history". I would suggest making this a general article on the history of all email authentication protocols. Hopefully, this will segregate the controversial stuff from the technical fundamentals. I can write the technical article, with Hadmut's assistance on factual accuracy. Hadmut can write the historical article, with our assistance on neutrality and non-partisan language. Hadmut, please read that article on neutrality. The policy does *not* in any way require you to "tell wrong facts". I think you will see that when we get to specific examples where we suggest changes in your writing.

As for the length of the articles, my preference for short is not a policy issue, but just to make the whole cluster more suitable for students and busy professionals who may be interested in specific aspects of a topic, but no time to read a whole book. Note that the position of these articles on specific protocols is two levels down in our "Email system" cluster. You can count on the reader having already understood the two parent articles.

On the link to the RMX draft, I have no problem. I searched the IETF archives, and did a Google search, and could find nothing better than the draft on Hadmut's website. It's a shame the IETF doesn't do a better job of archiving these drafts.

On using Hadmut's name in the first paragraph, that seems appropriate to identify a little-known protocol in a way that is searchable. The article on PGP has "Phil Zimmerman" in a similar context. SPF is well-known, and has no such need. We just have to be careful that it does not seem promotional in any way. --David MacQuigg 13:52, 24 November 2009 (UTC)

OK, my proposal is: Let me continue to write the article the way I'd do it, and then discuss it. Just a simple request: Please try to not correct anything while I am writing. It's annoying to have those mid air collissions. Hadmut Danisch 21:29, 25 November 2009 (UTC)

It's fine for you to write a draft, but, as I understand CZ policies, write the draft in your userspace, and then transfer it to the mainspace when you are ready for comment. There's a pretty firm CZ belief that people don't "own" articles in mainspace, and can't tell people not to change things. Remember, CZ is intended to be quality-checked, so if an Editor has a concern, he or she needs to be free to speak up at any time.

I can help you set up a userspace work area if you aren't familiar with the conventions. Howard C. Berkowitz 22:02, 25 November 2009 (UTC)

I understand Hadmut's concern about "mid-air" collisions, and I think the sandbox (userspace) is an excellent solution. I write most of my articles that way. Take a look at the sandbox linked from my user page: User:David_MacQuigg. Sometimes I get an inspiration to write an article, but I don't have time to get even a first draft completed. It would waste everyone's time to be making corrections at that point, although I have asked other editors to look at some of my sandbox articles for general comment. If and when I think they are ready for "publication", I move them to mainspace.--David MacQuigg 11:24, 26 November 2009 (UTC)

Yes. It's not a "demotion" to move something to userspace; I do it myself when I find that I'm still working out ideas. Indeed, not infrequently, I start an article in a local editor on my desk, and move it to userspace only when it's far enough along that I have to check links and Wikiformatting. When I move it to mainspace, I actually hope I'll get comments and collaboration -- if I didn't want those, I'd submit to journals. Howard C. Berkowitz 15:46, 26 November 2009 (UTC)

It's not about not wanting to have comments and collaboration. It's about not beeing able to press the Save button without getting an error message... Hadmut Danisch 12:26, 29 November 2009 (UTC)

One more reason to use the Sandbox method, then. You really have to accept the fact that if you contribute to CZ, other Citizens are apt to edit whatever you're working on at any time -- but not in your Sandbox. If you're primarily concerned with losing stuff as you Save it (because of an Edit Conflict), before you Save it, first do a "Show preview", then highlight the text you've just written and Copy it. Then Save the article. That way, if there's an Edit Conflict, you can easily Paste your copied text into the new version. There are other methods, as well. But I recommend the Sandbox method if you are writing complicated text. Hayford Peirce 16:48, 29 November 2009 (UTC)

Shortness

There is a major distinction between saying an article can be any length, and saying that a group of articles can be of any length. The first is not user-friendly, while the latter is very much so. By having articles at different levels of details, it allows us, quite differently from Wikipedia, to "drill down" to the appropriate level of detail for the reader. One reader might just want to know that OSPF is a fast, somewhat computationally expensive, CIDR-friendly routing protocol. Another reader might want to know the history of how the Dijkstra algorithm has continued to be tuned in OSPF implementation. Howard C. Berkowitz 16:39, 24 November 2009 (UTC)