टिप्पणियों के लिए अनुरोध

For the Wikipedia process, see विकिपीडिया:Requests for comment.

कंप्यूटर नेटवर्क इंजीनियरिंग में, टिप्पणियों के लिए अनुरोध (RFC) इंटरनेट इंजीनियरिंग टास्क फ़ोर्स (IETF) द्वारा प्रकाशित ज्ञापन है, जो इंटरनेट और इंटरनेट-संबंधी प्रणालियों के कार्य पर लागू विधि, व्यवहार, अनुसंधान, या अभिनव परिवर्तनों को वर्णित करता है।

इंटरनेट सोसाइटी के माध्यम से इंजीनियर और कंप्यूटर वैज्ञानिक, सहकर्मी समीक्षा या केवल नई अवधारणाओं, सूचना या (कभी-कभी) इंजनीयरी हास्य सूचित करने के लिए, एक RFC के रूप में वार्ता प्रकाशित कर सकते हैं। IETF, RFC के रूप में प्रकाशित कुछ प्रस्तावों को इंटरनेट मानकों के रूप में अपनाता है।

इतिहास

RFC स्वरूप की स्थापना 1969 में प्राथमिक ARPANET परियोजना के अंश के रूप में हुई। ^[1] आज यह इंटरनेट इंजीनियरी टास्क फोर्स (IETF), इंटरनेट आर्किटेक्चर बोर्ड (IAB) और - कुछ हद तक - सामान्य तौर पर कंप्यूटर नेटवर्क शोधकर्ताओं के वैश्विक समुदाय के लिए आधिकारिक प्रकाशन माध्यम भी है।

पहले RFC के लेखकों ने अपने काम के लिए टाइपलेखन का इस्तेमाल किया और ARPA शोधकर्ताओं के बीच उसकी संपठनीय प्रतियां वितरित कीं. आधुनिक RFC के विपरीत कई प्रारंभिक RFC, टिप्पणियों के लिए अनुरोध हुआ करते थे . RFC सवाल खुला छोड़ता है और एक कम औपचारिक शैली में लिखा होता है। यह कम औपचारिक शैली आजकल इंटरनेट मसौदा दस्तावेजों का सामान्य स्वरूप है, जो RFC के रूप में मंजूरी देने से पहले का अग्रगामी चरण है।

दिसम्बर 1969 में, शोधकर्ताओं ने नए प्रचालित ARPANET के ज़रिए नए RFC का वितरण शुरू किया। "मेज़बान सॉफ्टवेयर" शीर्षक वाला RFC 1, कैलिफोर्निया विश्वविद्यालय, लॉस एंजिल्स (UCLA) के स्टीव क्रोकर द्वारा लिखा और 7 अप्रैल 1969 को प्रकाशित किया गया। हालांकि इसे स्टीव क्रोकर ने लिखा, पर RFC, स्टीव क्रोकर, स्टीव कैर और जेफ़ रुलिफ़सन के बीच एक प्रारंभिक कार्य दल की चर्चा से उभरा. (दस्तावेज में बिल डुवैल को केवल प्रकाशन से पूर्व कार्य दल की अंतिम बैठक में शामिल होना सूचीबद्ध है।)

RFC श्रृंखला को पहले परिभाषित करने वाले RFC 3 में, क्रोकर ने "नेटवर्क कार्य दल" को RFC श्रृंखला का श्रेय दिया। ऐसा नहीं लगता कि कभी इस समूह का कोई औपचारिक अस्तित्व भी था, जिसे "इस समूह के लोग" के रूप में परिभाषित किया गया, लेकिन आज भी यह श्रेय RFC के साथ मौजूद है।

1970 दशक के बाद से कई RFC भी UCLA से आए, सिर्फ़ छात्रवृत्ति की गुणवत्ता की वजह से नहीं, बल्कि इसलिए भी कि UCLA, ARPANET पर मौजूद पहले इंटरफ़ेस संदेश प्रॉसेसर (IMP) में से एक था।

