Грамматизьма

[netch80]

В IETF засилье грамматистов.

"Грамматистами" я их называю потому, что они вводят текстовые протоколы со сложной грамматикой, в которой можно вложить что угодно куда угодно... но реально эта возможность используется очень слабо (да, мне так кажется - а докажите обратное;)), зато даёт сильные побочные эффекты.

Первым звонком о последствиях такой "грамматизации" был RFC822 и его реализации. RFC822, он же стандарт номер 11, построен так, что произвести адекватный разбор письма можно только применив полный грамматический разбор заголовка. Известные подходы вроде "\r\n\r\n - признак конца заголовка и начала тела", "\r\n - разделитель строк в заголовке" - недопустимые упрощения, потому что есть такое quoted string, внутри которого возможен quoted CRLF. Например (в сишном представлении внутри строки):

"To: \"X\\\r\nyyy:\" <a@b>\r\n"

По строгому соответствию здесь одно поле To: с вычурным, но допустимым mailbox, у которого phrase - один word, который quoted-string. В этом quoted-string есть допустимый quoted-pair, состоящий из обратного слэша и CR. Есть также LF, но это непринципиально.

Ни один из широко распространённых MTA или MUA это так не поймёт. Для него CRLF - первично, поэтому в письме окажется два поля заголовка - To: сломанного формата и yyy:, которое, так как не описано как structured, будет воспринято как есть, со всем своим мусором. Полную грамматику никто не парсит.

(Это не единственная хохма RFC822. Наплевательское обращение с NUL'ами почти во всех реализациях - тоже известно. Но это уже тараканы бездумного распространения и применения языка Си и его стандартных средств.)

Через 19 лет выпустили RFC2822. Много мелких правок. Исправили ли проблему квотинга CRLF, дали ли возможность обойтись без тотального парсинга? Похоже, да. По крайней мере не вижу ни одного возражения этому.

Но RFC822 - официальный стандарт (STD11), а RFC2822 - так себе, "proposed standard".

To be continued, тема весьма обширная.

Comments

[trivee.livejournal.com]

Присоединяюсь и ненавижу. Чего я лично никогда не понимал - это зачем разрешать нули и разные управляющие символы в текстовых полях. Вот есть такой тест - RFC 4475 section 3.1.1.2. У меня он не проходит, потому что там нуль в display name. То есть парсер это парсит, оно дальше при более текстовых преобразованиях теряется. И чинить я это принципиально не хочу. Слишком много усилий, а пользы никакой.

[blacklion.livejournal.com]

Полную грамматику никто не парсит.
Почему, кстати? Это же очень дёшево.

[dbg.livejournal.com]

> Но RFC822 - официальный стандарт (STD11), а RFC2822 - так себе, "proposed standard".

Что значит, "этот официальный, а тот так себе"? Они оба официальные. Это maturity level, а не степень обязательности к исполнению.

[netch]

Вот именно что степень обязательности к исполнению определяется именно тем, что объявлено standard, а что - proposed standard, best current practice и так далее. "Зрелость" же как раз выше у 2822.

[dbg.livejournal.com]

RFC 2026, 4.1 - ни слова про обязательность к исполнению. Вообще, IETF не в силах кого-то к чему-то обязать.

An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.

Тут maturity означает, как я это понимаю, широкое распространение и наличие значительного опыта, т.е. не отсутствие подлян (если б их не было, не было бы нужды выпускать обновленную спецификацию), а то, что подляны известны и хорошо поняты.

А BCP - это вообще из другого трэка.