درخواست نظرات

از ویکیپدیا، دانشنامه آزاد
پرش به ناوبری پرش به جستجو

A Request for Comments ( RFC ) یک نشریه در مجموعه‌ای است که توسط سازمان‌های اصلی توسعه فنی و تنظیم استاندارد برای اینترنت ، که برجسته‌ترین آنها کارگروه مهندسی اینترنت (IETF) می‌باشد. یک RFC توسط افراد یا گروه‌هایی از مهندسان و دانشمندان کامپیوتر در قالب یادداشتی که روش‌ها، رفتارها، تحقیقات یا نوآوری‌های قابل اجرا در کار اینترنت و سیستم‌های متصل به اینترنت را توصیف می‌کند، تالیف می‌شود. این یا برای بررسی همتایان یا برای انتقال مفاهیم جدید، اطلاعات، یا گاهی اوقات، طنز مهندسی ارسال می شود. [1]

IETF برخی از پیشنهادات منتشر شده به عنوان RFC به عنوان استانداردهای اینترنت را پذیرفته است. با این حال، بسیاری از RFC ها ماهیت اطلاعاتی یا تجربی دارند و استاندارد نیستند. [2] سیستم RFC توسط استیو کراکر در سال 1969 برای کمک به ثبت یادداشت های غیر رسمی در مورد توسعه ARPANET اختراع شد . RFC ها از آن زمان به اسناد رسمی مشخصات اینترنت ، پروتکل های ارتباطی ، رویه ها و رویدادها تبدیل شده اند. [3] به گفته کراکر، اسناد "عملکرد درونی اینترنت را شکل می دهند و نقش مهمی در موفقیت آن ایفا کرده اند"، اما به طور گسترده در خارج از جامعه شناخته شده نیستند. [4]

خارج از جامعه اینترنتی، اسناد دیگری نیز به نام درخواست برای اظهار نظر در کار دولت فدرال ایالات متحده منتشر شده است ، مانند اداره ملی ایمنی ترافیک بزرگراه . [5]

تاریخچه

شروع فرمت RFC در سال 1969 به عنوان بخشی از پروژه اصلی ARPANET رخ داد . [4] امروزه، این کانال رسمی انتشار برای گروه ویژه مهندسی اینترنت (IETF)، هیئت معماری اینترنت (IAB) و - تا حدی - جامعه جهانی محققان شبکه های کامپیوتری به طور کلی است.

نویسندگان اولین RFC کار خود را تایپ کردند و نسخه های چاپی آن را در میان محققان ARPA منتشر کردند. بر خلاف RFC های مدرن، بسیاری از RFC های اولیه درخواست های واقعی برای نظرات بودند و برای جلوگیری از به نظر رسیدن بیش از حد توضیحی و تشویق بحث به این عنوان عنوان می شدند. [6] [7] RFC سؤالات را باز می گذارد و به سبک کمتر رسمی نوشته شده است. این سبک کمتر رسمی اکنون در اسناد پیش نویس اینترنتی معمول است، مرحله پیشرو قبل از تایید به عنوان RFC.

در دسامبر 1969، محققان شروع به توزیع RFCهای جدید از طریق ARPANET کردند. RFC  1 با عنوان "نرم افزار میزبان" توسط استیو کراکر از دانشگاه کالیفرنیا، لس آنجلس (UCLA) نوشته شد و در 7 آوریل 1969 منتشر شد . بحث گروهی بین استیو کراکر، استیو کار و جف رولیفسون .

در RFC 3 که برای اولین بار سری RFC را تعریف کرد، کراکر شروع به نسبت دادن سری RFC به گروه کاری شبکه کرد. به جای اینکه یک کمیته رسمی باشد، یک انجمن آزاد از محققان علاقه مند به پروژه ARPANET بود. در واقع، شامل هر کسی می‌شد که می‌خواست به جلسات و بحث‌های مربوط به پروژه بپیوندد.

