تحليلات
أحدث المقالات
أحدث المعلومات عن مشغلي البنية التحتية، والقرارات السياسية، والتحركات السوقية، وتحولات القوة الرقمية.
تاريخ
لم تكن الشبكة الحاملة هي الاتصال: كيف فصلت RFC 892 حالة النقل عن المسار
استخدمت RFC 892 كلمة «اتصال» لشيئين لا يجوز دمجهما: Network Connection تحمل الوحدات، وTransport Connection تحفظ الحوار الذي تنتمي إليه. لو كانتا شيئاً واحداً لما أمكن لعدة حوارات أن تشترك في حامل واحد، ولا لحوار واحد أن يوزع نفسه على عدة حوامل.
ملف القضية
المفتاح الخاص لم يغادر، لكن سلطة استخدامه عبرت الحدود: RFC 9987 والثقة المتعدية في وكيل SSH
قد يبقى المفتاح داخل جهاز مادي لا يسمح بتصديره، ومع ذلك يتحول الجهاز إلى خدمة توقيع متاحة من مضيف بعيد. حماية المادة السرية تقلل نوعاً مهماً من الخطر، لكنها لا تجيب عن السؤال التشغيلي: من يستطيع أن يطلب من المفتاح أن يعمل؟
ملف القضية
وافق العنوان الخارجي على استقبال التقرير، لا على رؤية كل الرسالة: RFC 9991 وحدود إفصاح DMARC
قد يتحقق خادم البريد من أن مزوداً خارجياً وافق عبر DNS على استقبال تقارير الفشل الخاصة بنطاق معين. هذه خطوة ضرورية، لكنها تجيب عن سؤال واحد فقط: هل يقبل المزود علاقة التلقي؟ لا تجيب عن الحقول التي يحتاجها، ولا عمّن يستطيع قراءة متن الرسالة، ولا عن مدة الاحتفاظ أو القرار الذي قد…
IETF
Gavin Brown وأمر الإنشاء الناجح الذي لم يكن قد سجّل النطاق بعد
إيصال الاستلام يثبت أن الطلب دخل النظام، لا أن صاحبه فاز بالاسم. تجعل RFC 8334 هذا الفاصل قابلاً للقياس: قد ينجح أمر EPP، ويحصل الطلب على معرّف، بينما يظل تخصيص النطاق قراراً مؤجلاً.
ملف القضية
مسودة SC100 ترسم حد DNSSEC عند المنظور الأساسي. ويجب أن يسمّيه الإيصال
اجتازت SC100 التصويت بالإجماع بين الأعضاء المشاركين، لكنها في 31 أغسطس 2026 ظلت مسودة مقبولة داخل مراجعة الملكية الفكرية. أهم ما توضحه ليس أن «DNSSEC مطلوب»؛ فهذا الالتزام قائم بالفعل. بل توضّح أن الالتزام يقع على دور محدد: منظور الشبكة الأساسي. أما المناظير البعيدة فيجوز لها…
التقارير
اعتمد مجلس APNIC «Shepherds» للموضوعات من دون نشر حدود الدور
تحتاج المجالس إلى شخص يحتفظ بذاكرة الملف بين اجتماع وآخر، لا إلى تسعة مراكز قرار. اختار المجلس التنفيذي في APNIC في مايو 2026 نموذج «Shepherd» للموضوعات الأساسية، بحيث يقود أعضاء معينون النقاش في مجالات موزعة عليهم. تبدو الفكرة عملية، لكن صفحات الحوكمة العامة المجمدة لهذه المقالة…
IETF
Russ Housley وعنوان MAC الذي استطاعت الشهادة تسميته ولم تستطع جعله فريداً
تستطيع الشهادة تثبيت ستة أو ثمانية ثمانيات بدقة. لكنها لا ترى المنفذ الذي يستخدمها الآن، ولا الإطار الذي حملها، ولا الجهة المحلية التي سمحت بما حدث بعد التحقق.
تاريخ
حمل المسار الأسرع الوقت، لكنه لم يختر الساعة المرجعية: حلقتا RFC 891
في شبكة Fuzzball كانت رسالة HELLO واحدة تحمل دليلاً يفيد قرار التوجيه وتقديراً لانحراف الساعة. غير أن الاشتراك في الرسالة لم يوحّد السلطة: المسار تحدده قياسات التأخير، والمرجع يحدده `CLOCK-HID` في الإعداد، والتصحيح الأخير تقرره الساعة المحلية.
ملف القضية
تسد SC101 فجوة في إثبات السيطرة على النطاق. لكن الانتقال يسمح بقاعدتين
إذا كتب مدقق في سبتمبر 2026 أن إصدار شهادة امتثل لأحدث TLS Baseline Requirements، فلن يكون قد حدد الخوارزمية التي نُفذت. فالنسخة 2.2.9 هي الوثيقة الجارية، لكنها تسمح حتى 15 نوفمبر باستخدام قسم 3.2.2.4 منها أو القسم نفسه من النسخة 2.2.7. أصلحت SC101 ترتيب CNAME وحذف المقاطع؛ إلا…
تاريخ
كان الإطار أطول من الرزمة: كيف أبقت RFC 894 حشو Ethernet خارج IP
كان على المستقبل أن يمسك مسطرتين في الوقت نفسه. الأولى تقيس ما سلّمته طبقة Ethernet فعليًا كي يخصص له ذاكرة كافية. والثانية، Total Length، تحدد أين تنتهي رزمة IPv4 كي لا تتحول أصفار الحشو إلى بيانات لم يرسلها التطبيق. لم يكن اختلاف القياسين تناقضًا؛ بل كان الحاجز الذي وضعته RFC…
ملف القضية
RFC 9996 يسمّي صيغة Protobuf، لكنه لا يمنح مخططها سلطة المعنى
قد تحمل الرسالة ترويسة صحيحة، ويقبلها المحلّل بلا خطأ، ثم تغيّر حساباً أو صلاحيةً على أساس معنى لم يقصده المرسل. يعالج RFC 9996 الاسم العام للصيغة الخارجية. أما اختيار نوع الرسالة، وإثبات مصدر الـdescriptor، وربط الحقول بقرار العمل، فتبقى مسؤوليات مستقلة لا تستطيع ترويسة…
التقارير
بوابة الأعضاء الجدد لدى AFRINIC تعرض ثلاثة أدلة، والروابط الثلاثة تعيد 404 نفسها
كانت بوابة NMRP متاحة وتعرض متطلبات فعلية وقناة اتصال. أما الخلل فظهر قبل بدء الطلب: الإجراء والأهلية والوثائق ثلاث وظائف مختلفة، لكنها اعتمدت على صفحة أساس واحدة أعادت 404 عند الفحص المباشر.
IETF
Benoît Claise والتوسعة التي لم تستطع الوحدة الأساسية تسميتها
لا يكفي أحياناً أن تقرأ ملف النموذج قراءة صحيحة. فقد يكون التغيير الذي يحدد شكله الفعلي مكتوباً في ملف آخر تماماً. هذه هي الفجوة التي تجعل علاقة `augment` العكسية مهمة في YANG.
اتجاهات الاتصالات الوطنية في أوروبا والشرق الأوسط
برج 4G ريفي لا يثبت التغطية المحلية حتى يتطابق المشغل والمكان
قد يكون البرج عاملاً، وقد يتحقق هدف وطني، ومع ذلك يبقى هاتف بعينه بلا خدمة مفيدة في المكان المهم. يبدأ القبول المحلي عندما يُسمّى المشغل والموقع والسياق بوضوح.
تاريخ
لم تكن الإجابة الأولى حكماً أخيراً: كيف فصلت RFC 887 بين الاكتشاف والتأكيد
أمكن لمضيف لا يعرف عنوان الخادم أن يسأل الشبكة المحلية كلها. لكن RFC 887 لم تمنح أول عنوان يصل سلطة الحقيقة النهائية: للصمت معنى، وللنفي الصريح معنى آخر، ولمعلومة الطرف الثالث وزن أضعف من جواب المزود نفسه.
ملف القضية
قد يبقى WebDriver عند مرحلة Candidate Recommendation. استشهد بالنسخة الثابتة
تجعل مسودة ميثاق Browser Testing and Tools لدى W3C خياراً غير مألوف صريحاً: يراد تطوير WebDriver وWebDriver BiDi حتى Candidate Recommendation، ثم إبقاؤهما متحركين عبر Snapshots، من دون نية معلنة للانتقال إلى Recommendation. قد يلائم ذلك بروتوكولات تعيش داخل عدة متصفحات سريعة…
IETF
Kazuho Oku والحقل الذي يجعل الرفض مفهوماً من دون أن يَعِد بالبث التدريجي
قد تبقى وصلة HTTP مفتوحة ويواصل الخادم إنتاج البيانات، ومع ذلك لا يصل أول بايت في الوقت الذي تحتاجه الخدمة. تعالج RFC 10036 جزءاً من هذا الغموض: الوسيط الذي يفهم الإشارة ويرفضها صراحةً عليه أن يُظهر الرفض، لكن الإشارة لا تُلزم وسيطاً لا يعرفها.
تاريخ
قالت القائمة «رسمي»، ولم تقل «مُنفَّذ»: كيف فصلت RFC 880 الحالة عن الشيفرة العاملة
أدرجت RFC 880 فئة اسمها None، وشرحت أنها تعني أن البند ليس بروتوكولاً أصلاً. كان وجود الفئة داخل قائمة البروتوكولات الرسمية تذكيراً مبكراً بأن الإدراج في سجل لا يحدد وحده طبيعة الشيء، فضلاً عن أن يثبت تشغيله.
ملف القضية
وقّع الغلاف الملخص، ولم يسلّم الأصل: RFC 9995 وحدود سلطة COSE Hash Envelope
يمكن لختم صحيح على إيصال مستودع أن يثبت ما كتبه مُصدره، لكنه لا يضع الصندوق في غرفة الفحص. بالطريقة نفسها، يتيح RFC 9995 التحقق من غلاف صغير يحمي ملخصاً رقمياً، حتى عندما يبقى الأصل بعيداً أو مفقوداً. النجاح التشفيري بداية سلسلة، لا نهايتها.
ملف القضية
ميثاق WebAuthn المقترح يفتح باب التوقيع على البيانات الخام، لكن النطاق ليس موافقة
يدرس W3C توسيع ولاية فريق Web Authentication لتشمل توقيع بيانات يختارها التطبيق، بوساطة WebAuthn، مع ذكر الذكاء الاصطناعي القائم على الوكلاء وبيانات الاعتماد الرقمية القابلة للتحقق ضمن أمثلة الاستخدام. هذه خطوة تتيح للفريق أن يعمل على الفكرة، وليست شهادة بأن التصميم الحالي قد نضج…