الخلاصة

  • يحدد draft-ietf-calext-vcard4-bis-00 حالات إلزامية لمطابقة البطاقات والخصائص بواسطة UID وPID وCLIENTPIDMAP، ويترك الحالات الأخرى لتقدير محرك المزامنة.
  • سلامة النقل وإصدار المورد ومطابقة السجل وقرار دمج الخاصية وصحة وسيلة الاتصال إيصالات منفصلة؛ لا يغني أحدها عن الآخر.

ختم الرسالة لا يوقع الاستنتاج

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

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

هذه ليست ثغرة في التشفير. إنها حدود السؤال الذي يجيب عنه. عندما نجعل إيصال النقل دليلاً على صحة الاستدلال، ننقل سلطة من طبقة إلى طبقة لم تمنحها إياها.

المراجعة 00 ليست RFC ولا تقرير نشر

صدرت المراجعة 00 من vCard Format Specification في 2 يوليو 2026 وتنتهي في 3 يناير 2027. وهي مسودة عمل تابعة لمجموعة CALENDAR EXTENSIONS ومقصودة لمسار المعايير، وستحل محل RFC 6350 إذا اعتُمدت. لكنها ليست RFC حتى الآن.

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

لكن التنسيق يمثل معلومات ولا يثبت الواقع الذي تصفه. بطاقة صحيحة نحوياً لا تتحقق من الشخص. قيمة UID لا تمنح إذناً قانونياً. نجاح المزامنة لا يثبت أن الرقم ما زال يعمل.

في docs/heng-lu-note.md تفصل أولوية الكود العامل بين النشر والتنفيذ والتحقق والاستخدام والنتيجة. أما الحد الأدنى للمواصفة الأولية فيدعو إلى تثبيت أقل قدر مشترك وترك القرارات المستقبلية للسياق المحلي. تنفذ vCard4-bis هذا الفصل عندما تحدد روابط قطعية ثم تسلم الباقي للمحرك.

UID يطابق تمثيلين ولا يتحقق من الشخص

تعرّف المسودة المزامنة بأنها دمج ذكي لتمثيلين للكائن نفسه. إذا كانت قيمتا UID متكافئتين، فيجب مطابقة البطاقتين.

تخضع URI الصحيحة لقواعد التكافؤ في RFC 3986. أما النص فيقارن حرفاً بحرف بعد إزالة تهريب vCard. تمنع هذه القاعدة إنشاء شخص جديد كلما عادت نسخة معدلة من بطاقة مشتركة.

لكن عدد UID المسموح هو *1: حد أقصى واحد، وليس وجوداً إلزامياً دائماً. وإذا لم يحسم UID الأمر، يجوز للمحرك المطابقة بتقديره. وحتى UID المتساوي قد يكون منسوخاً خطأ أو مستخدماً بسوء نية.

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

PID يربط الهوية المحلية بسياق المصدر

بعد مطابقة البطاقتين يجب مطابقة الخصائص. قد تحتوي البطاقة عدة EMAIL وTEL، ولذلك لا يكفي اسم الخاصية.

الحقل الأول من PID رقم محلي للقيمة. والحقل الثاني رقم مصدر صغير لا معنى له إلا داخل نسخة vCard نفسها. يربط CLIENTPIDMAP رقم المصدر بـ URI، فيمنحه سياقاً عالمياً قابلاً للمقارنة.

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

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

المقارنة والوصاية مفهومان مختلفان. CLIENTPIDMAP يخدم الأولى، لا يثبت الثانية.

القواعد الإلزامية تقلص مساحة التخمين

لا يجوز مطابقة خصائص بطاقات غير متطابقة، ولا خصائص تحمل أسماء مختلفة. وفي بطاقتين متطابقتين، يجب مطابقة الخصائص المتساوية الاسم ذات الحد الأقصى الواحد، وكذلك الخصائص ذات PID المتطابق.

تحمي هذه القواعد قابلية التشغيل البيني. فلا يتحول TEL إلى EMAIL بسبب تشابه نصي، ولا ينتقل حقل من شخص آخر، ولا يُتجاهل رابط PID ثابت حسب مزاج المورد.

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