بسیاری از RFCهای بعدی دهه 1970 نیز از UCLA آمدند، زیرا UCLA یکی از اولین پردازنده‌های پیام رابط (IMP) در ARPANET است. مرکز تحقیقات تقویت (ARC) در موسسه تحقیقاتی استنفورد ، به کارگردانی داگلاس انگلبارت ، یکی دیگر از چهار گره اولیه ARPANET و منبع RFCهای اولیه است. ARC به اولین مرکز اطلاعات شبکه ( InterNIC ) تبدیل شد که توسط الیزابت جی. فاینلر مدیریت شد تا RFCها را همراه با سایر اطلاعات شبکه توزیع کند. [9] از سال 1969 تا 1998، جان پستل به عنوان ویراستار RFC خدمت کرد.. پس از مرگ او در سال 1998، آگهی ترحیم او با نام RFC 2468 منتشر شد.

پس از انقضای قرارداد اصلی ARPANET با دولت فدرال ایالات متحده، انجمن اینترنت به نمایندگی از IETF، با بخش شبکه‌ای مؤسسه علوم اطلاعات دانشگاه کالیفرنیای جنوبی (USC) قراردادی امضا کرد تا سردبیری و سردبیری را بر عهده بگیرد. مسئولیت های انتشار تحت هدایت IAB. سندی گینوزا در سال 1999 به USC/ISI ملحق شد تا روی ویرایش RFC کار کند و آلیس هاگنز در سال 2005. [10] باب برادن نقش رهبری پروژه RFC را بر عهده گرفت، در حالی که جویس کی. رینولدز تا 13 اکتبر به عنوان بخشی از تیم ادامه داد. 2006.

در جولای 2007، جریان های RFC تعریف شد، به طوری که وظایف ویرایش می تواند تقسیم شود. اسناد IETF از گروه های کاری IETF یا موارد ارسالی ارائه شده توسط مدیر منطقه IETF از گروه راهبری مهندسی اینترنت ارائه شده است. IAB می تواند اسناد خود را منتشر کند. یک جریان تحقیقاتی از اسناد از گروه ویژه تحقیقات اینترنت (IRTF) و یک جریان مستقل از سایر منابع خارجی می آید. [11] مدل جدیدی در سال 2008 پیشنهاد شد، پالایش شد و در آگوست 2009 منتشر شد و وظیفه را به چندین نقش تقسیم کرد، [12] از جمله گروه مشاوره سری RFC (RSAG). این مدل در سال 2012 به روز شد. [13]این استریم ها نیز در دسامبر 2009 با استانداردهایی که برای سبک آنها تعریف شده بود، اصلاح شدند. [14] در ژانویه 2010، عملکرد ویرایشگر RFC به یک پیمانکار، انجمن مدیریت راه حل، با گلن کواک به عنوان ویرایشگر سری موقت منتقل شد. [15] در اواخر سال 2011، هدر فلانگان به عنوان ویرایشگر دائمی سری RFC استخدام شد. همچنین در آن زمان، کمیته نظارت بر سری RFC (RSOC) ایجاد شد. [16]

درخواست‌ها برای نظرات در ابتدا در قالب متن غیرقابل جریان تولید شدند. در آگوست 2019 فرمت تغییر کرد تا اسناد جدید در دستگاه‌هایی با اندازه‌های نمایش متفاوت به‌طور بهینه قابل مشاهده باشند. [17]

تولید و نسخه سازی

ویرایشگر RFC به هر RFC یک شماره سریال اختصاص می دهد . پس از اختصاص یک شماره و انتشار، یک RFC هرگز لغو یا اصلاح نمی شود. اگر سند نیاز به اصلاح داشته باشد، نویسندگان یک سند اصلاح شده را منتشر می کنند. بنابراین، برخی از RFC ها جایگزین دیگران می شوند. گفته می شود که RFCهای جایگزین شده توسط RFC جایگزین منسوخ ، منسوخ یا منسوخ شده اند. RFCهای سریالی با هم یک رکورد تاریخی پیوسته از تکامل استانداردها و شیوه های اینترنت را تشکیل می دهند. فرآیند RFC در RFC 2026 ( فرایند استانداردهای اینترنت، ویرایش 3 ) مستند شده است. [18]

فرآیند تولید RFC با فرآیند استانداردسازی سازمان های استاندارد رسمی مانند سازمان بین المللی استاندارد (ISO) متفاوت است. کارشناسان فناوری اینترنت ممکن است پیش نویس اینترنت را بدون پشتیبانی یک موسسه خارجی ارسال کنند. RFC های استاندارد با تأیید IETF منتشر می شوند و معمولاً توسط کارشناسان شرکت کننده در گروه های کاری IETF تولید می شوند که ابتدا پیش نویس اینترنتی را منتشر می کنند. این رویکرد دورهای اولیه بررسی همتایان را قبل از بلوغ اسناد به RFC تسهیل می کند. [ نیازمند منبع ]

