الخلاصة

  • جعل RFC 2422 ترتيب البايتات جزءاً من عقد audio/32KADPCM: توضع كلمة الترميز الأسبق في نصف البايت الأدنى، وتليها الثانية في النصف الأعلى.
  • إذا كان عدد كلمات الترميز فردياً، يفضّل المعيار إكمال العينة بصمت؛ وإلا تُسقط الكلمة الأخيرة. يحسم ذلك كيفية تفسير البايت، لكنه لا يثبت وصول رسالة أو سماعها.

كان الجزء الرياضي من عمل المرمّز قد أُنجز بالفعل. فقد وصف توصيف ITU-T G.726 التضمين النبضي التفاضلي التكيفي والتحويل بين PCM بقانون A أو μ وبمعدل 64 كيلوبت في الثانية، مع أخذ 8000 عينة كل ثانية، وبين قنوات أقل سرعة، منها 32 كيلوبت في الثانية. عند هذا المعدل تُمثّل كل عينة بأربعة بتات. يوضح ذلك كيف تتولد كلمة الترميز، لكنه لا يحدد وحده أي نصف من بايت ذي ثمانية بتات يحتوي الكلمة الأسبق.

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

كان RFC 1911 قد أدرج Audio/32KADPCM ضمن صيغ الصوت العامة الإلزامية في ملفه التجريبي Voice Profile for Internet Mail. وبذلك حدّد موضع الترميز في ملف مراسلة مقيّد، لكنه لم يحسم ترتيب البتات الأربعة. أما RFC 2422، المنشور في سبتمبر 1998 ضمن مسار المعايير، فقد صيغ صراحة لتدقيق التسجيل السابق وسد هذه الفجوة. سجّل audio/32KADPCM لبيانات G.726، وجعل عرفاً واحداً للتسلسل جزءاً من معنى النوع الفرعي نفسه.

التوزيع محدد بدقة. في كل ثمانيّة، تشغل كلمة الترميز الأولى A البتات من 0 إلى 3، ويوضع بتها الأقل قيمة A0 عند أقل بت في الثمانيّة. وتشغل الكلمة التالية B البتات من 4 إلى 7، مع وجود B3 عند الطرف الأعلى قيمة. ويتكرر النمط نفسه مع كل زوج لاحق. ليست هذه عملية قلب لتدفق الصوت كله ولا تغييراً في المتنبئ التكيفي لـ G.726؛ إنها قاعدة لترتيب نصفَي البايت الواحد.

وتوزع هذه الدقة العمل أيضاً. يذكر RFC 2422 أن مرمّزات G.726 الموجودة قد تختلف في ترتيب كلمات الترميز. ولأن هذا النوع من MIME لا يقبل إلا ترتيب little-endian، فعلى المرمّز الذي يستخدم الترتيب المقابل أن يعيد ترتيب الكلمات قبل التخزين في هذا النوع أو بعد استخراجه منه. لم يكن الاسم المشترك وحده ليجعل تلك المرمّزات متوافقة. يجعل المعيار موضع التحويل ظاهراً وقابلاً للاختبار عند الحد الفاصل، بدلاً من ترك كل زوج من التطبيقات يتفاوض سراً.

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

لا يتطلب النوع الفرعي أي معاملات ولا يتيح معاملات اختيارية. ويحمل المتن صوت G.726 الثنائي بلا معلومات ترويسة صوتية؛ ويمكن أن يكون ترميز النقل في MIME ثنائياً أو، غالباً، Base64. هذان قراران منفصلان. يغير Base64 طريقة عبور الثمانيّات داخل نظام البريد، لكنه لا يغير موضع A أو B بعد فك ترميز المتن. واعتبار ترميز النقل جواباً عن ترتيب كلمات الترميز يخلط بين غلاف البايت ومعناه.

وهكذا يقدم RFC 2422 قصة موجزة لكنها مؤثرة عن وضع المعايير. فتحديد التحويل لا يكفي دائماً لتعريف كائن قابل للتبادل بين التطبيقات. وما إن تعبر المخرجات حدود الأنظمة حتى يصبح الترتيب والإكمال وتوزيع المسؤولية جزءاً من العقد. لا يبين المستند مدى انتشار التنفيذ أو أي مرمّز أخطأ أو ما إذا كان المستلم قد سمع الرسالة. لكنه يبين أين يجب أن يحسم التطبيق اختياره، وأين يتوقف النوع الفرعي MIME عن ترك هذا الاختيار محلياً.