كلمة MAY لا تجعل القرار صادراً عن IETF. إنها تحدد من يقرر محلياً. يجب على المحرك تسجيل المدخلات والتطبيع وإصدار القاعدة والثقة والعتبة والإجراء.

المواصفة تسمح بالقرار؛ لا تصدر إيصال القرار.

مثال البريد والهاتف يكشف الفرق

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

يبقى البريدان منفصلين ويُنسخان كلاهما. أما الهاتفان، فرغم اختلاف PID، يعرضان القيمة نفسها. يفترض المثال محركاً «ذكياً على نحو خاص» يطابقهما ويدمجهما.

قد يكون ذلك صحيحاً تماماً. وقد يخفي امتداداً أو استخداماً مهنياً أو فرقاً في الثقة أو مصدراً قديماً. تحتفظ خاصية TEL النهائية بكلا PID، فتظهر أن مسارين اجتمعا. لكنها لا تفسر لماذا اجتمعا.

الإيصال المطلوب منفصل: تجزئة كل مدخل، PID والخرائط الأصلية، القيمة قبل التطبيع وبعده، إصدار القاعدة أو النموذج، الثقة، السياسة، الفاعل والوقت. وإذا أكد إنسان الدمج فيجب تسجيل ذلك كحدث مستقل عن اقتراح الآلة.

تعارض CLIENTPIDMAP يوقف الإجابة المشتركة

تعالج خرائط CLIENTPIDMAP منفصلة عن الخصائص العادية. يجب أن يضمن المحرك اتساقها بين البطاقات المتطابقة. وإذا لم تكن متسقة، تترك المراجعة 00 النتيجة للمحرك ولا تحددها.

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

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

إذا اختار المنتج خريطة ثم نسب الاختيار إلى توافق vCard، فهو يخفي سلطته المحلية خلف اسم التنسيق.

التبسيط ينتج حالة أقصر لا تاريخاً أكمل

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

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

الضغط ضروري. تحتاج الأنظمة الموزعة إلى لقطات وعرض مادي سريع. ليس من المناسب تحميل كل تاريخ الأحداث داخل بطاقة قابلة للنقل.

الحل هو الفصل: بطاقة قصيرة للخدمة، وسجل طويل للتدقيق. قبل التبسيط تحفظ تجزئات المدخلات وخرائط المصدر وقرارات التعارض؛ أثناءه تحفظ علاقة الأرقام القديمة بالجديدة؛ وبعده تحفظ تجزئة الناتج.

تقول البطاقة ما يعتقده النظام الآن. ويقول الإيصال كيف وصل إليه.

لكل طبقة إيصالها

لا توفر vCard مصادقة أو سرية في ذاتها، ويمكن حملها بآليات مثل S/MIME. يوفر CardDAV سياق المجموعة وETag، وتحصي رموز WebDAV Sync الموارد المتغيرة.

هذه الأدوات لا تتنافس، بل تجيب عن أسئلة مختلفة. يثبت التوقيع سلامة النقل وهوية اعتماد. يحدد ETag النسخة. يحدد الرمز نطاق التغييرات.

أما مطابقة الشخص والخاصية وحل التعارض فهي قرارات دلالية لاحقة. وحتى بعدها لا نعرف أن الهاتف يصل إلى الشخص المقصود إلا بالملاحظة أو التأكيد.

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

SOURCE وREV لا يشكلان دفتر منشأ لكل حقل

يمكن لـ SOURCE الإشارة إلى مكان البيانات، ويمكن لـ REV بيان وقت تحديث البطاقة. يساعدان في إدارة التقادم.

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

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

النجاح ليس مجرد وصول الجهازين إلى النص نفسه

راقب نسبة مطابقة البطاقات بواسطة UID مقابل التخمين، ومطابقة الخصائص بواسطة PID مقابل التقدير، وتعارضات CLIENTPIDMAP، والدمج الذي يتراجع عنه المستخدم، والقيم المحذوفة، والتبسيط بلا خريطة تحويل، والفشل بعد المزامنة.

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

تظهر قوة vCard4-bis في أنها لا تدعي امتلاك كل الإجابات. يملك التنسيق البنية والروابط القطعية. يملك المحرك التخمين. يملك التطبيق سياسة التعارض. يملك المشغل النشر والتدقيق. وتكشف الوقائع لاحقاً صحة وسيلة الاتصال.

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

Sources