كانت للحزمة أبجدية ونغمة، لكن لم تكن لها علامة نهاية: RFC 1926

الخلاصة

• يربط RFC 1926 كل قيمة من أربع بتات بحرف، ويضيف حرف بداية، ويرسل الحروف بمورس فوق واحد من سبعة ترددات صوتية.
• عكس جدول الرموز لا يكفي للاستقبال؛ فلا بد أولاً من تحديد الحروف وحدود الحزمة والتوقيت والتلف وحالة إعادة المزامنة.
• ليست العبرة بكثرة قواعد المواصفة، بل بأن تكون القرارات المشتركة التي تغيّر قبول الطرف الآخر صريحة وقابلة للاختبار.

ماذا يسمع البرنامج بعد حرف البداية؟

تبدأ الوصفة في RFC 1926 من مخطط واضح. تُقسَّم رزمة IP إلى مقاطع من أربع بتات وفق ما يسميه النص «network beep order». يطابق جدول كامل القيم الست عشرة بستة عشر حرفاً. يُضاف الحرف b في المقدمة بوصفه إشارة بدء الإطار، ثم تُرسل الحروف بشفرة مورس من خلال تشغيل نغمة ثابتة وإيقافها.

يسمي النص تردد النغمة «Acoustical Signature» للمرسل، أي AS number بمدلول موسيقي. ويقترح سبعة ترددات من 440 إلى 784 هرتز لكي تتعايش شبكات «Local Acoustical Network» مختلفة، مع اعتماد 440 هرتز للحالة العادية.

بعد هذا التفصيل تأتي فقرة الاستقبال في جملة واحدة: تُنفَّذ العملية السابقة ببساطة في الاتجاه المعاكس.

يمكن للجدول العكسي أن يستعيد أربع بتات من حرف معروف. لكنه لا يحوّل الموجة الخام إلى حرف معروف. على المستقبل أن يفرّق بين النقطة والشرطة، وبين الفاصل داخل الحرف والفاصل بين الحروف، ثم أن يعرف أين تنتهي الرزمة كلها. بعد b قد يعني الصمت فاصلاً مشروعاً، أو نهاية، أو فقداناً للصوت، أو توقف المرسل قبل إكمال الرأس. لا يقدّم النص علامة إغلاق أو طولاً أو مهلة مكافئة. ولذلك يستطيع مستقبلان معقولان إغلاق التدفق في وقتين مختلفين.

تاريخ النشر يشرح الدعابة ولا يثبت التشغيل

صدر RFC 1926 في 1 أبريل 1996 ضمن فئة Informational، ويقول بوضوح إنه لا يحدد معيار إنترنت من أي نوع. وتضعه صفحة RFC Editor الحالية في Independent Stream. هذه حقيقة فهرسة حالية، ولا تكفي وحدها للقول إن تفاصيل المؤسسة في 1996 كانت مطابقة تماماً لما هو قائم اليوم.

يقدّم RFC 8700 السياق اللاحق الموثق: وثائق الأول من أبريل جزء خاص من تقليد Independent Stream، وهي نصوص فكاهية لا تمر بعملية رسمية للمراجعة والموافقة التقنية. تحويل ATM وLAN وAS إلى معانٍ صوتية هو بنية النكتة، لا تفويض معياري مخفي.

يحفظ رقم RFC النص في الأرشيف. لكنه لا يثبت وجود تطبيقين مستقلين أو اختبار ضوضاء أو قياسات تشغيلية. ولا يجيز غياب تلك الأدلة في المصادر التسعة أن نجزم بأن أحداً لم يصنع نموذجاً قط. الاستنتاج المنضبط هو أن الوثيقة وحدها لا تحسم اختيارات المستقبل المشتركة.

المواصفة الصغيرة تستطيع إعلان حدودها

يعرض RFC 1055 مثال SLIP بوصفه طريقة لا تفعل إلا تأطير حزم IP على خط تسلسلي. لا تمنح عنونة ولا تعريف نوع الحزمة ولا تصحيح الخطأ ولا الضغط. ومع ذلك تحدد محرف END، وتهرّب END وESC عندما يظهران داخل البيانات، وتقترح END في البداية لطرد البايتات الناتجة من ضوضاء الخط، وتعرض منطق الإرسال والاستقبال وحجماً عملياً أقصى للرزمة.

هنا تعني البساطة أن يعرف الطرفان القليل نفسه، وأن يعرفا أيضاً ما تُرك للطبقات الأخرى.

أما RFC 1662 فيفصل التأطير الشبيه بـHDLC في PPP: راية للبداية أو النهاية، وتهريب أو حشو بتات لحماية الشفافية، وتسلسل فحص إطار لكشف التلف، وقواعد للإطارات غير الصالحة وللفترة بين إطارين. لا يلزم أن يستخدم الربط الصوتي هذه الآليات نفسها، لكن لا يمكنه إلغاء الأسئلة المستقلة التي تجيب عنها.

وتكشف المقارنة مع ATM الحقيقي معنى آخر للاكتمال. يحدد RFC 1577 تشغيل Classical IP وARP فوق Asynchronous Transfer Mode وAAL5. يشرح الاتصالات الافتراضية، وتغليف LLC/SNAP الافتراضي، وMTU لحزم IP مقداره 9180 ثمانيّة، وحل العناوين، وإشارة نهاية PDU في الخلية الأخيرة. كما يعلن أن إعادة الإرسال مسؤولية بروتوكولات أعلى. تفويض الوظيفة ليس فراغاً حين تكون الجهة المسؤولة معروفة.

ست درجات بين الحرف والشبكة العاملة

أولاً التمثيل الذي يربط أربع بتات بحرف. ثم التضمين الذي يحوّل الحرف إلى نغمة. بعده التأطير الذي يحدد رزمة واحدة. ثم السلامة والتعافي اللذان يجعلان القطع والتلف والفقد والتكرار حالات ذات نتيجة معروفة. تأتي قابلية التشغيل البيني حين تتبادل تطبيقات مستقلة متجهات صحيحة ومتضررة. وأخيراً التشغيل حين تُقاس السرعة والتأخير والفقد والمدى والضوضاء والتعايش.

يغطي RFC 1926 الدرجتين الأوليين ويقدم إشارة بدء للثالثة. لا يحدد مدة النقطة والشرطة أو السماح الزمني أو إعادة المزامنة أو الحجم الأقصى أو التنافس على التردد أو رفض التسلسل التالف. الترددات السبعة تسمي قنوات محتملة، لكنها لا تحل تصادم مرسلين على النغمة نفسها. والتحذير من الأماكن المزدحمة وصف لخطر لا آلية أمن.

يساعد إطار Running-Code Primacy اللاحق على إبقاء الأدلة منفصلة: النشر والتنفيذ والتحقق والنشر التشغيلي والاستخدام ليست واقعة واحدة. ويبيّن Minimum Initial Specification أن الحد الأدنى لا يعني الغموض، بل قواعد قليلة صارمة حيث تعتمد قابلية التشغيل البيني عليها. ويفصل Reality Layers بين الدوام الرمزي للرقم والدعابة، وبين حقيقة تنفيذية تُلتقط فيها الموجة وتؤطَّر وتُفحَص وتُسلَّم.

هذه عدسات تحليلية جاءت لاحقاً، وليست دليلاً على قصد مؤلف RFC 1926. وهي تمنع حكماً أكبر من المصادر: لا نملك هنا فشلاً تشغيلياً موثقاً؛ نملك نصاً توقف قبل أن يحدد اختبار النجاح.