RFC: 1459
Оригинал: Internet Relay Chat Protocol
Категория: Экспериментальный
Дата публикации:
Авторы: ,
Перевод: Рустам Шихалиев aka russo

2.3.1. Формат сообщения в «псевдо» BNF

Протокол сообщений должен быть извлечен из смежных потоков октетов Текущим решением стало определение двух символов, CR и LS, как разделители сообщений. Игнорирование пустых сообщений, которые используют последовательности CR-LF между сообщениями без каких-либо проблем.

Распакованное сообщение проверяется внутри компонентов <prefix>, <command> и список параметров подравнивается с помощью <middle> или <trailing> компонентами.

BNF представляет собой нечто подобное:

<message>  ::= [':' <prefix> <SPACE> ] <command> <params> <crlf>
<prefix>   ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ]
<command>  ::= <letter> { <letter> } | <number> <number> <number>
<SPACE>    ::= ' ' { ' ' }
<params>   ::= <SPACE> [ ':' <trailing> | <middle> <params> ]

<middle>   ::= <Любая *не пустая* последовательность октетов, не
            включающая в себя пробел, или NUL, или CR, или LF;
        первой не может быть ':'>
<trailing> ::= <Любая, возможно *пустая*, последовательность октетов, не
            включающих в себя NUL или CR, или LF>

<crlf>     ::= CR LF

Замечания:

  1. <SPACE> содержит только символ(ы) пробела (0x20). Табуляция и другие контрольные символы рассматриваются как НЕ-ПУСТЫЕ-ПРОБЕЛЫ (NON-WHITE-SPACE).
  2. После извлечения списка параметров, все параметры равняются с помощью <middle> или <trailing>. <trailing> просто синтаксическая штуковина, включающая SPACE внутри параметра.
  3. Факт, что CR и LF нельзя добавить в строки параметров, просто артефакт оформления сообщения. Его можно изменить позже.
  4. NUL не является специальным символом в оформлении сообщения и в основе служит окончанием внутри параметра, но это является причиной усложнения в нормальной C-строке. Так же, NUL не позволителен внутри сообщений.
  5. Последний параметр может быть пустой строкой.
  6. Использование расширенного префикса (['!' <user> ] ['@' <host> ]) может быть в связи сервера с сервером и предполагается только для сообщений между сервером и клиентом, предоставляя клиентам больше полезной информации о пользователях без использования дополнительных запросов.
2007 - 2017 © Русские переводы RFC, IETF, ISOC.