स्टैनफ़ोर्ड रिसर्च इंस्टीट्युट में डगलस एंजलबार्ट का ऑगमेंटेशन रिसर्च सेंटर (ARC), चार पहले ARPANET केंद्रों में से एक और होने के अलावा, पहला नेटवर्क सूचना केंद्र तथा (जैसा कि समाजशास्त्री थीयर्री बार्डिनी ने नोट किया) प्रारंभिक असंख्य RFC का स्रोत था।

1969 से 1998 तक, जॉन पोस्टेल ने RFC संपादक के रूप में कार्य किया। (1998 में उनकी मृत्यु पर, उनका मृत्युलेख RFC 2468 के रूप में प्रकाशित किया गया।) अमेरिका की संघीय सरकार के साथ मूल ARPANET अनुबंध की समाप्ति के बाद, इंटरनेट सोसाइटी (IETF की ओर से कार्य करते हुए) USC सूचना विज्ञान संस्थान के नेटवर्किंग प्रभाग के साथ (IAB के निर्देशनाधीन) संपादन और प्रकाशन जिम्मेदारियों को ग्रहण करने के लिए अनुबंधित हुई। जॉन पोस्टेल ने अपनी मौत तक RFC संपादक के रूप में काम करना जारी रखा। बाद में, बॉब ब्रेडन ने परियोजना प्रमुख की भूमिका संभाली, जबकि जॉइस के. रेनॉल्ड्स 13 अक्टूबर 2006 तक दल का हिस्सा बने रहे।

RFC रचना और विकास

RFC संपादक प्रत्येक RFC को एक अद्वितीय क्रम संख्या प्रदान करता है। जब एक बार RFC के लिए एक संख्या नियत और प्रकाशित किया जाता है, तो RFC को कभी निरस्त या संशोधित नहीं किया जाता; अगर दस्तावेज़ में संशोधन की आवश्यकता हो, तो लेखक संशोधित दस्तावेज़ प्रकाशित करते हैं। इसलिए, कुछ RFC दूसरों का स्थान लेते हैं; ऐसे अधिक्रमित RFC को पदावनत, अप्रचलित, या अव्यवहृत कहा जाता है। आनुक्रमिक RFC एक साथ, इंटरनेट मानकों और प्रथाओं के विकास के सतत ऐतिहासिक रिकॉर्ड रचते हैं।

ध्यान दें कि शब्द RFC इस श्रृंखला के लिए अनन्य नहीं है। कई अन्य संगठनों ने RFC शब्द का उपयोग करते हुए दस्तावेज़ प्रकाशित किए हैं। तथापि, IETF RFC इंटरनेट पर अब तक की सर्वाधिक विख्यात RFC श्रृंखला रही है।

RFC रचना प्रक्रिया, ISO जैसे औपचारिक मानक संगठनों की मानकीकरण प्रक्रिया से अलग है। इंटरनेट प्रौद्योगिकी विशेषज्ञ बिना बाह्य संस्था के समर्थन के भी इंटरनेट मसौदा पेश कर सकते हैं। IETF की मंजूरी के साथ स्टैंडर्ड-ट्रैक RFC प्रकाशित किए जाते हैं और आम तौर पर कार्य दलों में भाग लेने वाले विशेषज्ञों द्वारा रचित होते हैं, जो पहले इंटरनेट प्रारूप प्रकाशित करते हैं। इस अभिगम से दस्तावेज़ों के RFC के रूप में परिपक्व होने से पहले समकक्ष समीक्षा का शुरूआती दौर सुगम हो जाता है।

ISO तथा राष्ट्रीय मानक निकायों के ठेठ औपचारिक, समिति-संचालित प्रक्रियाओं की तुलना में, व्यक्तियों या छोटे कार्य दलों द्वारा निष्पन्न व्यावहारिक, अनुभव-संचालित, तथ्यानुरूप मानकों के स्रोत की RFC परंपरा के अधिक महत्वपूर्ण लाभ हैं।

परिहास RFC की समृद्ध परंपरा का अस्तित्व, इन फ़ायदों में से कुछ का द्योतक है। आम तौर पर हर साल, सामान्यतः अप्रैल फ़ूल्स डे के अवसर पर, कम से कम एक जोक प्रकाशित होता है।

