RFC об

[netch]

Поскольку rfc этот писан прекраснодушными обормотами, жившими в башне из слоновой кости, в этой области на него таки следует положить.
(из письма в ru.unix)

Вот тем и отличается RFC от нормального стандартизационного процесса, что стандарты (даже если они называются рекомендациями) пересматриваются и правятся. И устранить явную ошибку - там дело одной версии, а не полного изменения текста.

P.S. Я уже имел обширный спор об этом в fido7. Не надо, например, мне предлагать идти в IETF менять всю систему.

Comments

[blacklion.livejournal.com]

А как же `Updated by'/`Obsoleted by'? Что мешает поправить ошибку и перевыпустить с такими полями, чем это отличается от новой редакции стандарта?

[netch]

Разница в том, что
1) психологически правка существующего - событие меньшее, чем выпуск
нового. Поэтому против выпуска нового RFC с нефундаментальными
правками возражений всегда больше, чем против обновлённой версии
стандарта.
2) в источниках, как своих, так и чужих, закрепляются номера. Если
сказано "RFC793" и при этом присутствуют RFC793-1981 (начальный) и
RFC793-1987 (обновлённый) - всё равно ссылка будет на 793,
конкретная версия будет упоминаться только в случаях типа "XXX
соответствует версии 1981, хотя выпущен в 2000; почему не версии
1987?" Связи же между разными номерами типа "obsoleted by" требуют
явной проверки на устарелость.

[mt6561.livejournal.com]

Этот процесс нуждается прежде всего в документировании, а не в изменении.

Ибо прежде чем тебя начинают слушать, тебе надо стать своим в той тусовке, узнать общепринятые (но от того ничуть не формализованно-документированные) правила и так далее...

[netch]

> Этот процесс нуждается прежде всего в документировании, а не в изменении.

Он отлично документирован. Мне не нравится одна его сторона, в принципе небольшая, но по описанным здесь причинам очень существенная для остального мира.

> Ибо прежде чем тебя начинают слушать, тебе надо стать своим в той тусовке, узнать общепринятые (но от того ничуть не формализованно-документированные) правила и так далее...

Не пойдёт - я Замахиваюсь На Святое.:))

[ospf-ripe.livejournal.com]

В том, что RFC не изменяются, а только выпускаются новые есть свои плюсы (как и минусы).

Если спецификации продукта написано, что он поддерживает RFC-NNN то скорее всего он будет совместим с другим продуктом который реализует этот RFC. Если же взять два продукта которые реализуют стандарт ХХХ разных версий, то не факт, что они будут на 100% совместимыми.

Впрочем это я думаю не столь принципиальный вопрос, а скорее вопрос привычки.

А содержание стандарта больше зависть от людей которые их пишут. С версиями или без это уже второстепенно. И не надо забывать, что перед выпуском RFC выпускается несколько черновиков.

Какие то RFC писались практиками, а какие то теоретиками несколько далекими от реальностей жизни. Но даже плохой стандарт лучше чем его отсутствие.

И насколько я знаю в отличие от других организаций в IETF довольно открытый процесс обсуждения черновиков RFC (drafts) и высказать свое мнение может почти любой заинтересованный человек.

[netch]

> Если спецификации продукта написано, что он поддерживает RFC-NNN то скорее всего он будет совместим с другим продуктом который реализует этот RFC. Если же взять два продукта которые реализуют стандарт ХХХ разных версий, то не факт, что они будут на 100% совместимыми.

А теперь если сравнить с ситуацией когда один продукт поддерживает например RFC822 (не полностью - я не знаю НИ ОДНОГО который бы его полностью поддерживал), а второй - RFC2822 (в столь же урезанном наборе, однако) - кто кого заборет, кит слона или слон кита, и как будет с их совместимостью?

А ведь если бы RFC822 привели в норму устранив наиболее одиозные неудобства и кривости - и не потребовалось бы выдумывать новый столь же кривой стандарт...

> И насколько я знаю в отличие от других организаций в IETF довольно открытый процесс обсуждения черновиков RFC (drafts) и высказать свое мнение может почти любой заинтересованный человек.

А что это даст в данном случае?

[ospf-ripe.livejournal.com]

А ведь если бы RFC822 привели в норму устранив наиболее одиозные неудобства и кривости - и не потребовалось бы выдумывать новый столь же кривой стандарт...

С таким же успехом можно было выпустить нормальный RFC2822, без всякой ерунды, которая там есть.

> И насколько я знаю в отличие от других организаций в IETF довольно открытый процесс обсуждения черновиков RFC (drafts) и высказать свое мнение может почти любой заинтересованный человек.

А что это даст в данном случае?

Когда обсуждался чрновик 2822 можно было (теоретически) попробовать убедить их не включать в 2822 то, что все равно никто не станет реализовывать в полном проблеме.

Взять хотя бы синтаксис адресов. Если из него выкинуть quoted-string жить было бы легче...