سنت RFC از تألیف استانداردهای عملی، مبتنی بر تجربه و پس از واقعیت که توسط افراد یا گروه‌های کاری کوچک انجام می‌شود، می‌تواند مزایای مهمی را نسبت به فرآیند رسمی‌تر و کمیته‌محور معمول ISO و سازمان‌های استاندارد ملی داشته باشد . [ نیازمند منبع ]

اکثر RFC ها از مجموعه عبارات مشترکی مانند "MUST" و "NOT RECOMMENDED" (همانطور که توسط RFC 2119 و RFC 8174 تعریف شده است)، فرم Backus–Naur تقویت شده (ABNF) (RFC 5234) به عنوان یک زبان فرا زبان، و متن ساده استفاده می کنند. قالب بندی مبتنی بر، به منظور حفظ RFC ها سازگار و آسان برای درک. [18]

زیر مجموعه

سری RFC شامل سه زیر مجموعه برای RFCهای IETF است : BCP، FYI، و STD. بهترین روش فعلی (BCP) زیر مجموعه ای از RFCهای اجباری IETF است که در مسیر استاندارد نیستند. برای اطلاعات شما (FYI) زیر مجموعه ای از RFC های اطلاعاتی است که توسط IETF همانطور که در RFC 1150 (FYI 1) مشخص شده است، تبلیغ می شود. در سال 2011، RFC 6360 FYI 1 را منسوخ کرد و این زیر مجموعه را به پایان رساند. استاندارد (STD) سومین و بالاترین سطح بلوغ مسیر استانداردهای IETF بود که در RFC 2026 (BCP 9) مشخص شده بود. در سال 2011، RFC 6410 (بخش جدیدی از BCP 9) مسیر استاندارد را به دو سطح بلوغ کاهش داد. [ نیازمند منبع ]

جریان‌ها

چهار جریان RFC وجود دارد: IETF ، IRTF ، IAB ، و ارسال مستقل . [19] فقط IETF BCP و RFC را در مسیر استاندارد ایجاد می کند. یک ارسال مستقل توسط IESG برای تضاد با کار IETF بررسی می شود. کیفیت توسط یک هیئت تحریریه ارسالی مستقل ارزیابی می شود . به عبارت دیگر، IRTF و RFCهای مستقل  قرار است حاوی اطلاعات یا آزمایشات مرتبط برای اینترنت در کل باشد که با کار IETF در تضاد نباشد. RFC 4846، RFC 5742 و RFC 5744 را مقایسه کنید. [ نیاز به نقل از ]

دریافت RFC

انواع رسانه RFC 2046 نوامبر 1996


   الف. گرامر جمع آوری شده ................................... 43

1. معرفی

   اولین سند در این مجموعه، RFC 2045، تعدادی هدر را تعریف می کند
   فیلدها، از جمله Content-Type. از قسمت Content-Type استفاده می شود
   ماهیت داده ها را در بدنه یک موجودیت MIME، توسط
   دادن شناسه های نوع و زیرنوع رسانه، و با ارائه کمکی
   اطلاعاتی که ممکن است برای انواع رسانه های خاص مورد نیاز باشد. بعد از
RFC  2046 که نوع text/plain MIME را تعریف می کند ، خود یک متن ساده است.

منبع رسمی RFCها در شبکه جهانی وب ، ویرایشگر RFC است. تقریباً هر RFC منتشر شده را می توان از طریق یک URL به شکل http://www.rfc-editor.org/rfc/rfc5000.txt که برای RFC 5000 نشان داده شده است، بازیابی کرد.

هر RFC به صورت متن ASCII ساده ارسال می‌شود و در آن فرم منتشر می‌شود، اما ممکن است در قالب‌های دیگر نیز موجود باشد .

برای دسترسی آسان به ابرداده یک RFC، از جمله چکیده، کلمات کلیدی، نویسنده(ها)، تاریخ انتشار، خطا، وضعیت، و به خصوص به روز رسانی های بعدی، سایت ویرایشگر RFC فرم جستجو با ویژگی های بسیاری را ارائه می دهد. یک تغییر مسیر چند پارامتر کارآمد را تنظیم می کند، به عنوان مثال: rfc:5000 . [ نیازمند منبع ]

