-13

I plan on asking a question that goes something like: if you're an IT Pro what RFC numbers should you have memorized?

Example

In the SMTP/Sendmail community it is common to say RFC 821, or 2821 when talking about the envelope of a message, and 822, 2822 when referring to the envelope. This was even expected of me during an interview at Goldman Sacks, Microsoft, and Pfizer. Why? because there are two headers: a secret one and the other one that's visible when you view headers in an email/ Knowing the numbers expedites communication when differentiating between the two.

I'm sure there are other IT shops that rely so heavily on an RFC standard that they have incorporated this into regular parlance.

Question for meta

I expect this to be a finite list of distinct constructive answers that are valuable. That makes me think it is On Topic and Constructive. Do you agree?

My next question is should it be CW or not? I want to incentivize answers, and allow the most prevalent (need to know) RFC's bubble to the top of the list.

What are your thoughts on the format of this question?

| |
4

A question like this will be generally closed as not constructive. With a link to this section of the faq. https://serverfault.com/faq#dontask

You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page.

This question is more of an open discussion and you might find a much better home on www.reddit.com/r/sysadmin or some other other forum.

The question itself will not be very useful for a broad audience. The sysadmin field has lots of generalists who need to know the basics, and lots of specialists who need regularly need to know about very specific things, but don't care about unrelated things. For example why would a SAN administrator care at all about SMTP.

| |
12

None. Trying to commit such things to memory is a guaranteed way to get it wrong.

| |
  • 4
    +1 - an IT professional will know to google topic RFCs or visit rfc-editor.org -- you may have a few RFC numbers committed to memory if you use them frequently (e.g. I know RFC 822/2822 for email, because I yell at mail admins for violating them all the time - same for RFC 1918), or you may know ones you're working with at the moment, but you shouldn't waste brainpower memorizing the numbers. Concentrate more on the important content. – voretaq7 Oct 31 '12 at 15:45
8

The only one I ever felt was important to know by number is RFC 2549.

| |
5

I don't think it's a good idea because the answer is "No one", or at best, "it depends".

First, this is useless knowledge than can be easily retrieved via a quick search. I absolutely hate the idea that "knowledge" like this is considered as a form of qualification in any way.

Second, this is so dependent on your work field that this will create an endless list consisting of 50% of the still-valid RFCs. As an example, if you don't work with E-Mail, there is no reason that you should know it's defined in RFC 2822, but even if you do, there is usually no reason to actually read it anyway.

| |
2

RFC 1149. Not the content, just the number so you know what your colleagues are talking about when they make jokes that bandwidth increases with carrier age.

| |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .