فقدت بطاقة الاتصال UID، لكنها لم تفقد حدودها: RFC 9982 وسلطة هوية السجل

الخلاصة

• يجعل RFC 9982 خاصية uid اختيارية في Card من JSContact 2.0، ويلزم المحوّل ألا ينشئ uid لنسخة 2.0 عندما تغيب UID عن vCard المصدر.
• يجعل المعرّف السجل قابلاً للإشارة داخل نموذج معين، لكنه لا يثبت وحده هوية الشخص أو صحة العلاقة أو مصدر الادعاء أو الإذن بدمج أو تعديل السجلات.

كان JSContact سابقاً يطلب uid من كل Card، وهو أمر مفهوم لبروتوكولات التزامن التي تحتاج مقبضاً ثابتاً. لكن UID في vCard اختيارية. لذلك كان تحويل vCard بلا UID يفرض في القاعدة القديمة إنشاء قيمة، من دون ضمان أن تنتج تطبيقات مختلفة، أو تحويلات متكررة، القيمة نفسها. قد تبدأ هذه القيمة كحل تقني، ثم تدخل حقلي members أو relatedTo وتصبح أساس علاقة بين بطاقتين رغم أن المصدر لم يصرح بها.

يضع RFC 9982 حداً أدق. تبقى Card بلا uid صالحة في الإصدار 2.0؛ لا ينبغي رفضها لمجرد الغياب. لكنها لا يمكن أن تظهر عضواً في members ولا طرفاً في relatedTo. هذا لا يعني أن جهة الاتصال غير موجودة أو أن بقية البيانات بلا قيمة. معناه فقط أن السجل لا يملك المرساة التي يطلبها النموذج قبل بناء وصلة قابلة للقراءة الآلية.

قاعدة التحويل تؤكد المعنى. إن غابت UID في vCard، يجب أن يبقى uid غائباً عند التحويل إلى 2.0 أو أحدث. في 1.0 كانت القيمة تولد بطريقة خاصة بالتنفيذ، مع توصية بالثبات لا تزيل التباس التشغيل البيني. لا يحول الإصدار الجديد الفراغ إلى حقيقة؛ بل يمنع مفتاحاً مؤقتاً من حمل ادعاء دائم عن العلاقة.

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

قد يحتاج CardDAV أو JMAP Contacts إلى مفتاح لأغراض البروتوكول، بينما لا يحتاجه RDAP. هذه احتياجات مختلفة، لا فجوة تبرر اختراع هوية. القراءة المستلهمة من Heng Lu ترى في الحد الأدنى المشترك قيمة لأنه يتيح التبادل من دون مصادرة قرار المطابقة والعلاقة والتحديث من أصحابه المحليين.