شماره سریال استاندارد بین المللی رسمی (ISSN) سری RFC 2070–1721 است. [14]

وضعیت

همه RFC ها استاندارد نیستند. [20] [21] هر RFC با توجه به وضعیت در فرآیند استانداردسازی اینترنت یک نام اختصاص داده می شود. این وضعیت یکی از موارد زیر است: اطلاعاتی ، تجربی ، بهترین عملکرد فعلی ، مسیر استاندارد ، یا تاریخی .

هر RFC ثابت است. اگر سند تغییر کند، دوباره ارسال می شود و یک شماره RFC جدید به آن اختصاص می یابد. [ نیازمند منبع ]

آهنگ استاندارد

اسناد مسیر استاندارد بیشتر به اسناد استاندارد پیشنهادی و استاندارد اینترنت تقسیم می شوند . [22]

فقط IETF که توسط گروه هدایت مهندسی اینترنت (IESG) نمایندگی می‌شود، می‌تواند استانداردهای RFC را تأیید کند.

اگر یک RFC به استاندارد اینترنت (STD) تبدیل شود، یک شماره STD به آن اختصاص داده می شود اما شماره RFC خود را حفظ می کند. فهرست قطعی استانداردهای اینترنت، استانداردهای رسمی پروتکل اینترنت است. قبلاً STD 1 برای حفظ یک عکس فوری از لیست استفاده می شد. [23]

هنگامی که یک استاندارد اینترنت به روز می شود، شماره STD آن ثابت می ماند و اکنون به یک RFC جدید یا مجموعه ای از RFC ها اشاره می کند. یک استاندارد اینترنت معین، STD n ، ممکن است در یک زمان معین RFCs x و y باشد، اما بعداً همان استاندارد ممکن است به‌جای آن RFC z به‌روزرسانی شود . به عنوان مثال، در سال 2007 RFC 3700 یک استاندارد اینترنت بود — STD 1 — و در می 2008 با RFC 5000 جایگزین شد، بنابراین RFC 3700 به تاریخی تغییر کرد ، RFC 5000 به استاندارد اینترنت تبدیل شد و از می 2008 STD 1 RFC 5000 شد. از دسامبر 2013 RFC 5000 با RFC 7100 جایگزین شد و RFC 2026 را به روز کرد تا دیگر از STD 1 استفاده نشود.

(بهترین شیوه های فعلی به روشی مشابه کار می کنند؛ BCP n به یک RFC یا مجموعه ای از RFC ها اشاره دارد، اما RFC یا RFC ها ممکن است در طول زمان تغییر کنند).

اطلاعاتی

یک RFC اطلاعاتی می تواند تقریباً هر چیزی باشد، از شوخی های 1 آوریل گرفته تا RFC های ضروری شناخته شده مانند ساختار سیستم نام دامنه و تفویض اختیار (RFC 1591). برخی از RFCهای اطلاعاتی زیر مجموعه FYI را تشکیل دادند.

آزمایشی

یک RFC آزمایشی می تواند یک سند IETF یا یک ارسال فردی به ویرایشگر RFC باشد. یک پیش نویس آزمایشی تعیین می شود اگر مشخص نباشد که پروپوزال همانطور که در نظر گرفته شده کار می کند یا اینکه آیا پیشنهاد به طور گسترده پذیرفته می شود نامشخص است. یک RFC آزمایشی اگر محبوب شود و به خوبی کار کند ممکن است به مسیر استاندارد ارتقا یابد. [24]

بهترین روش فعلی

مجموعه فرعی Best Current Practice اسناد اداری و سایر متون را جمع آوری می کند که به عنوان قوانین رسمی در نظر گرفته می شوند و نه تنها اطلاعاتی هستند، بلکه روی داده های سیمی تأثیری ندارند . مرز بین مسیر استاندارد و BCP اغلب نامشخص است. اگر سندی فقط بر فرآیند استانداردهای اینترنت تأثیر بگذارد، مانند BCP 9، [25] یا مدیریت IETF، به وضوح یک BCP است. اگر فقط قوانین و مقرراتی را برای ثبت‌های مرجع شماره‌های اختصاص داده شده به اینترنت (IANA) تعریف کند، واضح نیست. بیشتر این اسناد BCP هستند، اما برخی در مسیر استاندارد هستند.