अधिकांश RFC "MUST" (ज़रूरी) और "NOT RECOMMENDED" (असंस्तुत) जैसे सामान्य शब्द (RFC 2119 द्वारा परिभाषित तौर पर), ऑगमेंटेड बैकस-नाउर फ़ार्म (ABNF) (RFC 5234 द्वारा परिभाषित रूप में) मेटालैंग्वेज के तौर पर और सरल पाठ आधारित पदों के सरल समूह का प्रयोग करते हैं, ताकि RFC सुसंगत रहे और आसानी से समझा जा सके। ^[2]

RFC और RFC प्रक्रिया के बारे में अधिक जानकारी के लिए, RFC 2026, "इंटरनेट मानक प्रक्रिया, संशोधन 3" देखें.^[2]

RFC प्राप्त करना

वर्ल्ड वाइड वेब पर RFC का अधिकारिक स्रोत RFC Editor है।

लगभग कोई भी व्यक्तिगत, प्रकाशित RFC, जैसे RFC 5000 को निम्न उदाहरण के समान URL के ज़रिए पुनःप्राप्त कर सकते हैं: http://www.rfc-editor.org/rfc/rfc5000.txt

प्रत्येक RFC को सादे ASCII पाठ के रूप में प्रस्तुत और उस रूप में प्रकाशित किया जाता है, लेकिन अन्य प्रारूपों में भी उपलब्ध हो सकता है। हालांकि, 2008 के अनुसार ^[update] निश्चित संस्करण किसी स्टैंडर्ड-ट्रैक विनिर्देशन का, ASCII संस्करण है।

RFC के मेटाडाटा तक सुगम पहुंच के लिए, जिसमें सार, खोजशब्द, लेखक, प्रकाशन तिथि, शुद्धिपत्र, स्थिति, और विशेष रूप से बाद के अपडेट भी शामिल हैं, RFC संपादक साइट कई विशेषताओं के साथ एक खोज प्रारूप भी उपलब्ध कराता है। पुनर्निर्देशन कुछ कुशल मानकों को स्थापित करता है, उदाहरण: http://purl.net/net/rfc/5000

स्थिति

सभी RFC मानक नहीं होते हैं।^[3] प्रत्येक RFC को स्थिति के संबंध में इंटरनेट मानकीकरण प्रक्रिया के अंतर्गत एक पदनाम सौंपा जाता है। यह स्थिति निम्न में से एक होती है: सूचनात्मक, प्रायोगिक, उत्तम मौजूदा व्यवहार (BCP), स्टैंडर्ड-ट्रैक, या ऐतिहासिक . स्टैंडर्ड-ट्रैक दस्तावेजों को आगे प्रस्तावित मानक, मसौदा मानक और इंटरनेट मानक दस्तावेज़ों में विभाजित किया गया है। शब्द ऐतिहासिक, पदावनत स्टैंडर्ड-ट्रैक दस्तावेजों या अप्रचलित RFC पर लागू किया जाता है, जो स्टैंडर्ड-ट्रैक की स्थापना से पहले प्रकाशित किए गए थे। केवल इंटरनेट इंजीनियरिंग संचालन समूह (IESG) द्वारा निरूपित IETF, स्टैंडर्ड-ट्रैक RFC का अनुमोदन कर सकते हैं। प्रत्येक RFC स्थिर है; अगर दस्तावेज़ बदला जाता है, तो इसे दुबारा प्रस्तुत किया जाता है और इसे एक नई RFC संख्या सौंपी जाती है। यदि एक RFC इंटरनेट मानक (STD) बन जाता है, तो उसे एक STD नंबर आबंटित किया जाता है, लेकिन उसकी RFC संख्या बरकरार रहती है; तथापि, जब इंटरनेट मानक को अद्यतन किया जाता है, तो उसकी संख्या वही रहती है और वह केवल एक अलग RFC या RFC के सेट को संदर्भित करता है। मान लें कि एक इंटरनेट मानक, STD n किसी निश्चित समय पर RFC x और y हो, लेकिन बाद में वही मानक बजाय उनके RFC z में अद्यतन हो सकता है। उदाहरण के लिए, 2007 में RFC 3700 इंटरनेट मानक - STD 1 था - मई 2008 में उसे RFC 5000 से बदला गया, अतः RFC 3700 ऐतिहासिक बन गया, RFC 5000 इंटरनेट मानक और मई 2008 के अनुसार ^[update]STD 1 है RFC 5000. जब STD 1 को दुबारा अद्यतन किया जाएगा, तब वह केवल एक नए RFC का संदर्भ लेगा जिसने स्टैंडर्ड ट्रैक पूरा किया हो, लेकिन वह अभी भी STD 1 होगा। उत्तम मौजूदा व्यवहार इसी तरह काम करते हैं; BCP n किसी विशिष्ट RFC या RFC के सेट को संदर्भित करता है, लेकिन जो RFC या RFC के सेट, समय के साथ बदल सकते हैं।

