|
|
|
|
|||||
|
|
|||||||
|
|
|||||||
|
Network Working Group Request for Comments: 4234 Obsoletes: 2234 Category: Standards Track
|
D. Crocker, Ed. Brandenburg InternetWorking
P. Overell THUS plc.
|
||||||
|
|
October 2005
|
||||||
|
|
|||||||
|
Расширенная спецификация синтаксиса Бэкуса-Наура (ABNF)
Augmented BNF for Syntax Specifications: ABNF
Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2005).
Тезисы
Технические спецификации Internet зачастую требуют использования формального синтаксиса. За долгие годы модифицированная версия формы Бэкуса-Наура (BNF1), названная (ABNF2) приобрела популярность во множестве спецификаций Internet. В данном документе содержится спецификация ABNF. Эта форма сочетает компактность и простоту с достаточно мощными средствами представления. Различия между стандартной формой BNF и ABNF включают правила именования, повторения, варианты, независимость от порядка (order-independence) и диапазоны значений. Данная спецификация также включает дополнительные определения правил и кодирования для основы лексического анализатора типов, используемого в нескольких спецификациях Internet.
|
|||||||
|
|
|||||||
|
Оглавление
|
|||||||
|
|
|||||||
|
1. Введение ................................................................................................................................................................................. .... ..................... 2
2. Определения правил ................................................................................................................................................................................ ...2....
2.1 Именование правил .......................................................................................................................................................................... ..2....
2.2. Форма правил ................................................................................................................................................................................. ....2...
2.3. Терминальные значения ................................................................................................................................................................. ...2...
2.4. Внешнее кодирование ........................................................................................................................................................ ...... ............ 3
3. Операторы ............................................................................................................................................................................. ..... .. .................. 3
3.1. Конкатенация: Rule1 Rule2 .......................................................................................................................................................... ......3. .
3.2. Варианты: Rule1 / Rule2 ............................................................................................................................................ ........................ 3
3.3. Дополнительные варианты: Rule1 =/ Rule2 .................................................................................................................................. ..3...
3.4. Диапазоны вариантов: %c##-## .............................................................................................................................. ....... ..................... 4
3.5. Упорядоченная группа: (Rule1 Rule2) .................................................................................................................................... .............................................................. ....... ..................... 4
3.5. Упорядоченная группа: (Rule1 Rule2) .................................................................................................................................... .............4
3.6. Переменное число повторов: *Rule ............................................................................................................................... ....... ............. 4
3.7. Заданное число повторов: nRule ................................................................................................................................................... ..4....
3.8. Необязательная последовательность: [RULE] ............................................................................................................ .. ................... 4
3.9. Комментарий: ; Comment ......................................................................................................................................... ......................... 4
3.10. Старшинство операторов ............................................................................................................................................................ ...5...
4. ABNF-определение для ABNF .............................................................................................................................................................. ..... 5. .
5. Вопросы безопасности ....................................................................................................................................................... ..... ...................... 5
6. Литература ............................................................................................................................................................................................. ...... 5..
6.1. Нормативные документы ............................................................................................................................................................... ...5...
6.2. Дополнительная литература ............................................................................................................................................................ 5....
Приложение A. Благодарности .......................................................................................................................................... ............................. 6
Приложение B. Основы ABNF для ABNF .................................................................................................................................. .... ................ 6
B.1. Базовые правила .................................................................................................................................................................. ..................... 6
B.2. Общие правила кодирования ......................................................................................................................................................... ..6....
|
|||||||
|
|
|||||||
|
1Backus-Naur Form 2Augmented BNF –
|
асширенная форма Бэкуса-Наура. Прим. перев.
|
||||||
|
|
|||||||
|
|
|||
|
|
Перевод RFC 4234
|
||
|
|
|||
|
1. Введение
В технических спецификациях Internet часто требуется определять формальный синтаксис и можно выбирать ту или иную нотацию, которую авторы считают полезной. За долгие годы модифицированная версия формы Бэкуса-Наура (BNF), названная (ABNF) приобрела популярность во множестве спецификаций Internet. Эта форма сочетает компактность и простоту с достаточно мощными средствами представления. В раннюю эпоху Arpanet каждая спецификация использовала свое определение ABNF. К таким определениям относится спецификация электронной почты [RFC733] и более поздний документ [RFC822], которые стали основой для последующих определений ABNF. Текущий документ разделяет эти определения для того, чтобы можно было независимо ссылаться на них. Кроме того в этом документе внесены некоторые изменения и усовершенствования.
Различия между стандартной формой BNF и ABNF включают правила именования, повторения, варианты, независимость от порядка (order-independence) и диапазоны значений. В Приложении B даются определения правил и кодирования для основы лексического анализатора типа, используемого в нескольких спецификациях Internet. Они приводятся для удобства и отделения от мета-языка, определенного в основной части данного документа, и его формального статуса.
Отличия от [RFC2234]:
В параграфе 3.7 фраза : "Т. е., в точности <N> включений <element>" была заменена фразой: "Т. е., в точности <n> включений <element>."
В некоторые продолжающиеся строки комментариев включены символы ";" в начале строк.
2. Определения правил 2.1 Именование правил
Имя правила является лишь именем как таковым, т. е., последовательностью символов, начинающейся с буквы3 или цифры, за которой следует комбинация букв, цифр и знаков дефиса4 (-).
Примечание: строчные и прописные буквы в именах правил не различаются.
Имена <rulename>, <Rulename>, <RULENAME> <rUlENamE> указывают на одно правило.
В отличие от исходной формы BNF угловые скобки (< и >) не являются обязательными. Однако в такие скобки могут заключаться имена правил, когда нужно подчеркнуть использование имени правила. Это обычно относится к именам правил, указанным в свободной форме, или для выделения имен правил включенных в строку без разделения символами пробела, как показано ниже при обсуждении повторов.
2.2. Форма правил
Правила определяются следующим способом:
name = elements crlf
где <name> - имя правила, <elements> - одно или множество имен правила или терминальных спецификаций, а <crlf> - индикатор завершения строки (возврат каретки с последующим переводом строки). Знак равенства отделяет имя от определения правила. Элементы формируют последовательность из одного или множества имен правил и/или определений значений, объединенных с помощью различных операторов, определяемых в данном документе, таких, как повторы или варианты.
Для наглядности определения правил выравнены по левому краю. Если правило не помещается на одной строке, используются знаки продолжения строки. Выравнивание по левому краю и сдвиг от края определяются первой строкой правила ABNF, чтобы правила можно было легко отличить от остального текста документа.
2.3. Терминальные значения
Правила преобразуются в строки терминальных значений, иногда называемых символами. В ABNF символ – это просто неотрицательное целое число. В некоторых случаях задается специфическое отображение (кодирование) значений в набор символов (такой, как ASCII).
Терминалы задаются одной или множеством цифр с явно заданным основанием. В настоящее время определены следующие варианты оснований чисел:
b = binary (двоичное)
d = decimal (десятичное)
x = hexadecimal (шестнадцатеричное)
Следовательно, записи:
CR = %d13 CR = %x0D
задают, соответственно, десятичное и шестнадцатеричное представление символа возврата каретки [US-ASCII].
Связанные (concatenated) строки таких значений задаются в компактной форме с использованием символа точки (.) в качестве разделителя. Следовательно,
CRLF = %d13.10
ABNF разрешает указывать текстовые строки5 непосредственно, помещая текст в двойные кавычки.
command = "command string"
Текстовые строки интерпретируются как связанное множество печатных символов.
Примечание: регистр букв текстовых строках ABNF не принимается во внимание, а в качестве набора символов используется US-ASCII.
|
|||
|
|
|||
|
3Здесь и далее в тексте документа термин “буква” означает буквы латинского алфавита. Прим. перев. 4В английском языке hyphen или dash. Прим. перев. 5Literal text string
|
|||
|
|
|||
|
|
|||
|
Перевод RFC 4234
|
|
||
|
|
|||
|
Следовательно,
rulename = "abc"
и
rulename = "aBc"
будут соответствовать "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC" и "ABC".
Для задания правила, в котором регистр символов принимается во внимание символы следует задавать по-отдельности. Например,
rulename = %d97 %d98 %d99
или
rulename = %d97.98.99
будут соответствовать только строкам, содержащим лишь строчные буквы abc.
2.4. Внешнее кодирование
Внешнее представление символов терминальных значений будет меняться в соответствии с условиями среды хранения и передачи. Следовательно, одна и та же грамматическая конструкция ABNF может иметь различное внешнее кодирование (например, одно представление для 7-битовой среды US-ASCII, другое для двоичной среды на базе октетов6, третье для 16-битовой среды Unicode). Детали кодирования выходят за пределы ABNF, хотя в Приложении В7 (Основы) приводятся определения для 7-битовой среды US-ASCII, как наиболее распространенной в Internet.
Разделение внешнего кодирования и синтаксиса предназначено для того, чтобы могли использоваться дополнительные среды кодирования для одного и того же синтаксиса.
3. Операторы
3.1. Конкатенация8: Rule1 Rule2
Правило может определять простую, упорядоченную строку значений (например, конкатенация последовательных символов) путем перечисления последовательности имен правил. Например,
foo = %x61 ; a
bar = %x62 ; b
mumble = foo bar foo
В результате правило <mumble> будет соответствовать строке строчных букв "aba".
Пробельные символы (linear white space): Конкатенация является основой модели разбора (parsing) ABNF. Строка непрерывных (contiguous) символов (значений) разбирается согласно правилам, определенным в ABNF. Для спецификаций Internet в силу исторических причин допускается свободное “рассеяние” символов пробела и горизонтальной табуляции вокруг основных конструкций (таких, как специальные разделители9 или строки-атомы10).
Примечание:
В данной спецификации ABNF не предполагается неявно такого “рассеяния” пробельных символов (linear white space).
Любая грамматическая конструкция, которая разрешает “рассеяние” пробельных символов вокруг разделителей и сегментов строк, должна указывать это явно. Зачастую бывает полезно обеспечить такое пустое пространство в основных (core) правилах, которые используются среди правил вышележащих уровней11. “Основные” правила могут формироваться в лексический анализатор или просто быть частью главного набора правил.
3.2. Варианты12: Rule1 / Rule2
Элементы, разделенные символом дробной черты13 (/), задают варианты. Следовательно,
foo / bar
будет принимать <foo> или <bar>.
Примечание:
Заключенные в двойные кавычки строки букв представляют собой специальную форму задания дополнительных символов и интерпретируются как нетерминальное представление набора комбинаторных строк с содержащимися в них символами в указанном порядке, но с любыми комбинациями строчных и прописных букв.
3.3. Дополнительные варианты14: Rule1 =/ Rule2
Иногда удобно задавать список вариантов в виде фрагментов. Т. е., начальному правилу соответствует один или множество вариантов, а последующие определения правил добавляют набор вариантов. Это особенно полезно для создания иной независимой спецификации, которая является производной от того же родительского набора правил, как это часто бывает со списками параметров. ABNF поддерживает такие дополнения с помощью конструкции:
oldrule =/ additional-alternatives
|
|||
|
|
|||
|
6binary octet environment
7В оригинале ошибочно указано Приложение A. Прим. перев.
8Слияние. Прим. перев.
9delimiter
10atomic string
11higher-level rule
12Alternatives
13forward slash
14Incremental Alternatives
|
|||
|
|
|||
|
|
|||
|
|
Перевод RFC 4234
|
||
|
|
|||
|
Таким образом набор правил
ruleset = alt1 / alt2 ruleset =/ alt3 ruleset =/ alt4 / alt5
представляет собой то же самое, что и
ruleset = alt1 / alt2 / alt3 / alt4 / alt5
3.4. Диапазоны вариантов15: %c##-##
Диапазон вариантов цифровых значений может быть представлен в компактной форме с использованием символа дефиса (-) для индикации диапазона вариантов. Следовательно,
DIGIT = %x30-39
является эквивалентом:
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
Конкатенация цифровых значений и диапазон цифровых значений не могут быть заданы в одной строке. Цифровое значение может использовать нотацию с точками для конкатенации16 или нотацию с дефисом17 для задания одного диапазона значений. Следовательно, для задания одного печатного символа между последовательностями завершения строк, можно указать:
char-line = %x0D.0A %x20-7E %x0D.0A
3.5. Упорядоченная группа18: (Rule1 Rule2)
Элементы, заключенные в круглые скобки, трактуются как один элемент со строгим упорядочением. Таким образом,
elem (foo / bar) blat
соответствует (elem foo blat) или (elem bar blat), а
elem foo / bar blat
соответствует (elem foo) или (bar blat).
Примечание:
Настоятельно рекомендуется использовать группы взамен вариантов, состоящих из множества имен правил или литералов. Следовательно, рекомендуется использовать приведенную ниже форму:
(elem foo) / (bar blat)
Это позволит предотвратить ошибочную интерпретацию при невнимательном чтении.
Упорядоченные группы используются также внутри свободного текста для выделения порядка слов в тексте.
3.6. Переменное число повторов19: *Rule
Оператор *, предшествующий элементу, указывает на повторение. Полная форма имеет вид:
<a>*<b>element
где <a> и <b> - необязательные десятичные значения, показывающие минимальное (<a>) и максимальное (<b>) число повторов элемента.
По умолчанию для верхнего и нижнего порога используются значения 0 и “бесконечность”, поэтому *<element> позволяет любое число элементов (включая 0), 1*<element> требует по крайней мере один элемент, 3*3<element> разрешает в точности три повтора, а 1*2<element> разрешает 1 или 2 повтора.
3.7. Заданное число повторов20: nRule
Правило вида:
<n>element
эквивалентно правилу
<n>*<n>element
Т. е., допускается в точности <n> включений <element>. Таким образом 2DIGIT представляет собой двухзначное число, а 3ALPHA – строку из трех букв.
3.8. Необязательная последовательность21: [RULE]
В квадратных скобках указывается необязательная последовательность элементов.
[foo bar]
эквивалентно
*1(foo bar).
3.9. Комментарий: ; Comment
Точка с запятой (;) служит началом комментария, который продолжается до конца строки. Это обеспечивает простой способ включения в спецификацию полезных примечаний.
|
|||
|
|
|||
|
15Value Range Alternatives 16dotted notation 17dash notation 18Sequence Group 19Variable Repetition 20Specific Repetition 21Optional Sequence
|
|||
|
|
|||
|
|
|||
|
Перевод RFC 4234
|
|
||
|
|
|||
|
22Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.
|
|||
|
|
|||
|
|
|||
|
|
Перевод RFC 4234
|
||
|
|
|||
|
Приложение A. Благодарности
Изначальная спецификация синтаксиса ABNF была приведена в RFC 733. Ken L. Harrenstien из SRI International выполнил работу по кодированию для расширенного BNF, позволившему сделать представление более компактным и ясным.
Этот недавний проект проект начался как простая работа по выделению части документа RFC 822, которая неоднократно использовалась в спецификациях, не связанных с электронной почтой, и являлась описанием расширенного варианта BNF. Вместо простого копирования имеющегося текста в отдельный документ рабочая группа предпочла внимательное рассмотрение преимуществ и недостатков существующей спецификации и других спецификаций, выпущенных за последние 15 лет. Это сделало проект более амбициозным, нежели предполагалось в начале. Интересно отметить, что полученный результат не слишком значительно отличается от оригинала, хотя некоторые решения (типа удаления списков - list notation) стали сюрпризом.
Эта “отдельная” версия спецификации была частью работы группы DRUMS, значительный вклад в которую внесли Jerome Abela, Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete Resnick и Henning Schulzrinne.
Julian Reschke заслуживает отдельной благодарности за преобразование чернового варианта (Draft Standard version) в формат XML.
Приложение B. Основы ABNF для ABNF
Это приложение включено как удобная основа для грамматических конструкций. Приведенные здесь определения можно использовать как базовый набор правил.
B.1. Базовые правила
Для некоторых базовых правил (таких, как SP, HTAB, CRLF, DIGIT, ALPHA и т. п.) используются заглавные буквы.
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z BIT = "0" / "1"
CHAR = %x01-7F
; любой 7-битовый символ US-ASCII, за исключением NUL CR = %x0D
; возврат каретки
CRLF = CR LF
; стандартная в Internet последовательность для новой строки CTL = %x00-1F / %x7F
; коды управления DIGIT = %x30-39
; цифры 0-9 DQUOTE = %x22
; " (двойные кавычки) HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HTAB = %x09
; символ горизонтальной табуляции LF = %x0A
; перевод строки LWSP = *(WSP / CRLF WSP)
; linear white space (после новой строки) OCTET = %x00-FF
; 8 битов данных SP = %x20
VCHAR = %x21-7E
; видимые (печатные) символы WSP = SP / HTAB
; пробельные символы
B.2. Общие правила кодирования
Для внешнего представления данных используется 7-битовая кодировка US-ASCII с нулевым значением старшего бита23. Строки значений используют “сетевой порядок байтов24,” при котором старший (наиболее значимый байт) указывается слева и передается через сеть первым.
|
|||
|
|
|||
|
Адреса авторов Dave Crocker (editor)
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086
US
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
|
|||
|
|
|||
|
23network virtual ASCII 24network byte order
|
|||
|
|
|||
|
|
||||
|
Перевод RFC 4234
|
|
|||
|
|
||||
|
Paul Overell
THUS plc.
1/2 Berkeley Square
99 Berkeley Street
Glasgow
G3 7HR
UK
EMail: paul.overell@thus.net
|
||||
|
|
||||
|
Перевод на русский язык Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Интеллектуальная собственность
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
|
||||
|
|
||||
|
7
|
||||