Wikipedia:Articles for deletion/Fully qualified domain address
- The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.
The result was no consensus. there being no further discussion in a week after the relist, no-consensus seems reasonable; no prejudice to a merge is consensus can be obtained for that in the usual way--I have no opinion on the underlying issue DGG (talk) 17:40, 1 May 2009 (UTC)[reply]
Fully qualified domain address[edit]
- Fully qualified domain address (edit | talk | history | protect | delete | links | watch | logs | views) (delete) – (View log)
This definition is not notable and not in common use. It happens to be defined in an RFC on "voice profiles for internet mail", but there are a lot of definitions in various RFCs. The FQDA article was prod'ed once and it was deleted, but when I prod'ed this version of the name, the prod was contested. I have looked, and on the first 6 pages of google, and all references are either 1) copies of wikipedia's e-mail article, 2) usages where they actually mean fully qualified domain name and not the definition given in this article, or 3) related to RFC 3801 (and earlier versions of this RFCs and/or drafts for these RFCs). The one exception was a thread on the Postfix mailing list. While RFCs are good sources, random definitions in them aren't noteworthy.
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL Wrs1864 (talk) 23:49, 19 April 2009 (UTC)[reply]
Your pressing 'Next' 6 times in Google is not material.
No instances of where fully qualified domain name (example.org), or this site and mirrors have mistakenly been used in the article. The term is used in multiple RFCs—which, in your words, are "good sources." It is unclear what is "random" about the sometimes-hyphenated techical term. Usage in RFCs, other than the single #3801 one you mentioned in the Prod, is already provided in the article, which you are obliged to check before nominating.
It's a specialized technical area, and part of that; it has usage in comp.unix.admin (long-established mailing list), discussion of mail systems [1] & [2].
It is taught as part of at least one university level computer science syllabus, California State University, Long Beach, by Dr. T. Maples, Ph.D., see http://www.cecs.csulb.edu/~maples/cecs410/notes/410-1-Intro.doc: "Note: A modern Internet e-mail address is a string of the form [email protected], creating a Fully Qualified Domain Address (FQDA). The part before the @ sign is the local part of the address, often the username of the recipient, and the part after the @ sign is a domain name." –Whitehorse1 07:15, 20 April 2009 (UTC)[reply]
- The phrase is in only one current RFC, not multiple ones. RFC 3801 uses it, as I mentioned above. It obsoletes a previous version of the same document, RFC 2421, which in turn obsoleted the previous version, RFC 1911. Neither previous revisions, nor the draft documents used to make those RFCs, count as multiple sources any more than previous versions of a wikipedia article count as multiple articles. As far as your compsci syllabus, it is an exact copy of the line out of e-mail from a few years ago. Actually, that entire document looks like a worked over copy of wikipedia's e-mail article. A few usages on mailing lists and news groups isn't enough to make a phrase notable. So far, with both of us looking, we have found one (1) reference to a reliable source in an obscure RFC. Wrs1864 (talk) 12:26, 20 April 2009 (UTC)[reply]
- Incidentally, the quoted example use of the term in the university course notes defines the term incorrectly as well. The second part (after the @ symbol) must not be a domain name, but an FQDN, i.e., a DNS host name. WP should have an article defining the term properly using the existing Internet Standards Track RFC as the source of definition. Kbrose (talk) 18:13, 20 April 2009 (UTC)[reply]
- Indeed, the "incorrect" defintion of FQDA needing just a domain name instead of a FQDN is one of the easy ways to tell if the "source" was copied from wikipedia's e-mail article where it was defined wrong. Sadly, if you accept things like this compsci syllabus as a "reliable source", due to the error in wikipedia, it may now be that wikiepdia has changed the definition of the term. This isn't the first time that such errors in wikipedia have been picked up by "reliable sources." On the other hand, this also points out just how few places give a definition for this term. Wrs1864 (talk) 22:13, 26 April 2009 (UTC)[reply]
- Well, there were rather more instances of usage/defining the term (though still a small quantity) before you removed them. (diff) Those were IETF Internet-Draft documents which, of course, are not RFCs; be that as it may, referring to an RFC as as a 'standard', like the 'robots exclusion standard' (sic) is commonplace, the distinction between document types is sometimes blurred. –Whitehorse1 22:36, 26 April 2009 (UTC)[reply]
- Well, there were rather more instances of usage/defining the term (though still a small quantity) before you removed them. (diff) Those were IETF Internet-Draft documents which, of course, are not RFCs; be that as it may, referring to an RFC as as a 'standard', like the 'robots exclusion standard' (sic) is commonplace, the distinction between document types is sometimes blurred. –Whitehorse1 22:36, 26 April 2009 (UTC)[reply]
- Indeed, the "incorrect" defintion of FQDA needing just a domain name instead of a FQDN is one of the easy ways to tell if the "source" was copied from wikipedia's e-mail article where it was defined wrong. Sadly, if you accept things like this compsci syllabus as a "reliable source", due to the error in wikipedia, it may now be that wikiepdia has changed the definition of the term. This isn't the first time that such errors in wikipedia have been picked up by "reliable sources." On the other hand, this also points out just how few places give a definition for this term. Wrs1864 (talk) 22:13, 26 April 2009 (UTC)[reply]
- Just to clarify here: I'm not asserting the linked edit was correct or incorrect, or in _any_ way suggesting or implying inappropriateness.
- OK, I think maybe it would help if I explained a little about the RFC process here. Before there can be an IETF Request for Comment (RFC), you must submit an internet draft version of the document. If the drafts pass review and become RFCs, these drafts do not disappear, but they are meaningless. Once an RFC has been published, not a word of it can be changed for any reason. If anything needs to be updated, from just minor spelling changes to major revisions, a new internet draft needs to be submitted and then the a new RFC with a new number will be published. All the RFCs and drafts that you listed were for the exact same protocol/standard. with one exception. Trying to cite all of those drafts/RFCs as separate "sources" would be like trying to cite all the versions of this AfD as separate AfDs. Now, there is one draft document that wasn't part of the history of RFC 3801, but that draft expired 10 years ago. It is important to remember that Internet drafts are not peer reviewed documents. All the RFC editor does for drafts is check the formatting. I could package up this AfD as an internet draft, format it correctly, send it off to the right email address, and it would be published. An internet draft might count as a self-published source (WP:SPS), but like most other things that anyone can publish, they should generally be avoided here.
Opposed. After thinking about this term for a week now since the original suggestion of deletion, I am going with my original (private) reaction and vote to oppose the deletion. Even though the term is not very often used anymore these days, I do remember there was more frequent use of this term in the 80 and 90s. Furthermore, it clearly is defined in the RFC literature, the number of citations doesn't really matter, IMHO. The RFC in which it is defined, is not so obscure, b/t/w, rather an important standard for voicemail systems. What persuades me mostly though, is that the term has been confused in some instances with 'fully qualified domain name' and thus I think WP can serve as a more accessible reference to a general audience for the correct meaning of this term. I think policy strictness (in terms of notability for WP use) is not a good strategy in this case and deletion serves no real purpose outside of such criteria. Kbrose (talk) 15:10, 20 April 2009 (UTC)[reply]
- I too remember when this phrase popped up more often, but it was never that common. I really don't think that ignoring WP:N in order to use wikipedia to push for the "correct" use of the phrase is at all appropriate, that would violate WP:NPOV and WP:NOR. Considering how most uses of this phrase are actually intending to be fully qualified domain name, I could see a redirect tagged as a misspelling. Wrs1864 (talk) 15:38, 20 April 2009 (UTC)[reply]
- Note: This debate has been included in the list of Internet-related deletion discussions. -- — LinguistAtLarge • Talk 17:58, 20 April 2009 (UTC)[reply]
- Merge to email address. The subject of the topic is basically an e-mail address where the domain part is a FQDN. The term is not notable, and is only used (as far as we can tell) in a single reliable source. It is worth mentioning, it isn't worth having its own page. JulesH (talk) 20:07, 20 April 2009 (UTC)[reply]
- Keep with links to fully qualified domain name and email address for clarity. A redirect to email address would be confusing. Ventifax (talk) 04:27, 26 April 2009 (UTC)[reply]
- Relisted to generate a more thorough discussion so consensus may be reached.
Please add new comments below this notice. Thanks, I'mperator 23:34, 26 April 2009 (UTC)[reply] - The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.