Кто определяет правила Интернета (если не RFC) и где они?

Насколько мне известно, все, что касается Интернета, определено (или, скорее, должно быть?) определено и задокументировано в RFC. Я нашел список нескольких HTTP-заголовков на сайте mozilla.org (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers), которые, как я предположил, были заимствованы из RFC. Однако большинство HTTP-заголовков, связанных с безопасностью, отсутствуют ни в RFC (источник: https://www.rfc-editor.org/search/rfc_search_detail.php?title=Content-Security-Policy), ни в заголовках HTTP, предложенных IANA (источник: https://www.iana.org/assignments/message-headers/message-headers.xhtml)

  1. Есть ли комитет, который принимает решения по таким соглашениям, и центральное место, где я всегда могу найти информацию из первых рук о правилах Интернета?
  2. Как программисты критически важных приложений узнают, какие функции они должны реализовать, чтобы поддерживать свое программное обеспечение в актуальном состоянии с остальной частью Интернета?
  3. Как программисты могут быть уверены, что их программное обеспечение реализовано в полном соответствии с правилами и работает в гармонии с остальной частью Интернета. Например. кто-то, кто программирует FTP-клиент (предполагая, что он не использует библиотеки), должен убедиться, что его понимание FTP-протокола такое же, как и у каждого отдельного приложения FTP-сервера, верно?

http-headers rfc iana
person Max    schedule 30.12.2020    source источник
comment
Questions which are too broad, unclear, incomplete or primarily opinion-based могут быть закрыты сообществом до тех пор, пока они не будут улучшены.   -  person amarinediary    schedule 31.12.2020
comment
Один поток на вопрос — это обычная лучшая практика в Stackoverflow.   -  person amarinediary    schedule 31.12.2020
comment
Почему этот вопрос слишком общий, неясный, неполный или в первую очередь основанный на мнении?   -  person Max    schedule 31.12.2020

Ответы (1)


arrow_upward
1
arrow_downward

RFC являются окончательно утвержденной документацией. В вашем случае HTTP находится в рабочей группе HTTP, поэтому в этой группе обсуждаются некоторые новые функции, которые уже поддерживаются некоторыми браузерами. Расширяя идею, некоторые заголовки безопасности, присутствующие в HTTP, могут быть из других групп и просто упоминаться в RCF HTTP. Политика безопасности контента описана в RFC 7762, но не помечена как информационная.

  1. Каждая область имеет свои рабочие группы, в данном случае HTTP вложен в ART (область приложений и реального времени). Каждая из этих групп составляет, пересматривает и публикует новые спецификации. В качестве примера вы можете увидеть HTTP(httpbis) чартер

  2. Есть два варианта: реализовать на основе RCF и его ссылок или следовать директивам и ссылкам рабочей группы. Использование только RFC более безопасно и совместимо, но в конечном итоге устареет, пока не будет опубликован новый RFC.

  3. Единственный способ — реализовать то, что задокументировано в RFC. Это часть интернет-концепции, новые функции или стандарты потребуют времени, чтобы быть полностью задокументированными, и это зависит от разработчиков, исследующих и реализующих их.

person Hebert Luiz    schedule 31.12.2020
comment
HTTP не является безопасным, именно TLS может защитить HTTP, и для TLS существуют RFC. ОП просто не знает, что искать. - person Ron Maupin; 31.12.2020
comment
Нет, я не знал, ГДЕ искать. На все, что я хотел знать, ответил выше - так что, видимо, Герберт решил, что мой вопрос был обоснованным. Спасибо! Шифрование HTTP на самом деле не было частью моего первоначального вопроса. - person Max; 31.12.2020