الخلاصة

  • سجلت RFC 3362 النوع image/t38 واصفاً لوسائط SDP الخاصة بتدفق فاكس T.38 في الزمن الحقيقي، بينما بقي تعريف الترميز والإجراءات في توصية ITU-T T.38.
  • إزالة غموض الاسم لم تثبت قبول الطرف الآخر أو توافق النقل أو وجود التشفير أو نجاح البوابة أو اكتمال الصفحة ووصولها.

قد تقرأ البوابة السطر قراءة صحيحة تماماً. ترى image/t38 وتعرف أن الطرف الآخر يقترح تدفق فاكس في الزمن الحقيقي. نجح القاموس في تلك اللحظة، لكن الورقة في الجهة الأخرى قد تبقى بيضاء. هذه المسافة بين التسمية والتحقق هي المسألة التاريخية التي تكشفها RFC 3362.

صدرت الوثيقة في عام 2002 عند نقطة التقاء بين مجموعتين من المعايير. وصفت توصية T.38 الصادرة عن ITU-T الخصائص اللازمة لاتصال أجهزة فاكس المجموعة الثالثة وبواباتها عبر شبكات IP. وقدمت SIP وSDP آليات إنشاء الجلسة ووصفها. أما RFC 3362 فسجلت اسماً مشتركاً يمكن وضعه في وصف SDP.

لم تدع الوثيقة أنها تعيد تعريف الترميز. أحالت إلى T.38 بوصفها المرجع الذي يحدد ذلك السلوك. وذكرت أن T.38 تسمح باستخدام TCP أو UDP بحسب بيئة الخدمة. كما شرحت أن إجراءات Annex D المكتوبة مع نسخة أقدم من SIP يمكن تطبيقها أيضاً مع النسخة المنقحة في RFC 3261.

كان توزيع المسؤوليات مفيداً لا ناقصاً. تستطيع ITU-T الحفاظ على سلوك الفاكس، ويحافظ IETF على آليات الجلسة، وتحفظ IANA الرمز، ثم يقرر المنفذون والمشغلون ما يشغلونه فعلاً. لم يكن على سجل واحد أن يتحول إلى سلطة فوق كل طبقة.

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

حددت RFC 3362 سياقاً لا يجوز تجاهله. النوع مخصص للدلالة على تدفق T.38 في SDP، وليس للبريد الإلكتروني. استخدامه في تطبيقات البريد لم يكن معرفاً، ولذلك لم يكن مضمون التشغيل البيني مع تدفق T.38. وجود كلمة image في الاسم الأعلى لا يحول الجلسة إلى مرفق عادي.

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

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

SDP لا تنقل الحزم بمجرد وصفها. من RFC 2327 إلى RFC 4566 ثم RFC 8866 الحالية، هي صيغة لوصف جلسة متعددة الوسائط ولا تتضمن بروتوكول نقل. تستطيع كتابة عنوان ومنفذ ونوع وسيط، لكن الوصف ليس طريقاً للشبكة.

بعد الوصف يأتي التفاوض. تنظم RFC 3264 العرض من منظور طرف، ثم الإجابة من منظور الطرف الآخر. لا تكتمل صورة الجلسة إلا بهما معاً. ويمكن للإجابة رفض التدفق بوضع المنفذ عند الصفر. لذلك لا تثبت مشاهدة image/t38 في العرض سوى أن طرفاً اقترحه.

حتى القبول لا يساوي وصول الصفحة. يجب أن ينفذ الطرفان سلوك T.38 متوافقاً، وأن يعمل TCP أو UDP المختار عبر المسار، وأن تبقى الخسارة والتأخير وإعادة الترتيب ضمن ما تحتمله الخدمة، وأن تحول البوابات توقيت عالم الحزم إلى توقعات أجهزة الفاكس. قد تنشأ الجلسة ثم تتوقف صفحة في منتصفها.

تحتاج الإدارة إلى سلم أدلة. يثبت سجل IANA أن الرمز مسجل ويحيل إلى RFC 3362. وقد يثبت جرد البرمجيات أن تطبيقاً يتعرف عليه. ويثبت عرض SDP الاقتراح. وتثبت الإجابة القبول أو الرفض. وتثبت آثار الحزم النقل المرصود. وتثبت سجلات البوابة محاولة التحويل. وتثبت أعداد الصفحات وإشارات النهاية اكتمال التسليم التقني. أما وصول الوثيقة إلى الإنسان أو مسار العمل فهو طبقة أخرى.

لا يجوز استبدال درجة بأخرى. التسجيل ليس إحصاءً للتبني، والتعرف ليس قبولاً، والقبول ليس نقلاً، والنقل ليس صفحة كاملة ومقروءة.

تطورت قواعد التسجيل العامة بعد ذلك. كانت RFC 2048 تحدد الإجراء في زمن RFC 3362، ثم حدثت RFC 4288 وRFC 6838 الإطار. تساعد المراجعة والثبات ومنع التصادم على بناء مرجع مشترك، لكنها لا تثبت ميزة داخل جهاز.

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

يبقى سجل IANA الحالي مفيداً لأنه يحفظ image/t38 ومرجعه بعد عقود. إلا أن هذه الاستمرارية دليل على حفظ الاسم، لا على عدد البوابات أو خيار النقل أو نسبة التشفير أو نجاح الصفحات.

يستخدم هذا المقال نصين للكاتب Lu Heng بوصفهما عدستين معلنتين. يدعو “Minimum Initial Specification” إلى إبقاء الطبقة المشتركة عند الحد الضروري القابل للتحقق، ثم ترك التبني لمن يشغلون الشفرة. وتوضح RFC 3362 فائدة تلك الوصلة الضيقة. أما “On Reality Layers” فيمنع خلط السجل الرمزي بالواقع التشغيلي. التسجيل والعرض والقبول والنقل والاستلام طبقات مختلفة هنا.

نجح الرمز لأنه قال شيئاً واحداً بدقة. سمّى تدفق T.38 في وصف جلسة. وكل ادعاء يتجاوز ذلك احتاج إلى إيصال جديد.

المصادر