इंटरनेट मानकों की निश्चित सूची ख़ुद एक इंटरनेट मानक है, STD 1: इंटरनेट आधिकारिक प्रोटोकॉल मानक .^[4]

स्थिति "सूचनात्मक"

एक सूचनात्मक RFC, पहली अप्रैल के जोक से लेकर RFC 1591 जैसे व्यापक रूप से पहचाने जाने वाले आवश्यक RFC जैसे स्वामित्व प्रोटोकॉल तक कुछ भी हो सकते हैं। कुछ सूचनात्मक RFC आपकी जानकारी के लिए (FYI) जैसी उप-श्रृंखला के रूप में हो सकते हैं। जहां आज शायद ही कभी जोड़े जाते हों, कुछ पुराने FYI अभी भी दिलचस्प हैं, उदाहरण के लिए, FYI 18 (RFC 1983), इंटरनेट उपयोगकर्ताओं की शब्दावली . FYI 17, द ताओ ऑफ़ IETF अब RFC 4677 है, जो 2006 में प्रकाशित हुआ।

स्थिति "प्रायोगिक"

एक प्रायोगिक RFC, एक IETF दस्तावेज़ या RFC संपादक के लिए कोई व्यक्तिगत प्रस्तुति हो सकती है। सिद्धांत रूप में यह वास्तव में प्रायोगिक है; व्यवहार में कुछ दस्तावेज़ों को स्टैंडर्ड ट्रैक पर बढ़ावा नहीं दिया जाता है, क्योंकि प्रक्रियागत विवरणों के लिए कोई स्वयंसेवक मौजूद नहीं हैं।

स्थिति "उत्तम मौजूदा व्यवहार"

उत्तम मौजूदा व्यवहार (BCP) उप-श्रृंखला प्रशासनिक दस्तावेजों और अन्य पाठों को संग्रहित करते हैं, जिन्हें आधिकारिक नियम माना जाता है और वे न केवल सूचनात्मक हैं, बल्कि जो ओवर द वायर डाटा को प्रभावित नहीं करते. स्टैंडर्ड ट्रैक और BCP के बीच की सीमा अक्सर स्पष्ट नहीं होती है। यदि कोई दस्तावेज़ केवल इंटरनेट मानक प्रक्रिया को प्रभावित करता है, जैसे कि BCP 9, या IETF प्रशासन, तो वह निश्चित रूप से BCP है। यदि वह केवल इंटरनेट असाइन्ड नंबर्स अथॉरिटी (IANA) रजिस्ट्रियों के लिए नियम और विनियमों को परिभाषित करता है तो वह अधिक स्पष्ट नहीं; इनमें अधिकांश दस्तावेज़ BCP हैं, पर कुछ स्टैंडर्ड ट्रैक पर भी हैं।

BCP श्रृंखला, इंटरनेट मानकों का व्यवहार कैसे करें, के लिए तकनीकी सिफ़ारिशों को भी आवृत करती हैं; उदाहरण के लिए Dos हमलों को अधिक मुश्किल बनाने के लिए सोर्स फ़िल्टरिंग के इस्तेमाल की सिफारिश (RFC 2827: "नेटवर्क इनग्रेस फ़िल्टरिंग: डिफ़ीटिंग डिनायल ऑफ़ सर्विस अटैक्स व्हिच एम्पलॉय IP सोर्स अड्रेस स्पूफ़िंग ") है BCP 38.