مجموعه BCP همچنین توصیه های فنی برای نحوه اجرای استانداردهای اینترنت را پوشش می دهد. به عنوان مثال، توصیه به استفاده از فیلتر منبع برای دشوارتر کردن حملات DoS (RFC 2827: " فیلتر ورود به شبکه: شکست حملات انکار سرویس که از جعل آدرس منبع IP استفاده می کنند ") BCP 38 است.

تاریخی

یک RFC تاریخی ، فناوری تعریف شده توسط RFC دیگر برای استفاده توصیه نمی شود، که با سرصفحه "Obsoletes" در یک RFC جایگزین متفاوت است. برای مثال، RFC 821 ( SMTP ) خود توسط RFC های جدیدتر منسوخ شده است، اما خود SMTP هنوز "فناوری فعلی" است، بنابراین در وضعیت "تاریخی" نیست. [26] با این حال، از آنجایی که نسخه 4 BGP به طور کامل جایگزین نسخه های قبلی BGP شده است، RFC هایی که آن نسخه های قبلی را توصیف می کنند، مانند RFC 1267، تاریخی تعیین شده اند.

ناشناخته

وضعیت ناشناخته برای برخی از RFCهای بسیار قدیمی استفاده می‌شود، جایی که مشخص نیست اگر سند امروز منتشر شود، چه وضعیتی خواهد داشت. برخی از این RFC ها امروز اصلا منتشر نمی شوند. یک RFC اولیه اغلب فقط همین بود: یک درخواست ساده برای نظرات، که برای مشخص کردن پروتکل، رویه اداری یا هر چیز دیگری که امروز سری RFC برای آن استفاده می شود، در نظر گرفته نشده است. [27]

حق چاپ

قاعده کلی این است که نویسندگان اصلی (یا کارفرمایان آنها، در صورتی که شرایط شغلی آنها چنین باشد) حق چاپ را حفظ می کنند مگر اینکه به طور صریح حقوق خود را منتقل کنند. [28]

یک نهاد مستقل، IETF Trust، حق تکثیر برخی از RFCها را در اختیار دارد و برای همه سایرین مجوزی توسط نویسندگان اعطا شده است که به آن اجازه می دهد RFC ها را بازتولید کند. [29] انجمن اینترنت در بسیاری از RFCها قبل از RFC4714 به عنوان مالک حق چاپ ارجاع شده است، اما حقوق خود را به IETF Trust منتقل کرد. [30]

همچنین ببینید

