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

[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, а не степень обязательности к исполнению.