स्थिति "ऐतिहासिक"

ऐतिहासिक RFC वह है जिसे नए संस्करण से अप्रचलित कर दिया गया है, जो ऐसे प्रोटोकॉल को प्रलेखित करता है जिसे वर्तमान इंटरनेट में रोचक नहीं माना जाता, या जिसे अन्य कारणों से स्टैंडर्ड ट्रैक से हटा दिया गया है। कुछ अप्रचलित RFC ऐतिहासिक रूप में वर्गीकृत नहीं किए गए हैं, क्योंकि इंटरनेट मानक प्रक्रिया आम तौर पर स्टैंडर्ड ट्रैक RFC से निचले स्तर के अन्य RFC में नियामक संदर्भों को अनुमत नहीं करती है। साथ ही, बहुत कम लोग RFC को ऐतिहासिक रूप में वर्गीकृत कराने और उस आधार पर सभी RFC को नियामक रूप से अद्यतन करने के लिए अपेक्षित प्रक्रियागत विवरणों के ज़रिए गुज़रने में दिलचस्पी रखते हैं।

स्थिति "अज्ञात"

स्थिति अज्ञात का इस्तेमाल कुछ बहुत पुराने RFC के लिए किया जाता है, जहां यह स्पष्ट नहीं होता कि आज प्रकाशित किए जाने पर दस्तावेज की स्थिति क्या होगी। इनमें से कुछ RFC आज प्रकाशित ही नहीं होंगे; प्रारंभिक RFC अक्सर ऐसे ही थे: टिप्पणी के लिए एक सरल अनुरोध, प्रोटोकॉल निर्दिष्ट करने के उद्देश्य से नहीं, प्रशासनिक प्रक्रिया, या कुछ और, जिनके लिए आज RFC श्रृंखला का प्रयोग किया जाता है।

इन्हें भी देखें

• इंटरनेट प्रयोग नोट
• शैक्षिक प्रकाशन
• अप्रैल फ़ूल्स डे RFC
• RFC की सूची

सन्दर्भ

1. "Stephen D. Crocker, How the Internet Got Its Rules, दि न्यू यॉर्क टाइम्स, 6 अप्रैल 2009". मूल से 2 अप्रैल 2019 को पुरालेखित. अभिगमन तिथि 14 जून 2020.
2. "RFC Index". RFC Editor. 2008-05-25. मूल से 9 फ़रवरी 2010 को पुरालेखित. अभिगमन तिथि 2008-05-26.
3. Huitema, C.; Postel, J.; Crocker, S. (1995). "Not All RFCs are Standards (RFC 1796)". The Internet Engineering Task Force. मूल से 27 अक्तूबर 2010 को पुरालेखित. अभिगमन तिथि 2008-05-19. [E]ach RFC has a status…: Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic. नामालूम प्राचल |month= की उपेक्षा की गयी (मदद)सीएस1 रखरखाव: एक से अधिक नाम: authors list (link)
4. "Internet Official Protocol Standards (STD 1)" (plain text). RFC Editor. 1995. अभिगमन तिथि 2008-05-19. नामालूम प्राचल |month= की उपेक्षा की गयी (मदद)

अतिरिक्त पठन

• Scott O. Bradner (1996). "RFC 2026: The Internet Standards Process — Revision 3". IETF. मूल से 29 मार्च 2010 को पुरालेखित. अभिगमन तिथि 2008-12-20. नामालूम प्राचल |month= की उपेक्षा की गयी (मदद)

बाहरी कड़ियाँ

• IETF's RFC page
• RFC Index (HTML) प्रत्येक RFC के पाठ के साथ, यह भी उल्लेख करता है कि यह कौन से अन्य RFC को "अद्यतन" करता है या किसके "द्वारा अद्यतन" किया गया है।
• RFC Database
• RFC Editor
• RFC Errata
• RFC Frequently Asked Questions
• RFC Index (पाठ)
• Official RFC standardization status

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.