जब अलग-अलग कंपनियों के बनाए प्रोग्राम इंटरनेट पर एक-दूसरे से जुड़ते हैं, तो विनिर्देश के किसी एक अक्षर की भी अलग व्याख्या होने पर संचार टूट सकता है। फिर भी शुरुआती इंटरनेट ऐसे छोटे अंतरों के बीच किसी तरह जुड़ा रहा। इस सफलता का रहस्य समझाने के लिए अक्सर ‘पोस्टेल के नियम (Postel's Law)’ का उल्लेख किया जाता है।
सरल शब्दों में, पोस्टेल का नियम संचार की रूपरेखा बनाने का यह सिद्धांत है कि ‘भेजते समय विनिर्देश का सख्ती से पालन करें और प्राप्त करते समय, जहाँ तक अर्थ समझना संभव हो, उदार रहें।’ औपचारिक दस्तावेज़ों में इसे ‘सुदृढ़ता का सिद्धांत (Robustness Principle)’ भी कहा जाता है।
इस सामग्री में हम क्रम से देखेंगे कि पोस्टेल का नियम कहाँ से आया, इंटरनेट को इसकी आवश्यकता क्यों थी, रोज़मर्रा के जीवन और सॉफ़्टवेयर विकास में यह कैसे दिखाई देता है, और आज इसकी आलोचना क्यों होती है।
पोस्टेल के नियम को समझना
पोस्टेल का नियम कहाँ से आया?
इस नियम का नाम अमेरिकी कंप्यूटर वैज्ञानिक जोनाथन पोस्टेल (Jonathan B. Postel, 1943–1998) के नाम पर पड़ा। उन्होंने दक्षिणी कैलिफ़ोर्निया विश्वविद्यालय के सूचना विज्ञान संस्थान (USC ISI) में काम किया और 1969 से अपने निधन तक इंटरनेट मानकों के दस्तावेज़ों की RFC शृंखला का संपादन संभाला। उन्होंने पतों और संख्याओं का प्रबंधन करने वाले IANA में भी केंद्रीय भूमिका निभाई।
1980 के 1वें महीने में पोस्टेल द्वारा संकलित इंटरनेट विनिर्देश RFC 760 (इंटरनेट प्रोटोकॉल) और RFC 761 (ट्रांसमिशन कंट्रोल प्रोटोकॉल) में सुदृढ़ता का सिद्धांत प्रकाशित हुआ। RFC 760 के मसौदे में इसी तरह का एक वाक्य था, और “भेजते समय संयम बरतें, प्राप्त करते समय उदार रहें (be conservative in what you do, be liberal in what you accept from others)” वाला वाक्य ठीक इसी रूप में RFC 761 में प्रकाशित हुआ। यह बात 1981 के TCP मानक RFC 793 में भी शामिल रही और बाद में ‘पोस्टेल के नियम’ के नाम से प्रसिद्ध हुई।
पोस्टेल का मानना था कि विनिर्देश कितना भी विस्तृत क्यों न हो, अलग-अलग लोग उसकी अलग व्याख्या कर सकते हैं। इसलिए उन्होंने सलाह दी कि भेजने वाला पक्ष साफ़ और मानक के अनुरूप डेटा तैयार करे, और प्राप्त करने वाला पक्ष अर्थ स्पष्ट होने पर प्रारूप की छोटी त्रुटियों पर भी आपत्ति न करे।
भेजते समय सख्ती और प्राप्त करते समय उदारता क्यों?
इंटरनेट कोई ऐसा बंद नेटवर्क नहीं है जिसमें केवल एक कंपनी की बनाई मशीनें इस्तेमाल होती हों। अलग-अलग ऑपरेटिंग सिस्टम, भाषाओं और संस्करणों के प्रोग्रामों को एक ही प्रोटोकॉल के अनुसार संवाद करना होता है। ऐसे में यदि दोनों पक्ष ‘ज़रा भी अंतर होने पर अस्वीकार’ करें, तो व्याख्या का छोटा-सा अंतर भी संपर्क तोड़ देता है।
(1) भेजने वाले पक्ष की सख्ती
यदि प्रारूप, लंबाई और आवश्यक मदों को विनिर्देश के अनुसार ठीक से भरा जाए, तो दूसरा पक्ष चाहे जिस कार्यान्वयन का उपयोग करे, उसके लिए समझना आसान हो जाता है। अपनी सुविधा के लिए विनिर्देश का विस्तार करने पर दूसरे पक्ष को उन सभी बदलावों को स्वीकार करना पड़ता है।
(2) प्राप्त करने वाले पक्ष की उदारता
यदि डेटा का अर्थ स्पष्ट है, तो प्रारूप की मामूली समस्या के कारण उसे पूरा खारिज नहीं किया जाता। इसी तरह अलग-अलग कार्यान्वयन कुछ समय तक साथ काम कर सकते हैं।
(3) अंतरसंचालनीयता को प्राथमिकता
यह पूर्ण मेल से पहले ‘फ़िलहाल संवाद हो सके’ को प्राथमिकता देने का दृष्टिकोण है। शुरुआती दौर जैसे परिवेश में, जहाँ कार्यान्वयन अलग-अलग थे, इस उदारता ने नेटवर्क के विस्तार को सुगम बनाया।
(4) विनिर्देश की अपूर्णता को स्वीकार करना
इसमें माना जाता है कि दस्तावेज़ में कमियाँ या अस्पष्ट अभिव्यक्तियाँ हो सकती हैं। इसलिए मुख्य बात यह संतुलन है कि प्राप्त करने वाले पक्ष को कुछ गुंजाइश दी जाए, लेकिन भेजने वाला पक्ष उस गुंजाइश पर निर्भर रहने के बजाय अधिक सावधानी बरते।
रोज़मर्रा के जीवन और सॉफ़्टवेयर विकास में पोस्टेल का नियम
यह सिद्धांत केवल नेटवर्क तक सीमित नहीं है। वेब ब्राउज़र का थोड़ा त्रुटिपूर्ण HTML भी स्क्रीन पर दिखा देना और ईमेल प्रोग्राम का गलत प्रारूप वाली चिट्ठी को किसी तरह खोलकर दिखाने की कोशिश करना भी इसी भावना के क़रीब है।
सॉफ़्टवेयर इंटरफ़ेस में भी इसी तरह के चुनाव बार-बार सामने आते हैं।
- सार्वजनिक इंटरफ़ेस (Public API): बाहर भेजे जाने वाले अनुरोधों और उत्तरों में केवल दस्तावेज़ में निर्धारित प्रारूप का उपयोग करें और चुपके से प्रयोगात्मक फ़ील्ड न जोड़ें।
- इनपुट सत्यापन (Input Validation): आवश्यक और ख़तरनाक मानों की सख्ती से जाँच करें, लेकिन समान अर्थ वाले मामूली लेखन अंतरों को स्वीकार करना है या नहीं, इस पर टीम के नियम पहले से तय करें।
- पिछले संस्करणों के साथ संगतता (Backward Compatibility): यदि नया संस्करण पुराने डेटा को पढ़ सकता है, तो पूरे सिस्टम को एक साथ बदलना आवश्यक नहीं होता।
- लॉग और त्रुटि संदेश (Clear Errors): उदारता से स्वीकार करने पर भी यह दर्ज करना चाहिए कि गड़बड़ी कहाँ थी, ताकि बाद में विनिर्देश सुधारा जा सके।
सरल शब्दों में, यह ‘अपनी बात स्पष्ट रूप से कहें और दूसरे की बात सुनते समय उसका आशय समझें’ वाले दृष्टिकोण को मशीनों के बीच संवाद पर लागू करना है।
आज इस नियम पर दोबारा विचार क्यों किया जाता है?
पोस्टेल के नियम ने इंटरनेट के बड़े पैमाने पर विस्तार में मदद की, लेकिन समय के साथ इसके दुष्प्रभाव भी सामने आए। प्राप्त करने वाला पक्ष बहुत अधिक उदार हो, तो अस्पष्ट व्याख्याएँ जमा होती जाती हैं और उन कमियों का दुरुपयोग करने वाले हमले आसानी से पैदा हो सकते हैं। साथ ही, गलत प्रारूप को चुपचाप स्वीकार कर लेने पर स्वयं विनिर्देश लंबे समय तक बिना सुधरे रह सकता है।
हाल के इंटरनेट मानक संबंधी विमर्श में यह आलोचना सामने आई है कि “केवल उदारता से दीर्घकालिक अंतरसंचालनीयता की गारंटी नहीं मिलती।” मार्टिन थॉमसन (Martin Thomson) और अन्य लोगों ने बताया कि विनिर्देश को स्थिर मानकर केवल उदारता पर ज़ोर देने से अस्पष्टता ही मानक की तरह स्थापित हो सकती है।
इसलिए आज का व्यावहारिक दृष्टिकोण इस सिद्धांत को त्यागने के बजाय इसके संतुलन को बेहतर बनाने के अधिक क़रीब है।
- भेजने में सख्ती (Strict Send): बाहर जाने वाले डेटा को विनिर्देश के अनुरूप बनाएँ और सत्यापन उपकरण की जाँच में सफल कराएँ।
- स्वीकार करने में सावधानी (Careful Accept): दस्तावेज़ों और परीक्षणों के माध्यम से स्वीकार्य बदलावों की सीमा स्पष्ट करें और उसके बाहर की चीज़ों को अस्वीकार करें।
- विनिर्देशों को अद्यतन करना (Evolve Specs): व्यवहार में बार-बार दिखने वाले अंतरों को चुपचाप दबाने के बजाय विनिर्देश और उदाहरण सुधारते रहें।
- सुरक्षा को प्राथमिकता (Security First): पहले जाँचें कि उदारता हमले की संभावित गुंजाइश बढ़ा तो नहीं रही।
पोस्टेल का नियम शुरुआती इंटरनेट की वह समझ है जिसमें ‘संपूर्ण विनिर्देश’ से पहले ‘अलग-अलग कार्यान्वयन साथ कैसे काम करें’ पर विचार किया गया था। साथ ही, यह इस बात की चेतावनी भी है कि उदारता अस्पष्टता और जोखिम बढ़ा सकती है।
भेजते समय अधिक स्पष्ट रहें और प्राप्त करते समय आशय समझें, लेकिन सीमाएँ साफ़ रखें—एक-दूसरे को जोड़ने वाले सिस्टम बनाने की दिशा में यही पहला कदम है।