منابع

  1. وایتزمن، دیوید (1 آوریل 1990). استانداردی برای انتقال دیتاگرام های IP در حامل های پرندگان . IETF _ doi : 10.17487/RFC1149 . RFC 1149 . بازبینی شده در 29 مارس 2017 .
  2. ^ هویتما، مسیحی ؛ پستل، جان ؛ کراکر، استیو (آوریل 1995). همه RFCها استاندارد نیستند . IETF _ doi : 10.17487/RFC1796 . RFC 1796 . بازبینی شده در 15 مه 2018 .
  3. «RFC، درخواست اینترنت برای نظرات» . Livinginternet.com _ بازیابی شده در 3 آوریل 2012 .
  4. a b "استیون دی. کراکر، اینترنت چگونه قوانین خود را بدست آورد ، نیویورک تایمز، 6 آوریل 2009" . Nytimes.com _ 7 آوریل 2009 . بازیابی شده در 3 آوریل 2012 .
  5. ^ اطلاعیه و درخواست نظرات ، در ثبت نام فدرال (16 ژانویه 2018).
  6. ^ هافنر، کتی؛ لیون، متیو (1996). جادوگران تا دیروقت بیدار می مانند: ریشه های اینترنت.
  7. متز، کید (18 مه 2012). "با مردی آشنا شوید که دستورالعمل های اینترنت را اختراع کرد" . سیمی . بازبینی شده در 18 دسامبر 2018 .
  8. کراکر، استیو (7 آوریل 1969). "RFC 1" .  {{cite journal}}:استناد به مجله نیاز دارد |journal=( کمک )
  9. الیزابت جی. فینلر (ژوئیه–سپتامبر ۲۰۱۰). «مرکز اطلاعات شبکه و آرشیو آن». Annals of History of Computing . 32 (3): 83-89. doi : 10.1109/MAHC.2010.54 . S2CID 206443021 . 
  10. لسلی دایگل (مارس 2010). "ویرایشگر RFC در انتقال: گذشته، حال و آینده" . مجله پروتکل اینترنت جلد 13، شماره 1. سیسکو سیستم . بازیابی شده در 17 اوت 2011 .
  11. دایگل، لزلی (ژوئیه 2007). سری RFC و ویرایشگر RFC . IETF _ doi : 10.17487/RFC4844 . RFC 4844 .
  12. کلکمن، اولاف (اوت 2009). مدل ویرایشگر RFC (نسخه 1) . IETF _ doi : 10.17487/RFC5620 . RFC 5620 .
  13. کلکمن، اولاف؛ هالپرن، جوئل (ژوئن 2012). مدل ویرایشگر RFC (نسخه 2) . IETF _ doi : 10.17487/RFC6635 . RFC 6635 .
  14. ^ a b دایگل، لزلی; کلکمن، اولاف (دسامبر 2009). جریان‌های RFC، سربرگ‌ها و دیگ‌های بخار . IETF _ doi : 10.17487/RFC5741 . RFC 5741 .
  15. گلن کواک (7 ژانویه 2010). "اعلام انتقال ویرایشگر RFC" . بایگانی شده از نسخه اصلی در 29 ژوئن 2011.
  16. «ویرایشگر سری RFC و سازماندهی مجدد سری» . بازبینی شده در 5 آوریل 2013 .
  17. «سؤالات متداول تغییر قالب RFC» .
  18. ^ a b " شاخص RFC " . ویرایشگر RFC 25 مه 2008 . بازیابی شده در 26 مه 2008 .
  19. «ارسالی مستقل» . ویرایشگر RFC بازیابی شده در 5 ژانویه 2018 .
  20. ^ "آیا همه RFCها استانداردهای اینترنت هستند؟" . ویرایشگر RFC بازبینی شده در 16 مارس 2018 .
  21. ^ هویتما، مسیحی ؛ پستل، جان ؛ کراکر، استیو (آوریل 1995). همه RFCها استاندارد نیستند . IETF _ doi : 10.17487/RFC1796 . RFC 1796 . ... هر RFC وضعیتی دارد...: اطلاعاتی، تجربی، یا مسیر استاندارد (استاندارد پیشنهادی، پیش نویس استاندارد، استاندارد اینترنتی)، یا تاریخی.
  22. ^ هاسلی، راسل؛ کراکر، دیو؛ برگر، اریک (اکتبر 2011). کاهش مسیر استانداردها به دو سطح سررسید . IETF _ doi : 10.17487/RFC6410 . RFC 6410 .
  23. RFC 7100 بازنشستگی «استانداردهای پروتکل رسمی اینترنت» خلاصه سند
  24. «7.5. RFCهای اطلاعاتی و تجربی» ، The Tao of IETF ، بازیابی شده در 26 نوامبر 2017
  25. برادنر، اسکات او. (اکتبر 1996). فرآیند استانداردهای اینترنت – ویرایش 3 . IETF _ BCP 9 . بازبینی شده در ۲۵ اکتبر ۲۰۱۷ .
  26. «بیانیه IESG درباره تعیین RFCها به عنوان تاریخی» . IETF. 20 جولای 2014 . بازبینی شده در 14 آوریل 2016 .
  27. استانداردهای IETF نوشته شده توسط مشارکت کنندگان ISC ، کنسرسیوم سیستم های اینترنت ، بایگانی شده از نسخه اصلی در 5 آوریل 2022 ، بازیابی شده در 11 آوریل 2022 ، بسیاری از اسناد اولیه RFC وضعیت "ناشناخته" دارند، زیرا آنها مربوط به دوران گذشته است. RFC واقعا فقط یک درخواست برای نظرات بود.
  28. «تکثیر RFCها» . IETF Trust بازبینی شده در 12 اوت 2021 .
  29. ^ برادنر، اسکات؛ کنتراس، خورخه (نوامبر 2008). مشارکت کنندگان حقوق به IETF Trust ارائه می کنند . IETF _ doi : 10.17487/RFC5378 . RFC 5378 .
  30. «تکثیر RFCها» . IETF Trust بازبینی شده در 13 اوت 2021 .

پیوندهای خارجی