الخلاصة

  • يربط localizations أوسمة RFC 5646 بكائنات PatchObject؛ ينسخ RFC 9553 البطاقة دون هذا العضو ويطبق الرقعة كلها على النسخة.
  • الرفض الكامل يمنع نتيجة نصف مطبقة، لكنه لا يوثق الكاتب ولا يعتمد اسماً بديلاً ولا يثبت صلاحية البيانات أو حق التغيير.
  • يحتفظ الدليل القابل للمساءلة ببصمة الأساس والوسم المختار والرقعة والتفويض وبصمة الناتج والاستعمال اللاحق.

الصورة الكاملة ليست أصلاً آخر

لا يرى القارئ عمليات على مسارات JSON. يرى بطاقة كاملة: اسم ومسمى وعنوان ووسائل اتصال. لذلك يسهل أن يظن أن لكل لغة مصدراً مستقلاً راجع كل هذه الحقائق.

في RFC 9553 يكون localizations خريطة من وسم اللغة إلى PatchObject. يحدد التطبيق الوسم، ويأخذ الرقعة الموافقة، وينسخ Card الأساس من دون نسخ localizations، ثم يطبق التغييرات وقد يضبط language في النسخة. النتيجة هي النسخة المحلية من البطاقة الأصلية.

لا يُنشأ uid جديد، ولا يعرّف المعيار تاريخ مراجعة مستقل أو تحققاً جديداً للحقائق. ترث النسخة كل ما لم تغيره من الأساس، وتستمد الفروق من رقعة واحدة ومن سياسة اختيار اللغة.

إذا حفظ النظام الناتج وحده فقد الدليل على مدخلاته. عندما يظهر خطأ في المسمى لن يُعرف هل سببه أساس قديم، أو رقعة قديمة، أو fallback، أو ذاكرة مخبأة. يتحول الإسقاط القابل للإعادة إلى نسخة مستقلة مجهولة النسب.

الذرية تحمي البنية لا الحقيقة

يستخدم PatchObject مجموعة غير مرتبة من المسارات المبنية على جزء من JSON Pointer مع شرطة مائلة أولى ضمنية. يجب أن توجد كل عقد المسار السابقة للأخيرة. يمكن استبدال عضو قائم في مصفوفة، ولا يمكن استعمال للإدراج أو الحذف. لا يجوز أن يكون مسار بادئة لمسار آخر. ويجب أن تلائم القيمة نوع الخاصية؛ ولا يحذف null إلا خاصية اختيارية.

إذا كانت رقعة واحدة غير صالحة، يجب رفض PatchObject كله، ويحظر تطبيق الجزء السليم. تمنع هذه القاعدة بطاقة تغيّر فيها الاسم بينما يفشل العنوان بصمت.

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

لذلك يجب فصل الحالات: JSON مقروء، نموذج صالح، رقعة قابلة للتطبيق، مصدر موثق، حقل مأذون، اسم معتمد، حقيقة حديثة، واتصال ناجح. كلمة «محلي» لا تمنح حكماً جامعاً.

المسار مرتبط بجيل الأساس

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

يجب الحفاظ على مفاتيح Id في الخرائط عبر نسخ كائن JSContact نفسه، وهذا يجعل الرقع الدقيقة ممكنة. لكن تكرار Id في خريطتين أو بطاقتين لا ينشئ علاقة دلالية. t1 إحداثي محلي لا هوية عالمية.

قد تستمر رقعة معتمدة للبصمة A في النجاح على B مع أن t1 صار مسمى آخر. وقد تفشل إذا اختفى المفتاح. وقد تبقى صحيحة إن تغيّر حقل غير ذي صلة. المدقق يكتشف الفشل البنيوي، ولا يقرر وحده الحالتين الأخريين.

تشير updated إلى آخر تعديل لبيانات Card، لا إلى الحقل المعدل أو الكاتب أو المصدر أو القيمة السابقة أو إعادة مراجعة اللغات. وprodId يعرّف المنتج لا الموقّع. أما version فيحدد نموذج JSContact المسجل، لا جيل سجل الأعمال.

لهذا يجب ربط بصمة الرقعة ببصمة الأساس وبفترة النفاذ. صحة المسار وحدها لا تمنع بقاء عبارة قديمة.

وسم اللغة لا يعتمد اسماً رسمياً

تصف أوسمة RFC 5646 اللغة والكتابة والمنطقة عند الحاجة. يبدأ RFC 9553 بطلب تحديد الوسم، لكنه لا يقرر سياسة المنتج كاملة: المطابقة الدقيقة، fallback الإقليمي، تفضيل الكتابة والعودة إلى اللغة الأساسية قرارات تطبيق.

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

يحمل PatchObject البديل ولا يرفعه إلى alias رسمي. ينبغي أن يرتبط تغيير اسم شخص أو مؤسسة بمصدر رسمي متعدد اللغات، أو اسم أقره صاحبه، أو قاعدة نقحرة مراجعة. من دون ذلك يملك النظام خيار عرض لا حقيقة هوية جديدة.

وينطبق الأمر على العنوان والمسمى. قد يكون التغيير ترتيباً صحيحاً للمكونات، وقد يبدل ولاية أو مرتبة وظيفية. النوع الصحيح لا يميز بينهما.

يستطيع المهاجم أن يكتب بلغة مقنعة

تصف اعتبارات الأمن معلومات الاتصال بأنها شديدة الحساسية؛ فقد تكشف الهوية والموقع وبيانات الاعتماد والعمل والاهتمامات والعلاقات. وتذكر التنصت وإعادة الإرسال والإدراج والحذف والتعديل وهجوم المسار.

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

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

قد يثبت TLS أي خدمة سلمت Card من دون أن يثبت حقها في كل حقل. قد تنسب التوقيعات الرقعة من دون موافقة صاحب الاسم. وقد يرفض schema مساراً خاطئاً ولا يكتشف كذبة من النوع الصحيح.

سجل IANA ينسق المفردات

يسجل RFC 9553 الإصدار 1.0 وينشئ سجلات IANA للإصدارات والخصائص والأنواع والقيم المعدودة. تسمح حدود Since Version وUntil Version بمعرفة النموذج الذي يعرّف العنصر.

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

يجب أن تعني عبارة «JSContact صالح» الصلاحية تحت نموذج ولقطة سجل معلومة. تحويلها إلى «اتصال موثق» يخلط حوكمة التنسيق بإثبات الهوية.

سجل نسب صغير يكفي

يحفظ الإيصال uid وإصدار النموذج وبصمة الأساس وجيله؛ والطلب أو القاعدة التي اختارت الوسم؛ ونص PatchObject وبصمته ومصدره ونطاق سلطته؛ ونتيجة التحقق الكامل؛ وبصمة الناتج ووقته والمستهلك التالي.

عند تغيير اسم محمي، تضاف بينة اعتماد alias أو النقحرة. وعندما يحرك بريد أو هاتف أو عنوان عملاً آلياً، تسجل الحركة والنتيجة. العرض الناجح لا يثبت التسليم.

عند تحديث الأساس يمكن تصنيف كل رقعة: لم تتأثر، تحتاج مراجعة، أو أصبحت غير قابلة للتطبيق. لا حاجة إلى تسع قواعد حقائق منفصلة تأمل أن تبقى متوافقة.

تزيد المحلية الفهم حين تبقى تحولاً قابلاً للتفسير. وتفقد الثقة حين تمحو الواجهة الطريق بين النص والحقيقة والسلطة والأثر.

المصادر