19 ਦਸੰ 2025·8 ਮਿੰਟ
ਜੌਨ ਪੋਸਟਲ ਅਤੇ ਇੰਟਰਨੈੱਟ ਮਿਆਰਾਂ ਪਿੱਛੇ ਦੀ ਅਮਲੀ ਸਭਿਆਚਾਰ
ਜੌਨ ਪੋਸਟਲ ਦੀ ਅਮਲੀ ਮਿਆਰ-ਦ੍ਰਿਸ਼ਟੀ ਕਿਵੇਂ ਇੰਟਰਨੈੱਟ ਗਵਰਨੈਂਸ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ—RFCs, IETF ਆਦਤਾਂ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਕੋਆਰਡੀਨੇਸ਼ਨ ਰਾਹੀਂ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਇੰਟਰਓਪਰੇਬਿਲ ਬਣਾਉਣਾ।
ਜੌਨ ਪੋਸਟਲ ਦੀ ਅਮਲੀ ਮਿਆਰ-ਦ੍ਰਿਸ਼ਟੀ ਕਿਵੇਂ ਇੰਟਰਨੈੱਟ ਗਵਰਨੈਂਸ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ—RFCs, IETF ਆਦਤਾਂ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਕੋਆਰਡੀਨੇਸ਼ਨ ਰਾਹੀਂ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਇੰਟਰਓਪਰੇਬਿਲ ਬਣਾਉਣਾ।
ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਰ ਨੈੱਟਵਰਕਿੰਗ "ਇੱਕ ਹੀ ਨੈੱਟਵਰਕ ਜੋ ਵੱਡਾ ਹੋ ਗਿਆ" ਨਹੀਂ ਸੀ। ਇਹ ਕਈ ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕ ਸਨ—ਵੱਖ-ਵੱਖ ਸੰਸਥਾਵਾਂ ਵੱਲੋਂ ਚਲਾਏ ਜਾਂਦੇ, ਵੱਖ-ਵੱਖ ਹਾਰਡਵੇਅਰ 'ਤੇ ਬਣੇ, ਵੱਖ-ਵੱਖ ਲਕੜ੍ਹਾਂ ਵਾਲੀਆਂ ਫੰਡਿੰਗ ਅਤੇ ਵੇਖੇ-ਸੁਨੇ ਮਨੋਰਥਾਂ ਨਾਲ। ਕੁਝ ਅਕਾਦਮਿਕ ਤੇ ਸਹਿਯੋਗੀ ਸਨ, ਕੁਝ ਫੌਜੀ ਅਤੇ ਕੁਝ ਵਪਾਰਿਕ। ਹਰ ਨੈੱਟਵਰਕ ਖੁਦ ਵਿੱਚ ਠੀਕ ਕੰਮ ਕਰ ਸਕਦਾ ਸੀ ਪਰ ਹੋਰਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਵਿੱਚ ਅਸਮਰਥ ਜਾਂ ਅਨिचਛੁਕ ਹੋ ਸਕਦਾ ਸੀ।
ਦੂਰੋਂ ਵੇਖਣ ਤੇ ਚੈਲੰਜ ਸਿੱਧਾ ਸੀ: ਤੁਸੀਂ ਉਹਨਾਂ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਕਿਵੇਂ ਜੋੜਦੇ ਹੋ ਜਿਹੜੇ ਉਹੀ ਨਿਯਮ ਸਾਂਝੇ ਨਹੀਂ ਕਰਦੇ?
ਐਡਰੈੱਸ ਫਾਰਮੇਟ ਵੱਖਰੇ ਸਨ। ਸੁਨੇਹਿਆਂ ਦੇ ਆਕਾਰ ਵੱਖਰੇ ਸਨ। ਐਰਰ ਹੈਂਡਲਿੰਗ ਵੱਖਰੀ ਸੀ। ਬੁਨਿਆਦੀ ਉਮੀਦਾਂ ਵੀ—"ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਨੂੰ ਕਿੰਨਾ ਉਡੀਕ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?"—ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਸਨ। ਸਾਂਝੇ ਸਮਝੌਤਿਆਂ ਦੇ ਬਿਨਾ ਤਸੀਂ ਇੱਕ ਇੰਟਰਨੈੱਟ ਨਹੀਂ ਬਣਾਂਦੇ—ਤੁਸੀਂ ਕਸਟਮ ਬ੍ਰਿਜਾਂ ਨਾਲ ਜੁੜੇ ਟੁਕੜੇ-ਟੁਕੜੇ ਟਾਪੂਆਂ ਪਾਉਂਦੇ ਹੋ।
ਉਹ ਬ੍ਰਿਜ ਬਣਾਉਣਾ ਮਹਿੰਗਾ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਟੁੱਟਣ ਵਾਲਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਲੋਕਾਂ ਨੂੰ ਕਿਸੇ ਵਿਨਡਰ ਜਾਂ ਖਾਸ ਨੈੱਟਵਰਕ ਪਰਚਾਲਕ ਦੇ ਅਧੀਨ ਬੰਨ੍ਹ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ "ਅਨੁਵਾਦ ਪਰਤ" ਮੁਕਾਬਲੇ ਦੀ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦੀ ਹੈ।
ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਅਸੀਂ ਸ਼ੁਰੂਆਤੀ ਨੈੱਟਵਰਕਿੰਗ ਨੂੰ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਜੰਗ ਵਜੋਂ ਵੇਖਦੇ ਹਾਂ ਜਿਸ ਵਿੱਚ "ਸਭ ਤੋਂ ਵਧੀਆ" ਤਕਨਾਲੋਜੀ ਜਿੱਤਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ, ਅਕਸਰ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਤਕਨੀਕੀ ਸੁੰਦਰਤਾ ਜਾਂ ਬਾਜ਼ਾਰ ਕਬਜ਼ੇ ਤੋਂ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀ ਸੀ। ਇੱਕ ਐਸਾ ਪ੍ਰੋਟੋਕੋਲ ਜੋ ਥੋੜ੍ਹਾ ਅਪਰਿਪੂਰਨ ਹੋਵੇ ਪਰ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕੇ, ਉਹ ਇੱਕ ਸੁਤੰਤਰ ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਹੀ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਿਧਾਂਤਕ ਰੂਪ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲੋਂ ਵੱਧ ਲੋਕਾਂ ਨੂੰ ਜੁੜਨ ਦਾ ਮੌਕਾ ਦੇ ਸਕਦਾ ਹੈ।
ਇੰਟਰਨੈੱਟ ਦੀ ਸਫਲਤਾ ਇੱਕ ਐਸੇ ਸਭਿਆਚਾਰ 'ਤੇ ਨਿਰਭਰ ਸੀ ਜੋ ਸੰਸਥਾਵਾਂ ਅਤੇ ਸਰਹੱਦਾਂ ਪਾਰ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ—ਭਾਵੇਂ ਕਿਸੇ ਇਕਾਈ ਕੋਲ ਸਹਿਯੋਗ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰਨ ਦੀ ਅਧਿਕਾਰਤਾ ਨਾ ਹੋਵੇ।
ਜੌਨ ਪੋਸਟਲ ਇਸ ਸਹਿਯੋਗ ਦੇ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਰਖਵਾਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਬਣੇ। ਨਾ ਇਸ ਲਈ ਕਿ ਉਸ ਦੇ ਕੋਲ ਵਿਸ਼ਾਲ ਸਰਕਾਰੀ ਅਧਿਕਾਰ ਸੀ, ਪਰ ਇਸ ਲਈ ਕਿ ਉਸ ਨੇ ਉਹ ਆਦਤਾਂ ਅਤੇ ਨਾਰਮ ਬਣਾਏ ਜੋ ਸਾਂਝੇ ਮਿਆਰਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀਆਂ ਸਨ: ਸਾਫ਼ ਲਿਖੋ, ਅਸਲੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ 'ਚ ਟੈਸਟ ਕਰੋ, ਅਤੇ boring ਪਰ ਜਰੂਰੀ ਵਿਵਰਣਾਂ (ਜਿਵੇਂ ਨਾਮ ਅਤੇ ਨੰਬਰ) ਦੀ ਸੰਯੋਜਨਾ ਕਰੋ ਤਾਂ ਜੋ ਹਰ ਕੋਈ ਇੱਕ ਰਾਹ 'ਤੇ ਰਹੇ।
ਇਹ ਕਿਸੇ ਪੈਕਟ ਫਾਰਮੇਟ ਦਾ ਤਕਨੀਕੀ ਡਾਈਵ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਅਮਲੀ ਅਭਿਆਸ ਅਤੇ ਸ਼ਾਸਕੀ ਚੋਣਾਂ ਬਾਰੇ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਨੂੰ ਸੰਭਵ ਬਣਾਇਆ: RFCs ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਮਿਆਰ-ਸਭਿਆਚਾਰ, IETF ਦਾ ਕੰਮ ਕਰਨ ਦਾ ਅੰਦਾਜ਼, ਅਤੇ ਉਹ ਸ਼ਾਂਤ ਸਮਨਵਯ ਕੰਮ ਜੋ ਵਧ ਰਹੇ ਨੈੱਟਵਰਕ ਨੂੰ ਅਸੰਗਠਿਤ "ਮਿਨੀ-ਇੰਟਰਨੈੱਟਸ" ਵਿੱਚ ਫਰਕਣ ਤੋਂ ਰੋਕਦਾ ਰਿਹਾ।
ਜੌਨ ਪੋਸਟਲ ਕੋਈ ਮਸ਼ਹੂਰ CEO ਜਾਂ ਸਰਕਾਰੀ ਅਧਿਕਾਰੀ ਨਹੀਂ ਸੀ। ਉਹ ਇੱਕ ਕਾਰਜਕਾਰੀ ਇੰਜੀਨੀਅਰ ਅਤੇ ਐਡੀਟਰ ਸੀ ਜੋ UCLA ਅਤੇ ਬਾਅਦ ਵਿੱਚ Information Sciences Institute (ISI) 'ਚ ਉਸ ਨੇ ਆਪਣੀ ਕੈਰੀਅਰ ਦੀ ਬਹੁਤ ਹਿੱਸਾ ਸਮਾਂ ਬਿਤਾਇਆ, ਜਿੱਥੇ ਉਸ ਨੇ ਸ਼ੁਰੂਆਤੀ ਨੈੱਟਵਰਕਿੰਗ ਦੇ ਵਿਚਾਰਾਂ ਨੂੰ ਸਾਂਝੇ ਤੇ ਵਰਤੋਂਯੋਗ ਅਭਿਆਸਾਂ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।
ਜੇ ਤੁਸੀਂ ਕਦੇ ਡੋਮੇਨ ਨਾਮ ਲਿਖਿਆ, ਈਮੇਲ ਭੇਜੀ, ਜਾਂ ਵੱਖ-ਵੱਖ ਵਿਕਰੇਤਿਆਂ ਦੇ ਜੰਤਰਾਂ ਨੂੰ "ਸਿਰਫ਼ ਚੱਲਣ" 'ਤੇ ਨਿਰ ਭਰੋਸਾ ਕੀਤਾ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਤਰ੍ਹਾਂ ਦੀ ਕੋਆਰਡੀਨੇਸ਼ਨ ਤੋਂ ਲਾਭਾਨਵਿਤ ਹੋਏ ਹੋ ਜੋ ਪੋਸਟਲ ਨੇ ਦਹਾਕਿਆਂ ਤੱਕ ਖਾਮੋਸ਼ੀ ਨਾਲ ਪ੍ਰਦਾਨ ਕੀਤੀ।
ਪੋਸਟਲ ਪ੍ਰਭਾਵਸ਼ाली ਇਸ ਲਈ ਸਨ ਕਿਉਂਕਿ ਉਹ ਮਿਆਰਾਂ ਨੂੰ ਲੋਕਾਂ ਲਈ ਇੱਕ ਜਨਤਕ ਯੂਟਿਲਿਟੀ ਵਾਂਗ ਵਿਉਂ ਕਰਦੇ। ਉਹਨਾਂ ਦੀ ਲਿਖਾਈ ਸਾਫ਼, ਵਾਦ-ਵਿਵਾਦ ਵਿੱਚ ਧੈਰਯਸ਼ੀਲ ਅਤੇ ਵਿਵਰਣਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਜੀ-ਤੋੜੀ ਸਥਿਰਤਾ ਸੀ। ਇਹ ਮਿਲੀ-ਜੁਲੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਉਸ ਸਮੁਦਾਇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸਨ ਜਿੱਥੇ ਝਗੜੇ ਅਕਾਦਮਿਕ ਨਹੀਂ ਸਨ—ਉਹ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਰ ਸਕਦੇ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਅਲੱਗ ਕਰ ਸਕਦੇ ਸਨ।
ਉਸ ਨੇ ਉਹ ਨਿਰਮਲ ਕੰਮ ਵੀ ਕੀਤਾ: ਤਕਨੀਕੀ ਨੋਟਾਂ ਦਾ ਸੰਪਾਦਨ ਅਤੇ ਕਯੂਰੈਸ਼ਨ, ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ, ਗਰੁੱਪਾਂ ਨੂੰ ਫੈਸਲੇ ਵੱਲ ਧਕਕਣ, ਅਤੇ ਸਾਂਝੇ ਰਜਿਸਟਰੀਆਂ ਨੂੰ ਸੰਗਠਿਤ ਰੱਖਣਾ। ਇਹ ਸਥਿਰ, ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਸੇਵਾ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਰੇਫਰੰਸ ਪੌਇੰਟ ਬਣਾਉਂਦੀ ਜਦੋਂ ਤਣਾਅ ਵਧੇ ਜਾਂ ਟਾਈਮਲਾਈਨ ਲੰਬੀਆਂ ਹੋ ਗਈਆਂ।
ਪੋਸਟਲ ਦੇ ਪ੍ਰਭਾਵ ਦਾ ਇਕ ਮੁੱਖ ਹਿੱਸਾ ਇਹ ਸੀ ਕਿ ਇਹ ਰਾਜੀ ਅਧਿਕਾਰ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਸੀ। ਲੋਕ ਉਸ ਦੀ ਗੱਲ ਸੁਣਦੇ ਸਨ ਕਿਉਂਕਿ ਉਹ ਸਥਿਰ, ਨਿਰਪੱਖ ਅਤੇ ਡੂੰਘੀ ਜਾਣਕਾਰੀ ਵਾਲੇ ਸੀ—ਅਤੇ ਕਿਉਂਕਿ ਉਹ ਨੇ ਹਮੇਸ਼ਾ ਕਾਮ ਕੀਤਾ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਉਹ "ਅਧਿਕਾਰ" ਉਸ ਤਰੀਕੇ ਨਾਲ ਰੱਖਦੇ ਸਨ ਜਿਸ ਤਰ੍ਹਾਂ ਚੰਗੇ ਮੇਨਟੇਨਰ ਰੱਖਦੇ ਹਨ: ਮਦਦਗਾਰ, ਭਵਿੱਖਬਾਣੀਯੋਗ ਅਤੇ ਮੁਸ਼ਕਲ ਵਿੱਚ ਬਦਲਣ ਜੋਗ ਨਹੀਂ।
ਸ਼ੁਰੂਆਤੀ ਇੰਟਰਨੈੱਟ ਯੂਨੀਵਰਸਿਟੀਆਂ, ਲੈਬਾਂ, ਠੇਕਾਦਾਰੀਆਂ ਅਤੇ ਵਿਕਰੇਤਿਆਂ ਦਾ ਇਕ ਪੈਚਵਰਕ ਸੀ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਤਰਜੀਹਾਂ ਵੱਖ-ਵੱਖ ਸਨ। ਪੋਸਟਲ ਦੀ ਕਰੈਡਿਬਿਲਿਟੀ ਉਨ੍ਹਾਂ ਗਰੁੱਪਾਂ ਨੂੰ ਫਿਰ ਵੀ ਸਹਿਯੋਗ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਸੀ। ਜਦੋਂ ਕੋਈ ਇਹ ਭਰੋਸਾ ਰੱਖਦਾ ਸੀ ਕਿ ਫੈਸਲਾ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਲਈ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ—ਨ ਕਿ ਰਾਜਨੀਤੀ ਜਾਂ ਨਫੇ ਲਈ—ਉਹ ਆਪਣੀਆਂ ਸਿਸਟਮਾਂ ਨੂੰ ਝੁਕਾਉਣ ਲਈ ਤਿਆਰ ਹੋ ਜਾਂਦੇ ਸਨ, ਭਾਵੇਂ ਉਸਦੇ ਲਈ ਸਮਝੌਤਾ ਕਰਨਾ ਪਏ।
RFC—ਜਿਸਦਾ ਪੂਰਾ ਨਾਮ Request for Comments ਹੈ—ਇੱਕ ਸਰਵજનਿਕ ਮੈਮੋ ਹੁੰਦਾ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਸੇ ਇੰਟਰਨੈੱਟ ਪ੍ਰੋਟੋਕੋਲ ਜਾਂ ਅਭਿਆਸ ਨੂੰ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਨੂੰ ਸੋਚੋ: "ਇਥੇ ਵਿਚਾਰ ਹੈ, ਫਾਰਮੈਟ, ਨਿਯਮ—ਦੱਸੋ ਕਿ ਕੀ ਟੁੱਟਦਾ ਹੈ।" ਕੁਝ RFC ਸ਼ੁਰੂਆਤੀ ਖਾਕੇ ਹੁੰਦੇ ਹਨ; ਹੋਰ ਵਿਆਪਕ ਮਿਆਰ ਬਣ ਜਾਂਦੇ ਹਨ। ਮੁੱਖ ਆਦਤ ਇੱਕੋ ਹੀ ਰਹਿੰਦੀ: ਇਸਨੂੰ ਲਿਖੋ ਤਾਂ ਜੋ ਹੋਰ ਲੋਕ ਵੀ ਇੱਕੋ ਸਫੇ ਤੋਂ ਬਣਾਉਣ ਸ਼ੁਰੂ ਕਰ ਸਕਣ।
RFCs ਜਾਣ-ਬੂਝ ਕੇ ਅਮਲੀ ਬਣਾਏ ਗਏ ਸਨ। ਉਹਨਾਂ ਦਾ ਲਕੜ ਇੰਪਲੀਮੈਂਟ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਉਪਯੋਗੀ ਹੋਵਾਂ—ਕਮੇਟੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਲਈ ਨਹੀਂ। ਇਸਦਾ ਅਰਥ ਸੀ ਜਾਣਕਾਰੀ: ਸੁਨੇਹਾ ਫਾਰਮੇਟ, ਐਰਰ ਕੇਸ, ਉਦਾਹਰਨਾਂ ਅਤੇ ਉਹ ਨਿਰਸ ਪਰ ਜਰੂਰੀ ਸਪੱਸ਼ਟੀਕਰਨ ਜਿਹੜੇ ਦੋ ਟੀਮਾਂ ਨੂੰ ਇਕੋ ਵਾਕ ਤੋਂ ਵੱਖ-ਵੱਖ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦਾ।
ਇਸ ਤੋਂ ਵੱਧ ਜ਼ਰੂਰੀ, RFCs ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੇ ਜਾਂਦੇ ਸਨ ਕਿ ਉਹ ਟੈਸਟ ਅਤੇ ਸੁਧਾਰਣ ਯੋਗ ਹੋਣ। ਪ੍ਰਕਾਸ਼ਨ ਅੰਤ-ਲਕੀਰ ਨਹੀਂ ਸੀ—ਇਹ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਫੀਡਬੈਕ ਦੀ ਸ਼ੁਰੂਆਤ ਸੀ। ਜੇ ਕੋਈ ਵਿਚਾਰ ਕੋਡ 'ਚ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਪਰ ਨੈੱਟਵਰਕਾਂ ਦੇ ਵਿਚਕਾਰ ਫੇਲ ਹੁੰਦਾ, ਤਾਂ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਅਪਡੇਟ ਜਾਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਸੀ। ਇਹ "ਜਲਦੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਖੁੱਲ੍ਹ ਕੇ ਸੁਧਾਰੋ" ਰਿਦਮ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਜ਼ਮੀਨੀ ਰੱਖਦਾ ਸੀ।
ਜਦੋਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਿੱਜੀ ਰਹਿੰਦੀਆਂ ਹਨ, ਤਦ ਗਲਤਫਹਿਮੀਆਂ ਵਧਦੀਆਂ ਹਨ: ਇੱਕ ਵਿਕਰੇਤਾ ਇਕ ਵਿਆਖਿਆ ਸੁਣਦਾ, ਦੂਜਾ ਕੁਝ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਅਤੇ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਬਾਅਦ ਵਿੱਚ ਸੋਚੀ ਜਾਂਦੀ।
RFCs ਨੂੰ ਜਨਤਾ ਲਈ ਉਪਲਬਧ ਬਣਾ ਕੇ, ਸਭ ਨੂੰ ਇੱਕੋ ਸੰਦਰਭ-ਪਾਠ 'ਤੇ ਇਕਠਾ ਕੀਤਾ ਗਿਆ—ਨਤੀਜੇ ਵਜੋਂ ਵਿਵਾਦ ਹਟਦੇ ਨਹੀਂ ਪਰ ਉਹ ਦਿੱਖੇ ਹੋ ਜਾਂਦੇ ਅਤੇ ਇਸ ਲਈ ਹੱਲ ਯੋਗ ਹੋ ਜਾਂਦੇ।
RFCs ਪਾਠਯੋਗ ਅਤੇ ਸਥਿਰ ਰਹਿਣ ਦੇ ਇੱਕ ਮੁੱਖ ਕਾਰਣ ਸੰਪਾਦਕੀ ਅਨੁਸ਼ਾਸਨ ਸੀ। ਸੰਪਾਦਕ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਲਾਂ ਲਈ ਜੌਨ ਪੋਸਟਲ ਵੀ ਸ਼ਾਮਿਲ ਸਨ) ਸਾਫ਼ਗmia, ਸਥਿਰ ਟਰਮੀਨੋਲੋਜੀ ਅਤੇ ਸਾਂਝੇ ਢਾਂਚੇ ਲਈ ਧੱਕਾ ਦਿੰਦੇ ਸਨ।
ਫਿਰ ਵੱਡਾ ਸਮੁਦਾਇ ਸਮੀਖਿਆ ਕਰਦਾ, ਧਾਰਨਾਵਾਂ 'ਤੇ ਸਵਾਲ ਖੜੇ ਕਰਦਾ ਅਤੇ ਏਜ ਕੇਸਾਂ ਨੂੰ ਸਹੀ ਕਰਦਾ। ਇਹ ਮਿਲਾਪ—ਮਜ਼ਬੂਤ ਸੰਪਾਦਨ ਤੇ ਖੁੱਲ੍ਹੀ ਆਲੋਚਨਾ—ਇਹਨਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਉਹ ਬਣਾਉਂਦਾ ਸੀ ਜੋ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਵੱਲੋਂ ਵੀ ਲਾਗੂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਜਿੰਨ੍ਹਾਂ ਨੇ ਮੂਲ ਕਮਰੇ ਵਿੱਚ ਸਾਂਝ ਨਹੀਂ ਕੀਤੀ ਸੀ।
"Rough consensus and running code" IETF ਦਾ ਤਰੀਕਾ ਹੈ ਦੱਸਣ ਦਾ: ਓਹਨਾਂ ਗੱਲਾਂ 'ਤੇ ਜਿੱਤ ਨਾ ਕਰੋ ਜੋ ਸ਼ਾਇਦ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ—ਉਸ ਦੀ ਥਾਂ ਕੁਝ ਐਸਾ ਬਣਾਓ ਜੋ ਵਾਸਤੇ ਕੰਮ ਕਰਦਾ ਹੋਵੇ, ਹੋਰਾਂ ਨੂੰ ਦਿਖਾਓ, ਫਿਰ ਜੋ ਕੁਝ ਸਿੱਖਿਆ ਉਸਨੂੰ ਲਿਖੋ।
Running code ਕੋਈ ਨਾਅਰਾ ਨਹੀਂ ਕਿ ਸਿਰਫ਼ ਸਾਫਟਵੇਅਰ ਪਿਆਰ ਕਰੋ। ਇਹ ਇੱਕ ਪਰਖ ਮਿਆਰ ਹੈ:
ਅਮਲ ਵਿੱਚ, ਇਹ ਮਿਆਰੀਕਰਨਾਂ ਨੂੰ ਪ੍ਰੋਟੋਟਾਈਪ, ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਡੈਮੋ, ਟੈਸਟ ਸੁੱਟੀ ਅਤੇ बार-ਬਾਰ "ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਠੀਕ ਕਰੋ, ਫਿਰ ਕੋਸ਼ਿਸ਼ ਕਰੋ" ਚੱਕਰ ਵੱਲ ਧਕੇਦਾ ਹੈ।
ਨੈੱਟਵਰਕ ਗ਼ੈਰ-ਸੁਚਿਤ ਹਨ: ਲੇਟੰਸੀ ਵੱਖਰੀ ਹੋ ਸਕਦੀ, ਲਿੰਕ ਡ੍ਰੌਪ ਹੁੰਦੇ ਹਨ, ਮਸ਼ੀਨਾਂ ਵੱਖ-ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਲੋਕ ਅਣਉਮੀਦਤ ਤਰੀਕਿਆਂ ਨਾਲ ਚੀਜ਼ਾਂ ਬਣਾਉਂਦੇ ਹਨ। ਜਲਦੀ ਰਨਿੰਗ ਕੋਡ ਦੀ ਲੋੜ ਨਾਲ, ਸਮੁਦਾਇ ਅਨੰਤ ਫ਼ਿਲੋਸੋਫ਼ੀਕਲ ਬਹਿਸਾਂ ਤੋਂ ਬਚ ਗਿਆ ਜੋ "ਸੋਚੋ ਕਿ ਕੀ ਸਹੀ ਹੈ" 'ਤੇ ਰੁਕੇ ਰਹਿੰਦੇ।
ਫਾਇਦੇ ਪ੍ਰਯੋਗਿਕ ਸਨ:
ਇਹ ਪਹੁੰਚ ਬਿਨਾਂ ਖ਼ਤਰੇ ਨਹੀਂ। "ਪਹਿਲੀ ਚੀਜ਼ ਜੋ ਚੱਲੇ ਉਹ ਜਿੱਤਦੀ" ਪੱਕਾ ਕਰੋ ਤਾਂ ਪਹਿਲੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਦਲਣਾ ਮੁਸ਼ਕਿਲ ਹੋ ਸਕਦਾ। ਇਹ ਉਹਨਾਂ ਟੀਮਾਂ ਨੂੰ ਫਾਇਦਾ ਪਹੁੰਚਾ ਸਕਦੀ ਜਿੰਨ੍ਹਾਂ ਕੋਲ ਜ਼ਿਆਦਾ ਸਰੋਤ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਪਹਿਲਾਂ ਕੋਡ ਬਣਾ ਕੇ ਦਿਸ਼ਾ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਸਭਿਆਚਾਰ ਨੂੰ "ਇਹ ਛੱਡ ਦਿਓ" ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਣ ਲਈ, IETF ਨੇ ਟੈਸਟਿੰਗ ਅਤੇ ਦੁਹਰਾਈ ਉੱਤੇ ਧਿਆਨ ਰੱਖਿਆ। ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਇਵੈਂਟਸ, ਕਈ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਅਤੇ ਧਿਆਨ ਨਾਲ ਸੋਧ ਚੱਕਰ ਇਹ ਵੱਖ ਕੀਤਾ ਕਿ "ਮੇਰੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਅਤੇ "ਸਭ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ" ਵਿੱਚ ਫਰਕ ਕੀ ਹੈ।
ਇਹ ਮੂਲ ਵਿਚਾਰ ਹੈ: ਮਿਆਰਾਂ ਪ੍ਰਮਾਣਿਤ ਅਭਿਆਸਾਂ ਦਾ ਰਿਕਾਰਡ ਹਨ, ਇੱਛਾਵਾਂ ਦੀ ਸੂਚੀ ਨਹੀਂ।
ਇਥੇ "ਫਰੈਗਮੇਂਟੇਸ਼ਨ" ਸਿਰਫ਼ ਕਈ ਨੈੱਟਵਰਕ ਹੋਣ ਦਾ ਮਤਲਬ ਨਹੀਂ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਅਨਕੰਪੈਟਿਬਲ ਨੈੱਟਵਰਕ ਜੋ ਆਪਸ ਵਿੱਚ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਗੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਅਤੇ ਹਰ ਗਰੁੱਪ ਵਲੋਂ ਉਹੀ ਬੁਨਿਆਦੀ ਪਲੰਬਿੰਗ ਦੁਹਰਾਈ ਜਾਂਦੀ ਹੈ।
ਜੇ ਹਰ ਨੈੱਟਵਰਕ, ਵਿਕਰੇਤਾ ਜਾਂ ਸਰਕਾਰੀ ਪ੍ਰੋਜੈਕਟ ਨੇ ਆਪਣਾ ਐਡਰੈੱਸਿੰਗ, ਨਾਂਕਰਨ ਅਤੇ ਟਰਾਂਸਪੋਰਟ ਨਿਯਮ ਬਣਾਏ ਹੁੰਦੇ, ਤਾਂ ਸਿਸਟਮਾਂ ਨੂੰ ਜੋੜਨਾ ਲਗਾਤਾਰ ਅਨੁਵਾਦ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਉਹ ਅਨੁਵਾਦ ਅਕਸਰ ਯਹ ਰੂਪ ਧਾਰਦਾ:
ਨਤੀਜਾ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਜਟਿਲਤਾ ਨਹੀਂ—ਇਹ ਉੱਚ ਕੀਮਤਾਂ, ਹੌਲੀ ਨਵੀਨਤਾ, ਅਤੇ ਘੱਟ ਲੋਕਾਂ ਦੀ ਭਾਗੀਦਾਰੀ ਦਾ ਕਾਰਨ ਬਣਦਾ।
ਸਾਰਵਜਨਿਕ ਮਿਆਰਾਂ ਨੇ ਇੰਟਰਨੈੱਟ ਨੂੰ ਜੋੜਨਾ ਸਸਤਾ ਕੀਤਾ। ਇੱਕ ਨਵੀਂ ਯੂਨੀਵਰਸਿਟੀ ਨੈੱਟਵਰਕ, ਇੱਕ ਸਟਾਰਟਅਪ ISP, ਜਾਂ ਇੱਕ ਹਾਰਡਵੇਅਰ ਵਿਕਰੇਤਾ ਨੂੰ ਖਾਸ ਇਜਾਜ਼ਤ ਜਾਂ bespoke ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਉਹ ਪ੍ਰਕਾਸ਼ਿਤ spec ਲਾਗੂ ਕਰ ਸਕਦੇ ਸਨ ਅਤੇ ਉਮੀਦ ਕਰ ਸਕਦੇ ਸਨ ਕਿ ਹੋਰਾਂ ਨਾਲ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਰਹੇਗੀ।
ਇਸ ਨਾਲ ਪ੍ਰਯੋਗ ਦੀ ਲਾਗਤ ਵੀ ਘਟdi—ਤੁਸੀਂ ਮੌਜੂਦਾ ਪ੍ਰੋਟੋਕੋਲਾਂ ਉੱਤੇ ਨਵੀਂ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਓਪਰੇਟਰ ਨਾਲ ਅਲੱਗ-ਅਲੱਗ ਸਮਝੌਤਾ ਕਰਨ ਦੀ ਲੋੜ ਦੇ।
ਫਰੈਗਮੈਂਟੇਸ਼ਨ ਤੋਂ ਬਚਣ ਲਈ ਸਿਰਫ਼ ਚੰਗੇ ਵਿਚਾਰ ਕਾਫ਼ੀ ਨਹੀਂ; ਇਹੰ ਦੇ ਨਾਲ ਉਹ ਸਹਿਮਤੀ ਲੈਣ ਵਾਲਾ ਸੰਯੋਜਨ ਚਾਹੀਦਾ ਜੋ ਮੁਕਾਬਲੇ ਵਾਲੇ ਲਾਭਾਂ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਵੱਖ-ਵੱਖ ਗਰੁੱਪ ਵੱਖ-ਵੱਖ ਨਤੀਜੇ ਚਾਹੁੰਦੇ—ਵਪਾਰਕ ਫਾਇਦਾ, ਰਾਸ਼ਟਰਵਾਦੀ ਤਰਜੀਹਾਂ, ਖੋਜੀ ਟੀਮਾਂ ਦੇ ਮਨੋਰਥ—ਪਰ ਉਹਨਾਂ ਨੂੰ ਅਜੇ ਵੀ ਇਕ ਸਾਂਝੇ ਨਿਯਮਾਂ ਬਿੰਦੂ ਦੀ ਲੋੜ ਸੀ।
ਤਟਸਥ ਸੰਯੋਜਨ ਨੇ ਸਾਂਝੀ ਜੁੜਨ ਵਾਲੀ ਟਿਸ਼ੂ ਨੂੰ ਸਾਂਝਾ ਰੱਖਿਆ, ਭਾਵੇਂ ਉਪਰ ਉਸ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਵਾਲੇ ਪਾਰਟੀਆਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਕ-ਦੂਜੇ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੀਆਂ। ਇਹ ਇਕ ਚੁਪਚਾਪ, ਅਮਲੀ ਕਿਸਮ ਦੀ ਗਵਰਨੈਂਸ ਹੈ: ਨੈੱਟਵਰਕ ਨੂੰ ਕੰਟਰੋਲ ਨਾ ਕਰਨਾ, ਪਰ ਇਸਨੂੰ ਵਰਕਿਆਂ ਟਾਪੂਆਂ ਵਿੱਚ ਵੰਡਣ ਤੋਂ ਰੋਕਣਾ।
Internet Engineering Task Force (IETF) ਇਸ ਲਈ ਕਾਮਯਾਬ ਹੋਇਆ ਕਿ ਇਸ ਕੋਲ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਅਧਿਕਾਰ ਸੀ—ਜੋ ਝੂਠ ਹੈ। ਇਹ ਇਸ ਲਈ ਕਾਮਯਾਬ ਹੋਇਆ ਕਿ ਇਸਨੇ ਬਹੁਤ ਸਾਰਿਆਂ ਨੂੰ ਇਕ ਅਜਿਹੀ ਨਿਰਭਰਯੋਗ ਢੰਗ ਨਾਲ ਰੱਖਿਆ ਜਿਸ ਨਾਲ ਵੱਖ-ਵੱਖ ਆਜ਼ਾਦ ਲੋਕ ਅਤੇ ਸੰਸਥਾਵਾਂ ਇਹ ਫੈਸਲਾ ਕਰ ਸਕਦੇ ਕਿ ਇੰਟਰਨੈੱਟ ਕਿਵੇਂ ਵਿਹਾਰ ਕਰੇ—ਬਿਨਾਂ ਕਿਸੇ ਇਕ ਕੰਪਨੀ, ਸਰਕਾਰ ਜਾਂ ਲੈਬ ਨੂੰ ਨਤੀਜੇ ਦਾ ਮਾਲਕ ਬਣਾਉਣ ਦੀ ਲੋੜ।
IETF ਨੂੰ ਇੱਕ ਪਬਲਿਕ ਵਰਕਸ਼ਾਪ ਵਾਂਗ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਕੋਈ ਵੀ ਮੈਲਿੰਗ ਲਿਸਟਾਂ ਨੂੰ ਜੋੜ ਸਕਦਾ, ਡਰਾਫਟ ਪੜ੍ਹ ਸਕਦਾ, ਮੀਟਿੰਗਜ਼ 'ਚ ਸ਼ਿਰਕਤ ਕਰ ਸਕਦਾ ਅਤੇ ਟਿੱਪਣੀਆਂ ਕਰ ਸਕਦਾ। ਇਹ ਖੁੱਲ੍ਹਾਪਾ ਜ਼ਰੂਰੀ ਸੀ ਕਿਉਂਕਿ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਕੰਨਿਆਂ 'ਤੇ ਉਬਰਦੀਆਂ ਹਨ—ਜਿੱਥੇ ਵੱਖ-ਵੱਖ ਸਿਸਟਮ ਮਿਲਦੇ ਹਨ—ਅਤੇ ਉਹ ਕੋਨੇ ਕਈ ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਦੇ ਮਲਕੱਬੇ ਹੁੰਦੇ ਹਨ।
ਬਾਹਰੀ ਫੀਡਬੈਕ ਨੂੰ ਪਰੇਸ਼ਾਨੀ ਸਮਝਣ ਦੀ ਥਾਂ, ਪ੍ਰਕਿਰਿਆ ਇਸਨੂੰ ਮੌਜੂਦਾ ਇਨਪੁੱਟ ਵਜੋਂ ਮੰਨਦੀ ਹੈ। ਜੇ ਕੋਈ ਪ੍ਰਸਤਾਵ ਅਸਲੀ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਤੋੜਦਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਤੁਰੰਤ ਇਸਦਾ ਇਤਲਾ਼ ਕਰੇਗਾ।
ਸਾਰਾ ਕੰਮ ਜ਼ਿਆਦਾਤਰ ਵਰਕਿੰਗ ਗਰੁੱਪਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਹਰ ਇੱਕ ਇਕ ਖਾਸ ਸਮੱਸਿਆ 'ਤੇ ਕੇਂਦਰਤ (ਉਦਾਹਰਨ ਵਜੋਂ, ਈਮੇਲ ਦਾ ਫਾਰਮੈਟ, ਜਾਂ ਰਾਊਟਿੰਗ ਜਾਣਕਾਰੀ ਦਾ ਅਦਾਂ-ਪ੍ਰਦਾਂ)। ਵਰਕਿੰਗ ਗਰੁੱਪ ਉਹ ਵੇਲੇ ਬਣਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਸਾਫ਼ ਲੋੜ ਹੋਵੇ, ਕਾਫ਼ੀ ਰੁਚੀ ਵਾਲੇ ਹਿੱਸੇਦਾਰ ਹੋਣ, ਅਤੇ ਇੱਕ ਚਾਰਟਰ ਹੋਵੇ ਜੋ ਸਕੋਪ ਨਿਯਤ ਕਰੇ।
ਤਰੱਕੀ ਆਮ ਤੌਰ 'ਤੇ ਅਮਲੀ ਦਿਸਦੀ ਹੈ:
IETF ਵਿੱਚ ਪ੍ਰਭਾਵ ਉਹਨਾਂ ਲੋਕਾਂ ਨੂੰ ਮਿਲਦਾ ਹੈ ਜੋ ਆ ਕੇ ਕੰਮ ਕਰਦੇ ਹਨ—ਡਰਾਫਟ ਲਿਖਦੇ, ਟੈਸਟ ਕਰਦੇ, ਆਲੋਚਨਾ ਨੂੰ ਜਵਾਬ ਦਿੰਦਿਆਂ ਸੁਧਾਰ ਕਰਦੇ—ਨ ਕਿ ਉਨ੍ਹਾਂ ਦੀ ਨੌਕਰੀ ਦੇ ਨਾਮ ਤੋਂ। ਐਡਿਟਰ, ਇੰਪਲੀਮੈਂਟਰ, ਓਪਰੇਟਰ ਅਤੇ ਸਮੀਖਿਆਕਾਰ ਸਭ ਨਤੀਜੇ ਨੂੰ ਰੂਪ ਦਿੰਦੇ ਹਨ। ਇਹ ਇੱਕ ਉਪਯੋਗੀ ਦਬਾਅ ਬਣਾਉਂਦਾ ਹੈ: ਜੇ ਤੁਸੀਂ ਆਪਣਾ ਵਿਚਾਰ ਅਪਣਵਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਸਮਝਣਯੋਗ ਅਤੇ ਲਾਗੂ ਕਰਨ ਯੋਗ ਬਣਾਉਣਾ ਪਏਗਾ।
ਖੁੱਲ੍ਹਾ ਵਾਦ ਆਸਾਨੀ ਨਾਲ ਬੇਅੰਤ ਬਹਿਸ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ। IETF ਨੇ ਕੁਝ ਨਾਰਮ ਵਿਕਸਤ ਕੀਤੇ ਜਿਹੜੇ ਚਰਚਾ ਨੂੰ ਨੁਕਤੇ 'ਤੇ ਰਖਦੇ:
"ਜਿੱਤ" ਬੋਲਣੀ ਨਹੀਂ—ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਆਜ਼ਾਦੀ ਨਾਲ ਬਣੀਆਂ ਸਿਸਟਮਾਂ ਫਿਰ ਵੀ ਇਕੱਠੇ ਕੰਮ ਕਰ ਲੈਂਦੀਆਂ ਹਨ।
ਜਦੋਂ ਲੋਕ ਇੰਟਰਨੈੱਟ ਕਿਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੀਆਂ ਖੋਜਾਂ ਨੂੰ ਸੋਚਦੇ ਹਨ: TCP/IP, DNS, ਜਾਂ ਵੈੱਬ। ਪਰ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਦਾ ਬਹੁਤ ਸਾਰਾ ਨਿਰਭਰ ਕੁਝ ਘੱਟ ਚਮਕਦਾਰ 'ਤੇ ਹੁੰਦਾ ਹੈ: ਸਭ ਨੇ ਇੱਕੋ ਮਾਸਟਰ ਲਿਸਟਾਂ 'ਤੇ ਸਹਿਮਤ ਹੋਣਾ। ਇਹ IANA (Internet Assigned Numbers Authority) ਦਾ ਮੂਲ ਕੰਮ ਹੈ।
IANA ਇੱਕ ਸਮਨਵਯ ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਸਾਂਝੇ ਰਜਿਸਟਰੀਆਂ ਨੂੰ ਰੱਖਦੀ ਹੈ ਤਾਂ ਜੋ ਵੱਖ-ਵੱਖ ਸਿਸਟਮ ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ ਲਾਈਨ ਅਪ ਕਰ ਸਕਣ। ਜੇ ਦੋ ਅਜ਼ਾਦ ਟੀਮ ਇੱਕੋ ਮਿਆਰ ਤੋਂ ਸਾਫਟਵੇਅਰ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਉਸ ਮਿਆਰ ਨੂੰ ਅਸਲੀ ਦੁਨੀਆ 'ਚ ਮੇਲ ਕਰਨ ਲਈConcrete values—ਨੰਬਰ, ਨਾਮ ਅਤੇ ਲੇਬਲ—ਚਾਹੀਦੇ ਹੁੰਦੇ ਹਨ।
ਕੁਝ ਉਦਾਹਰਨ ਇਸਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦੀਆਂ ਹਨ:
ਸਾਂਝੀ ਰਜਿਸਟਰੀ ਨਾ ਹੋਵੇ ਤਾਂ ਟਕਰਾਅ ਹੋ ਜਾਂਦੇ। ਦੋ ਗਰੁੱਪ ਇੱਕੋ ਨੰਬਰ ਨੂੰ ਵੱਖ-ਵੱਖ ਫੀਚਰਾਂ ਲਈ ਉਪਯੋਗ ਕਰ ਸਕਦੇ ਹਨ, ਜਾਂ ਇੱਕੋ ਸੰਕਲਪ ਲਈ ਵੱਖ-ਵੱਖ ਲੇਬਲ ਵਰਤ ਸਕਦੇ ਹਨ। ਨਤੀਜਾ ਨਿਰਾਸ਼ਜਨਕ ਬੱਗਾਂ, ਗਲਤ ਫਹਿਮੀਆਂ ਅਤੇ ਐਸੇ ਉਤਪਾਦ ਹਨ ਜੋ ਸਿਰਫ਼ ਆਪਣੇ ਹੀ ਬਬਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ।
IANA ਦਾ ਕੰਮ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰ੍ਹਾਂ "ਬੋਰਿੰਗ" ਹੈ—ਪਰ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ। ਇਹ Abstract ਸਮਝੌਤਿਆਂ ਨੂੰ ਰੋਜ਼ਾਨਾ ਸਥਿਰਤਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ। ਇਹ ਖਾਮੋਸ਼ ਸਮਨਵਯ ਹੈ ਜੋ ਮਿਆਰਾਂ ਨੂੰ ਵਿਕਰੇਤਿਆਂ, ਦੇਸ਼ਾਂ ਅਤੇ ਦਹਾਕਿਆਂ ਦੇ ਪਾਰ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ ਬਿਨਾਂ ਲਗਾਤਾਰ ਦੁਬਾਰਾ-ਬੇਖ਼ਬਰ ਹੋਏ।
ਜੌਨ ਪੋਸਟਲ ਅਕਸਰ ਇਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇੱਥ ਉਲਲੇਖ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਸ਼ੁਰੂਆਤੀ ਇੰਟਰਨੈਟ ਸਾਫਟਵੇਅਰ ਦੇ ਵਿਹਾਰ ਨੂੰ ਰੂਪ ਦਿੱਤਾ: "ਜੋ ਤੁਸੀਂ ਭੇਜਦੇ ਹੋ ਉਸ ਵਿੱਚ ਸਖ਼ਤ ਰਹੋ, ਜੋ ਤੁਸੀਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ ਉਸ ਵਿੱਚ ਲਚਕੀਲੇ ਰਹੋ।" ਇਹ ਇੱਕ ਤਕਨੀਕੀ ਮਾਰਗਦਰਸ਼ਨ ਹੀ ਨਹੀਂ ਸੀ, ਬਲਕਿ ਉਹਨਾਂ ਅਜਿਹੇ ਅਣਜਾਣ ਲੋਕਾਂ ਵਿਚਕਾਰ ਇੱਕ ਸਮਾਜਿਕ ਸਮਝੌਤਾ ਵੀ ਸੀ ਜੋ ਸਿਸਟਮ ਬਣਾਉਣ ਲੱਗੇ ਸਨ।
"ਜੋ ਤੁਸੀਂ ਭੇਜਦੇ ਹੋ ਉਸ ਵਿੱਚ ਸਖ਼ਤ" ਦਾ ਮਤਲਬ ਹੈ ਤੁਹਾਡਾ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦੇ ਸਮੇਂ ਸਪੈਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰੋ—ਕੋਈ ਕ੍ਰੀਏਟਿਵ ਸ਼ਾਰਟਕਟ ਨਾ, ਕੋਈ "ਸਾਰੇ ਸਮਝ ਲੈਂਦੇ ਹਨ" ਨਹੀਂ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਅਜਿਹੇ ਅਨੌਖੇ ਵਿਆਖਿਆਵੇਂ ਨਾ ਫੈਲਣ ਜੋ ਹੋਰਾਂ ਨੂੰ ਨਕਲ ਕਰਨੀਆਂ ਪੈਣ।
"ਜੋ ਤੁਸੀਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ ਉਸ ਵਿੱਚ ਲਚਕੀਲੇ" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਐਸਾ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰੋ ਜੋ ਥੋੜ੍ਹਾ ਬਾਹਰ ਹੈ—ਸ਼ਾਇਦ ਇੱਕ ਖੇਤਰ ਗੁੰਮ, ਅਸਧਾਰਣ ਫਾਰਮੇਟ, ਜਾਂ ਏਜ-ਕੇਸ ਵਿਹਾਰ—ਤੁਸੀਂ ਉਸਨੂੰ ਨਰਮੀ ਨਾਲ ਸੰਭਾਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਨਾ ਕਿ ਕਨੈਕਸ਼ਨ ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ।
ਸ਼ੁਰੂਆਤੀ ਇੰਟਰਨੈੱਟ ਵਿਚ, ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਅਸਮਾਨ ਸਨ: ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨ, ਵੱਖ-ਵੱਖ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ, ਅਤੇ ਅਧੂਰੇ spec ਜੋ ਅਸਲ ਸਮੇਂ ਵਿਚ ਸੋਧੇ ਜਾ ਰਹੇ ਸਨ। ਲਚਕੀਲਾਪਨ ਨੇ ਸਿਸਟਮਾਂ ਨੂੰ ਇਕ ਦੂਜੇ ਨਾਲ ਗੱਲ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੱਤੀ, ਭਾਵੇਂ ਦੋਹਾਂ ਪਾਸਿਆਂ 'ਚ ਮੁਕੰਮਲਤਾ ਨਾ ਸੀ।
ਉਹ ਸਹਿਣਸ਼ੀਲਤਾ ਨੇ ਮਿਆਰੀਕਰਨ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇਕੱਠੇ ਹੋਣ ਦਾ ਸਮਾਂ ਦਿੱਤਾ। ਇਸ ਨੇ "forking" ਦਬਾਅ ਨੂੰ ਵੀ ਘਟਾਇਆ—ਟੀਮਾਂ ਨੂੰ ਅਪਣਾ ਵਿਭਿੰਨ ਵਰਜਨ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪਈ ਸਿਰਫ਼ ਕੰਮ ਚਲਾਉਣ ਲਈ।
ਸਮੇਂ ਦੇ ਨਾਲ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਲਚਕੀਲਾਪਨ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਨ ਲੱਗੀ। ਜੇ ਇੱਕ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਅੰਬਿਗਿਊਅਸ ਜਾਂ ਗਲਤ ਇਨਪੁਟ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਹੋਰ ਬਣਾਉਂਦੇ ਉਹ ਵਿਹਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਲੱਗਦੇ—ਇਸ ਤਰ੍ਹਾਂ ਬੱਗਾਂ "ਫੀਚਰ" ਬਣ ਜਾਂਦੀਆਂ। ਵੱਧ ਤੋੜ-ਫੋੜ ਵਾਲੀ ਪਾਰਸਿੰਗ ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਵੀ ਖੋਲ ਸਕਦੀ ਹੈ (ਇੰਜੈਕਸ਼ਨ-ਸਟਾਈਲ ਹਮਲੇ ਜਾਂ ਅਸਮਾਨ ਵਿਆਖਿਆਵਾਂ ਨਾਲ ਬਾਈਪਾਸ)।
ਆਧੁਨਿਕ ਸਬਕ ਇਹ ਹੈ: ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰੋ, ਪਰ ਮੋਰਲফਾਰਮਡ ਇਨਪੁਟ ਨੂੰ ਸਧਾਰਨ ਨ ਸਮਝੋ। ਮੂਲ ਤੌਰ 'ਤੇ ਸਖ਼ਤ ਰਹੋ, ਛੂਟੀਆਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ਬੱਧ ਕਰੋ, "ਅਨੁਮਤ ਪਰ ਨਾਨਕੰਪਲਾਇੰਟ" ਡੇਟਾ ਨੂੰ ਲਾਗ ਕਰੋ, ਸੀਮਿਤ ਕਰੋ ਅਤੇ ਆਖਿਰਕਾਰ ਫੇਜ਼-ਆਊਟ ਕਰੋ—ਸੁਰੱਖਿਆ ਧਿਆਨ ਨਾਲ ਸਮਰਥਾ ਨਿਭਾਉਂਦੇ ਹੋਏ।
"ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ" ਵਰਗੇ ਵੱਡੇ ਕਾਂਸੈਪਟ ਅਮਲ ਵਿੱਚ ਉਦਾਹਰਨਾਂ ਦੇਖਣ ਨਾਲ ਹੀ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ—ਉਹ ਦੈਨੰਦਿਨ ਸਿਸਟਮ ਜਿਹੜੇ ਹਰ ਵਾਰ ਤੁਸੀਂ ਕੋਈ ਵੈੱਬਸਾਈਟ ਖੋਲ੍ਹਦੇ ਜਾਂ ਸੁਨੇਹਾ ਭੇਜਦੇ ਸਮੇਂ ਚੁਪਚਾਪ ਸਹਿਯੋਗ ਕਰਦੇ ਹਨ। TCP/IP, DNS ਅਤੇ ਈਮੇਲ (SMTP) ਇੱਕ ਵਧੀਆ ਤ੍ਰੈਈ ਹਨ ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਵੱਖ-ਵੱਖ ਕੋਆਰਡੀਨੇਸ਼ਨ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ—ਅਤੇ ਹਰ ਇੱਕ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਕਿ ਬਾਕੀ ਦੋ ਹੋਣਗੇ।
ਸ਼ੁਰੂਆਤੀ ਨੈੱਟਵਰਕ ਆਇਥੇ ਖਤਮ ਹੋ ਸਕਦੇ ਸਨ: ਹਰ ਵਿਕਰੇਤਾ ਜਾਂ ਦੇਸ਼ ਆਪਣਾ ਅਣਕੰਪੈਟਿਬਲ ਪ੍ਰੋਟੋਕੋਲ ਸਟੈਕ ਚਲਾ ਰਿਹਾ। TCP/IP ਨੇ "ਡੇਟਾ ਕਿਵੇਂ ਗੁਜ਼ਰਦਾ" ਲਈ ਇੱਕ ਸਾਂਝਾ ਫਰੇਮਵਰਕ ਦਿੱਤਾ ਜੋ ਹਰੇਕ ਨੂੰ ਇਕੋ ਹਾਰਡਵੇਅਰ ਖਰੀਦਣ ਜਾਂ ਇਕੋ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਚਲਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦਾ।
ਮੁੱਖ ਜੇਤੂ ਇਹ ਨਹੀਂ ਸੀ ਕਿ TCP/IP ਪਰਫੈਕਟ ਸੀ। ਇਹ ਕਾਫੀ ਚੰਗਾ ਸੀ, ਖੁੱਲ੍ਹਾ ਨਿਰਧਾਰਿਤ ਸੀ, ਅਤੇ ਕਈ ਧਿਰਾਂ ਵੱਲੋਂ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ। ਜਦੋਂ ਕਾਫੀ ਨੈੱਟਵਰਕਾਂ ਨੇ ਇਸਨੂੰ ਅਪਨਾ ਲਿਆ, ਉਲਟ-ਚੋਣੀ ਸਟੈਕ ਚੁਣਨਾ ਅਕਸਰ ਅਲੱਗ-ਥੱਲੇ ਹੋਣ ਦਾ ਨਿਸ਼ਾਨ ਬਣ ਗਿਆ।
IP ਐਡਰੈੱਸ ਲੋਕਾਂ ਲਈ ਔਖੇ ਅਤੇ ਸੇਵਾਵਾਂ ਲਈ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹਨ। DNS ਨਾਂਕਰਨ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ—ਇਨਸਾਨ-ਦੋਸਤ ਨਾਂ ਨੂੰ ਰੂਟੇਬਲ ਐਡਰੈੱਸ ਵਿੱਚ ਬਦਲਦਾ।
ਪਰ ਨਾਂਕਰਨ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਮੈਪਿੰਗ ਨਹੀਂ ਹੈ। ਇਹ ਪਾਰਣ ਦੀ ਸਪਸ਼ਟੀਕਰਨ ਮੰਗਦਾ: ਕੌਣ ਨਾਮ ਬਣਾਉਂਦਾ, ਕੌਣ ਉਹਨਾਂ ਨੂੰ ਬਦਲ ਸਕਦਾ, ਅਤੇ ਟਕਰਾਅ ਕਿਵੇਂ ਰੋਕੇ ਜਾਂਦੇ। DNS ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਕਿ ਇਸਨੇ ਇੱਕ ਸਧਾਰਣ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਇੱਕ ਸਮਨਵਯਤ ਨੇਮਸਪੇਸ ਨਾਲ ਜੋੜਿਆ, ਜਿਸ ਨਾਲ ਆਜ਼ਾਦ ਓਪਰੇਟਰ ਆਪਣੇ ਆਪਣੇ ਡੋਮੇਨ ਚਲਾ ਸਕਦੇ ਬਿਨਾਂ ਸਭ ਨੂੰ ਤੋੜਣ ਦੇ।
ਈਮੇਲ ਇਸ ਲਈ ਸਫਲ ਹੋਈ ਕਿ SMTP ਇੱਕ ਜ਼ਰੂਰੀ ਵਾਅਦਾ 'ਤੇ ਕੇਂਦਰਤ ਰਹਿੰਦਾ: ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਸੁਨੇਹੇ ਬਦਲਵਾਉਣ ਲਈ ਇਕੋ ਫਾਰਮੈਟ ਅਤੇ ਇੱਕ ਨਿਰਧਾਰਿਤ ਗੱਲ-ਬਾਤ।
ਉਹ ਢੀਲਾ ਜੋੜੀ ਜਾਣਾ ਮਹੱਤਵਪੂਰਨ ਸੀ। ਵੱਖ-ਵੱਖ ਸੰਗਠਨ ਵੱਖ-ਵੱਖ ਮੈਲ ਸਾਫਟਵੇਅਰ, ਸਟੋਰੇਜ ਸੁਤਰ ਅਤੇ ਸਪੈਮ ਨੀਤੀਆਂ ਚਲਾਉ ਸਕਦੇ ਹਨ, ਫਿਰ ਵੀ ਮੈਲ ਅਦਾਂ-ਪ੍ਰਦਾਂ ਕਰ ਸਕਦਾ। SMTP ਨੇ ਇਕੱਲਾ ਪ੍ਰਦਾਤਾ ਜਾਂ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਲਾਦਿਆ ਨਹੀਂ—ਇਹ ਸਿਰਫ਼ ਹੈਂਡਆਫ਼ ਨੂੰ ਮਿਆਰਿਤ ਕਰਦਾ।
ਇਹਨਾਂ ਮਿਆਰਾਂ ਨੇ ਮਿਲ ਕੇ ਇੱਕ ਅਮਲੀ ਚੇਨ ਬਣਾਈ: DNS ਤੁਹਾਨੂੰ ਸਹੀ ਮੰਜ਼ਿਲ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ, TCP/IP ਪੈਕੇਟ ਉਥੇ ਪਹੁੰਚਾਉਂਦਾ, ਅਤੇ SMTP ਜਦੋਂ ਜੁੜਾਈ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਮੈਲ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਕੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ।
"Internet governance" ਸੁਣਕੇ ਸੋਚ ਆ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਰਾਜਨੀਤਿਕ ਸੰਮੇਲਨ ਤੇ ਰਾਜ-ਦਸਤਾਵੇਜ਼ ਹਨ। ਸ਼ੁਰੂਆਤੀ ਇੰਟਰਨੈੱਟ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਛੋਟੇ-ਛੋਟੇ, ਅਮਲੀ ਫੈਸਲਿਆਂ ਵਾਂਗ ਦਿਸਦਾ ਸੀ: ਕਿਹੜੇ ਨੰਬਰ ਰਿਜ਼ਰਵ ਕੀਤੇ ਜਾਣ, ਕਿਸ ਪ੍ਰੋਟੋਕੋਲ ਫੀਲਡ ਦਾ ਕੀ ਅਰਥ, ਭੁੱਲ-ਸੁਧਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦਾ ਤਰੀਕਾ, ਜਾਂ ਦੋ ਪ੍ਰਸਤਾਵਾਂ ਨੂੰ ਇਕੱਠੇ ਕਰਨ ਦਾ ਸਮਾਂ। ਪੋਸਟਲ ਦਾ ਪ੍ਰਭਾਵ ਫORMAL ਅਧਿਕਾਰਕਤਾ ਤੋਂ ਘੱਟ ਅਤੇ ਉਹਨਾਂ فيصلਿਆਂ ਨੂੰ ਅਗੇ ਵਧਾਉਣ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਰਨ 'ਚ ਜ਼ਿਆਦਾ ਸੀ।
ਕੋਈ ਕੇਂਦਰੀ "Internet police" ਨਹੀਂ ਸੀ। ਇਸਦੀ ਥਾਂ, ਗਵਰਨੈਂਸ ਉਹ ਆਦਤਾਂ ਰਾਹੀਂ ਹੁੰਦੀ ਸੀ ਜੋ ਸਹਿਯੋਗ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨ ਰਸਤਾ ਬਣਾਉਂਦੀਆਂ ਸਨ। ਜਦੋਂ ਕੋਈ ਸਵਾਲ ਉੱਠਦਾ—ਜਿਵੇਂ parameter registry ਬਾਰੇ ਜਾਂ ਪ੍ਰੋਟੋਕੋਲ ਅਸਪਸ਼ਟਤਾ—ਕਿਸੇ ਨੂੰ ਇਕ ਜਵਾਬ ਚੁਣਨਾ, ਲਿਖਣਾ ਅਤੇ ਘੁੰਮਾਉਣਾ ਪੈਂਦਾ। ਪੋਸਟਲ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਉਹ IANA ਫੰਕਸ਼ਨ ਜਿਸਦੀ ਉਸ ਨੇ ਰਖਵਾਲੀ ਕੀਤੀ, ਇੱਕ ਸਾਫ਼ ਕੋਆਰਡੀਨੇਸ਼ਨ ਪੁਆਇੰਟ ਪ੍ਰਦਾਨ ਕਰਦੇ। ਤਾਕਤ ਚੁੱਪ ਸੀ: ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਸਿਸਟਮ ਨੂੰ ਸਭ ਦੇ ਨਾਲ ਕੰਮ ਕਰਵਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਾਂਝੇ ਚੋਣਾਂ ਨਾਲ ਮਿਲਦੇ।
ਭਰੋਸਾ ਪਾਰਦਰਸ਼ੀ ਰਿਕਾਰਡਾਂ ਰਾਹੀਂ ਬਣਿਆ। RFCs ਅਤੇ ਪਬਲਿਕ ਮੈਲਿੰਗ ਲਿਸਟ ਚਰਚਾਵਾਂ ਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਫੈਸਲੇ ਨਿੱਜੀ ਮੀਟਿੰਗਜ਼ ਵਿੱਚ ਲੁਕੇ ਨਹੀਂ ਰਹਿੰਦੇ। ਜਿਵੇਂ ਹੀ ਵਿਅਕਤੀ ਫ਼ੈਸਲੇ ਕਰਦੇ, ਉਹ ਇੱਕ ਆਡਿਟ ਟ੍ਰੇਲ ਛੱਡਣ ਦੀ ਉਮੀਦ ਰੱਖਦੇ: ਕਾਰਨ, ਸੰਦਰਭ ਅਤੇ ਦੂਜਿਆਂ ਲਈ ਚੁਣੌਤੀ ਜਾਂ ਸੁਧਾਰ ਦਾ ਤਰੀਕਾ।
ਜਵਾਬਦੇਹੀ ਆਮ ਤੌਰ 'ਤੇ ਇੰਪਲੀਮੈਂਟਰਾਂ ਅਤੇ ਸਹਿਯੋਗੀਆਂ ਵੱਲੋਂ ਆਉਂਦੀ ਸੀ। ਜੇ ਕੋਈ ਫੈਸਲਾ ਖ਼ਰਾਬੀ ਵਜੋਂ ਨਿਕਲਿਆ, ਫੀਡਬੈਕ ਤੁਰੰਤ ਮਿਲਦਾ—ਸੌਫਟਵੇਅਰ ਫੇਲ ਹੁੰਦਾ, ਓਪਰੇਟਰ ਸ਼ਿਕਾਇਤ ਕਰਦੇ, ਅਤੇ ਵੱਖ-ਵੱਖ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਏਜ ਕੇਸ ਦਰਸਾਉਂਦੀਆਂ। ਅਸਲ ਐਨਫੋਰਸਮੈਂਟ ਮਕੈਨੀਜ਼ਮ ਅਪਣਾਏ ਜਾਣ 'ਤੇ ਆਧਾਰਿਤ ਸੀ: ਜੋ ਮਿਆਰ ਕੰਮ ਕਰਦਾ, ਉਹ ਫੈਲਦਾ; ਜੋ ਨਹੀਂ ਕਰਦਾ, ਉਹ ਅਣਦੇਖਾ ਹੋ ਜਾਂਦਾ ਜਾਂ ਸੋਧਿਆ ਜਾਂਦਾ।
ਇਸੇ ਕਾਰਨ ਇੰਟਰਨੈੱਟ ਗਵਰਨੈਂਸ ਅਕਸਰ ਇੰਜੀਨੀਅਰਿੰਗ ਟਰਾਈਆਜ ਵਾਂਗ ਦਿਸਦੀ: ਅਸਪਸ਼ਟਤਾ ਘਟਾਓ, ਟਕਰਾਅ ਰੋਕੋ, ਅਨੁਕੂਲਤਾ ਬਰਕਰਾਰ ਰੱਖੋ, ਅਤੇ ਕੁਝ ਐਸਾ ਸ਼ਿਪ ਕਰੋ ਜੋ ਲੋਕ ਲਾਗੂ ਕਰ ਸਕਣ। ਲਕੜ ਨਹੀਂ, ਉਦੇਸ਼ ਇੱਕ ਅਜਿਹਾ ਨੈੱਟਵਰਕ ਸੀ ਜੋ ਜੁੜਿਆ ਰਹੇ।
ਇੰਟਰਨੈੱਟ ਦਾ ਮਿਆਰ-ਸਭਿਆਚਾਰ—ਹਲਕੇ-ਫੁਲਕੇ ਦਸਤਾਵੇਜ਼, ਖੁੱਲ੍ਹੀ ਚਰਚਾ, ਅਤੇ ਚੱਲਦੀਆਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਨੂੰ ਤਰਜੀਹ—ਨੇ ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਪਰ ਇਹਨਾਂ ਆਦਤਾਂ ਨਾਲ ਹੀ ਕੁਝ ਟਰੇਡ-ਆਫ਼ ਵੀ ਆਏ ਜੋ ਇੰਟਰਨੈੱਟ ਦੇ ਰੀਸਰਚ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਗਲੋਬਲ ਢਾਂਚਾ ਬਣਨ ਤੱਕ ਮਹੱਤਵਪੂਰਨ ਹੋ ਗਏ।
"ਕੋਈ ਵੀ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦਾ" ਦਾ ਮਤਲਬ ਆਪਣੇ ਆਪ ਵਿੱਚ "ਹਰ ਕੋਈ ਪਹੁੰਚਯੋਗ" ਨਹੀਂ ਸੀ। ਸ਼ਾਮਿਲ ਹੋਣ ਲਈ ਸਮਾਂ, ਯਾਤਰਾ (ਸ਼ੁਰੂਆਤੀ ਸਾਲਾਂ ਵਿੱਚ), ਅੰਗਰੇਜ਼ੀ ਨਿਪੁਣਤਾ, ਅਤੇ ਸੰਸਥਾਨਕ ਸਮਰਥਨ ਦੀ ਲੋੜ ਸੀ। ਇਸ ਨੇ ਅਸਮਾਨ ਪ੍ਰਤੀਨਿਧਿਤਾ ਅਤੇ ਕਈ ਵਾਰ ਪੁਲਾੜੀ ਤਾਕਤ-ਅਸਮਾਨਤਾਵਾਂ ਪੈਦਾ ਕੀਤੀਆਂ: ਚੰਗੀ ਤਰ੍ਹਾਂ ਫੰਡ ਕੀਤੀਆਂ ਕੰਪਨੀਆਂ ਜਾਂ ਦੇਸ਼ ਨਿਰੰਤਰ ਪੇਸ਼ ਹੋ ਸਕਦੇ ਸਨ, ਜਦਕਿ ਹੋਰਾਂ ਦੇ ਲਈ ਸੁਣਾਈ ਦੇਣਾ ਮੁਸ਼ਕਿਲ। ਜਦੋਂ ਫੈਸਲੇ ਪਬਲਿਕ ਤੌਰ 'ਤੇ ਕੀਤੇ ਜਾਂਦੇ, ਤਾਂ ਵੀ ਅਜਿਹੇ ਲੋਕ ਜਿਨ੍ਹਾਂ ਕੋਲ ਅਜਿਹਾ ਸਮਰਥਨ ਸੀ, ਉਹ ਏਜੈਂਡਾ ਅਤੇ ਡਰਾਫਟ ਟੈਕਸਟ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਆਕਾਰ ਦੇ ਸਕਦੇ ਸਨ।
"ਜੋ ਤੁਸੀਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ ਉਸ ਵਿੱਚ ਲਚਕੀਲੇ" ਹੋਣ ਦੀ ਪ੍ਰਤੀਰੂਪਤਾ ਨੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕੀਤਾ, ਪਰ ਇਹ ਅਸਲ ਵਿੱਚ ਗਲਤ ਵਿਵਰਣਾਂ ਨੂੰ ਇਨਾਮ ਦੇ ਸਕਦੀ। ਅਸਪਸ਼ਟਤਾ inconsistent ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਲਈ ਜਗ੍ਹਾ ਛੱਡਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਧਾਰਣਾਂ ਬਣਾਉਂਦੇ ਹਨ ਤਾਂ ਇਹ ਸੁਰੱਖਿਆ ਖਤਰਿਆਂ ਵੱਲ ਵਧਦਾ ਹੈ। "ਮਾਰੀ ਦੋਸਤ" ਪਾਰਸਿੰਗ ਖਤਮ-ਦੌਰ 'ਤੇ ਅਜਿਹੇ ਬਗਾਂ ਨੂੰ ਫੋਕਸ ਕਰਦੀ ਜਿਸਨੂੰ ਹੱਕਰ ਵਰਤ ਸਕਦੇ ਹਨ।
ਜਲਦੀ ਇੰਟਰਓਪਰੇਬਲ ਕੋਡ ਸ਼ਿਪ ਕਰਨਾ ਮੱਲਿਆਪੂਰਨ ਹੈ, ਪਰ ਇਹ ਉਹਨਾਂ ਟੀਮਾਂ ਨੂੰ ਵਧੀਕ ਲਾਭ ਦਿੰਦਾ ਜੋ ਸਬ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਇੰਪਲੀਮੈਂਟ ਕਰ ਸਕਦੀਆਂ—ਕਦੀ-ਕਦੀ ਬਿਨਾਂ ਪੂਰੀ ਕੌਮਿਯ-ਚਰਚਾ ਤੇ ਪ੍ਰਾਈਵੇਸੀ, ਦੁਰਵਿਵਹਾਰ ਜਾਂ ਲੰਬੇ ਸਮੇਂ ਦੇ ਓਪਰੇਸ਼ਨਲ ਨਤੀਜਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਵੇਖੇ। ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਨ ਦੇ ਢੰਗ ਹੋ ਸਕਦੇ, ਪਰ ਬੈਕਵਰਡ ਕੰਪੇਟਿਬਿਲਿਟੀ ਦੇ ਕਾਰਨ ਕੁਝ ਦੋਸ਼ਾਂ ਨੂੰ ਉਲਟਾਉਣਾ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੇ ਸ਼ੁਰੂਆਤੀ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਇੱਕ ਛੋਟੀ, ਵਿਸ਼ਵਾਸਯੋਗ ਸਮੁਦਾਇ ਦੀ ਧਾਰਣਾ 'ਤੇ ਨਿਰਭਰ ਸਨ। ਜਿਵੇਂ ਹੀ ਵਪਾਰਕ ਪ੍ਰੇਰਣਾਵਾਂ, ਰਾਜ-ਕਿਰਦਾਰ ਅਤੇ ਵੱਡੇ ਪੈਮਾਨੇ ਆਏ, ਗਵਰਨੈਂਸ ਦੀਆਂ ਚਰਚਾਵਾਂ ਫਿਰ ਸਾਹਮਣੇ ਆਈਆਂ: ਕੌਣ ਫੈਸਲਾ ਕਰੇ, ਲੈਜੀਟੀਮੇਸੀ ਕਿਵੇਂ ਮਿਲਦੀ, ਅਤੇ "rough consensus" ਦਾ ਮਤਲਬ ਕੀ ਹੁੰਦਾ ਜਦ ਦਾਅਵੇ ਸਨਸਥਾ, ਨਿਰੀਖਣ ਅਤੇ ਗਲੋਬਲ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਨਾਲ ਸਬੰਧਤ ਹੋਣ।
ਪੋਸਟਲ ਨੇ ਇੰਟਰਨੈੱਟ ਨੂੰ ਕਿਸੇ ਮਹਾਨ ਯੋਜਨਾ ਨਾਲ ਨਹੀਂ ਚਲਾਇਆ। ਉਹ ਇਸਨੂੰ ਇਕਠਾ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਸੀ ਆਪਣੀ ਦੈਨਿੰਦਿਨ ਅਮਲਾਂ ਰਾਹੀਂ: ਲਿਖੋ, ਹੋਰਾਂ ਨੂੰ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਿਓ, ਅਤੇ ਸਾਂਝੇ ਪਛਾਣਕર્તਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖੋ। ਆਧੁਨਿਕ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ—ਖ਼ਾਸ ਕਰਕੇ ਉਹ ਜੋ ਪਲੇਟਫਾਰਮ, APIs ਜਾਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਬਣਾਉਂਦੀਆਂ—ਉਹ ਇਸ ਮਨੋਭਾਵ ਨੂੰ ਸਿੱਧਾ ਅਪਣਾ ਸਕਦੀਆਂ ਹਨ।
ਜੇ ਦੋ ਟੀਮਾਂ (ਜਾਂ ਦੋ ਕੰਪਨੀਆਂ) ਇਕੱਠੇ ਕੰਮ ਕਰਨੀਆਂ ਹਨ, ਤਾਂ ਟ੍ਰਾਈਬਲ ਨੋਲੇਜ ਜਾਂ "ਕਾਲ 'ਤੇ ਸਮਝਾਉਣਾਂ" 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ। ਆਪਣੇ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ: ਇੰਪੁਟ, ਆਉਟਪੁਟ, ਐਰਰ ਕੇਸ ਅਤੇ ਸੀਮਾਵਾਂ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ: ਜੇ ਇਹ ਕਿਸੇ ਹੋਰ ਸਿਸਟਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ, ਤਾਂ ਇਹ ਇੱਕ ਲਿਖਤੀ ਸਕੀਮਾ ਦੇ ਯੋਗ ਹੈ। ਉਹ ਸਕੀਮਾ ਹਲਕਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਉਹਨਾਂ ਨਸ਼ਿਰਾਂ ਲਈ ਲੋਕਾਂ ਲਈ ਪਬਲਿਕ ਹੋਣਾ ਜਰੂਰੀ ਹੈ।
ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਸਮੱਸਿਆਵਾਂ ਅਸਲ ਟ੍ਰੈਫਿਕ 'ਤੇ ਅੱਧ-ਕੰਮ ਕਮਰਿਆਂ ਤੱਕ ਛੁਪੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਡਰਾਫਟ spec ਸ਼ਿਪ ਕਰੋ, ਇੱਕ ਸਧਾਰਣ ਰੇਫਰੰਸ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਬਣਾਓ, ਅਤੇ ਸਾਥੀਆਂ ਨੂੰ ਟੈਸਟ ਕਰਨ ਲਈ ਬੁਲਾਓ ਜਦੋਂ ਇਹ ਅਜੇ ਬਦਲਣ ਲਈ ਆਸਾਨ ਹੋ।
ਸਾਂਝੇ specs ਅਤੇ ਰੇਫਰੰਸ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਨਾਲ ਅਸਪਸ਼ਟਤਾ ਘਟਦੀ ਹੈ, ਅਤੇ ਇਹ ਹਰ ਕਿਸੇ ਨੂੰ ਇਕ ਨਿਰਧਾਰਤ ਸ਼ੁਰੂਆਤ ਦਿੰਦਾ—ਵਿਰੋਧੀ ਵਿਆਖਿਆਵਾਂ ਦੀ ਥਾਂ।
ਸਹਿ-ਚਾਲਣ ਇੱਕ ਅਹਿਸਾਸ ਨਹੀਂ; ਇਹ ਕੁਝ ਤੁਸੀਂ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ।
ਸਫਲਤਾ ਮਾਪਦੰਡ ਨਿਰਧਾਰਤ ਕਰੋ ("ਇੱਕ-ਦੂਜੇ ਨਾਲ ਕੰਮ ਕਰਨਾ" ਦਾ ਕੀ ਅਰਥ ਹੈ), ਫਿਰ ਕੁਨਫੋਰਮੈਂਸ ਟੈਸਟ ਅਤੇ ਕੰਪੈਟਿਬਿਲਿਟੀ ਲਕੜੀਆਂ ਬਣਾਓ ਜੋ ਟੀਮਾਂ CI ਵਿੱਚ ਚਲਾ ਸਕਣ। ਜਦੋਂ ਸਾਥੀ ਇੱਕੋ ਟੈਸਟ ਚਲਾ ਸਕਦੇ ਹਨ, ਤਬ ਬਹਿਸ ਬਦਲ ਕੇ ਕਾਰਵਾਈਯੋਗ ਬੱਗਾਂ ਬਣ ਜਾਂਦੀ ਹੈ।
ਸਥਿਰਤਾ ਲਈ ਬਦਲਾਅ ਦਾ ਇੱਕ ਪੇਸ਼ਾਨਾ ਰਸਤਾ ਲਾਜ਼ਮੀ ਹੈ:
ਪੋਸਟਲ ਦਾ ਅਮਲੀ ਸਬਕ ਸਧਾਰਨ ਹੈ: ਸਮਨਵਯ ਤਦ ਵਿਸਥਾਰ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਮਨੁੱਖਾਂ ਅਤੇ ਮਸ਼ੀਨਾਂ ਦੋਹਾਂ ਲਈ ਅਚਾਨਕੀ ਘਟਨਾਵਾਂ ਘਟਾਉਂਦੇ ਹੋ।
IETF ਲਈ ਇਕ ਕਾਰਨ ਇਹ ਸੀ ਕਿ ਵਿਚਾਰ ਬਹੁਤ ਸਮੇਂ ਤੱਕ ਸਿਧਾਂਤ ਵਿੱਚ ਨਹੀਂ ਰਹਿੰਦੇ—ਉਹ ਰਨ ਕਰਨਯੋਗ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਬਣ ਜਾਂਦੇ। ਆਧੁਨਿਕ ਟੀਮਾਂ ਉਸੇ ਲੂਪ ਤੋਂ ਲਾਭ ਉਠਾ ਸਕਦੀਆਂ ਹਨ ਜੇ ਉਹ "ਅਸੀਂ ਇੰਟਰਫੇਸ 'ਤੇ ਸਹਿਮਤ ਹਾਂ" ਤੇ "ਦੋ ਅਜ਼ਾਦ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਇਕੱਠੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ" ਦੇ ਵਿਚਕਾਰ ਘਟਕੇ ਰਸਤੇ ਘਟਾ ਦੇਣ।
Platforms like Koder.ai are useful in that spirit: you can go from a written API sketch to a working web app (React), backend (Go + PostgreSQL), or mobile client (Flutter) through a chat-driven workflow, then iterate quickly with snapshots/rollback and source-code export. The tooling isn’t the standard—but it can make standards-like habits (clear contracts, fast prototyping, reproducible implementations) easier to practice consistently.
Interoperability wasn’t automatic because early networking was a patchwork of separate systems with different assumptions—address formats, message sizes, retry timers, error handling, and even incentives.
Without shared agreements, you get disconnected “islands” connected only by brittle, custom gateways.
Custom protocol bridges are expensive to build and maintain, easy to break as either side changes, and they often become chokepoints.
That creates vendor/operator lock-in because the party controlling the “translation layer” can dictate terms and slow competitors.
Because the “best” protocol doesn’t win if it can’t be implemented widely and consistently.
A slightly imperfect but broadly implementable standard can connect more networks than a technically elegant approach that only works inside one ecosystem.
He influenced outcomes through earned trust rather than formal authority: clear writing, patient coordination, and persistent follow-through.
He also handled the unglamorous work (editing, clarifying, nudging decisions, maintaining registries) that keeps independent implementers aligned.
An RFC (Request for Comments) is a publicly available memo describing an Internet protocol or operational practice.
Practically, it gives implementers a shared reference: formats, edge cases, and behaviors written down so different teams can build compatible systems.
“Rough consensus” means the group aims for broad agreement without requiring unanimity.
“Running code” means proposals should be proven by real implementations—ideally multiple independent ones—so the spec reflects what actually works on real networks.
Fragmentation would mean incompatible mini-networks with duplicated plumbing and constant translation.
The costs show up as:
The IETF provides an open process where anyone can read drafts, join discussions, and contribute evidence from implementation and operations.
Instead of hierarchy, influence tends to come from doing the work: writing drafts, testing ideas, responding to review, and improving clarity until systems interoperate.
IANA maintains shared registries (protocol numbers, port numbers, parameter codes, and parts of naming coordination) so independent implementations use the same values.
Without a single reference, you get collisions (same number, different meaning) and hard-to-debug incompatibilities that undermine otherwise “correct” standards.
Postel’s guideline—be strict in what you send, flexible in what you accept—helped early systems communicate despite uneven implementations.
But excessive tolerance can normalize malformed inputs and create security and interoperability bugs. A modern approach is compatibility with guardrails: validate strictly, document exceptions, log/limit noncompliance, and phase it out.