Context Navigation

source: draft-ietf-httpbis/orig/rfc5234.xml @ 598

Last change on this file since 598 was 598, checked in by julian.reschke@…, 14 years ago
fix Makefile, add RFC 2817/2818, re-gen HTML
Property svn:eol-style set to `native` Property svn:executable set to ``*
File size: 32.3 KB

Line
1	<?xml version="1.0" encoding="US-ASCII"?>
2
3	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
4
5	<?rfc rfcedstyle="yes" ?>
6
7	<?rfc comments="no"?>
8	<?rfc inline="yes"?>
9
10	<?rfc subcompact="no" ?>
11	<?rfc toc="yes" ?>
12	<?rfc tocdepth="2" ?>
13	<?rfc tocindent="yes" ?>
14	<?rfc symrefs="yes" ?>
15	<?rfc sortrefs="yes"?>
16	<?rfc iprnotified="no" ?>
17
18
19	<rfc category="std" number="5234" obsoletes="4234" seriesNo="68" xmlns:grddl='http://www.w3.org/2003/g/data-view#' grddl:transformation='rfc2629grddl.xslt'>
20	<front>
21	<title abbrev="ABNF">Augmented BNF for Syntax Specifications: ABNF</title>
22	<author fullname="Dave Crocker" initials="D." role="editor"
23	surname="Crocker">
24	<organization>Brandenburg InternetWorking</organization>
25	<address>
26	<postal>
27	<street>675 Spruce Dr.</street>
28	<city>Sunnyvale</city>
29	<region>CA</region>
30	<code>94086</code>
31	<country>US</country>
32	</postal>
33	<phone>+1.408.246.8253</phone>
34	<email>dcrocker@bbiw.net</email>
35	</address>
36	</author>
37	<author fullname="Paul Overell" initials="P." surname="Overell">
38	<organization>THUS plc.</organization>
39	<address>
40	<postal>
41	<street>1/2 Berkeley Square, </street>
42	<street>99 Berkeley Street</street>
43	<city>Glasgow</city>
44	<code>G3 7HR</code>
45	<country>UK</country>
46	</postal>
47	<email>paul.overell@thus.net</email>
48	</address>
49	</author>
50	<date month="January" year="2008" />
51	<keyword>ABNF</keyword>
52	<keyword>Augmented</keyword>
53	<keyword>Backus-Naur</keyword>
54	<keyword>Form</keyword>
55	<keyword>electronic</keyword>
56	<keyword>mail</keyword>
57	<abstract>
58	<t>Internet technical specifications often need to define a formal
59	syntax. Over the years, a modified version of Backus-Naur Form
60	(BNF), called Augmented BNF (ABNF), has been popular among many
61	Internet specifications. The current specification documents ABNF.
62	It balances compactness and simplicity with reasonable
63	representational power. The differences between standard BNF and
64	ABNF involve naming rules, repetition, alternatives, order-
65	independence, and value ranges. This specification also supplies
66	additional rule definitions and encoding for a core lexical
67	analyzer of the type common to several Internet specifications.
68	</t>
69	</abstract>
70	</front>
71	<middle>
72	<section title="Introduction">
73	<t> Internet technical specifications often need to define a formal
74	syntax and are free to employ whatever notation their authors deem
75	useful. Over the years, a modified version of Backus-Naur Form
76	(BNF), called Augmented BNF (ABNF), has been popular among many
77	Internet specifications. It balances compactness and simplicity
78	with reasonable representational power. In the early days of the
79	Arpanet, each specification contained its own definition of ABNF.
80	This included the email specifications, <xref target="RFC733" />
81	and then <xref target="RFC822" />, which came to be the common
82	citations for defining ABNF. The current document separates those
83	definitions to permit selective reference. Predictably, it also
84	provides some modifications and enhancements.</t>
85	<t> The differences between standard BNF and ABNF involve naming
86	rules, repetition, alternatives, order-independence, and value
87	ranges. <xref target="CORE" /> supplies rule definitions and
88	encoding for a core lexical analyzer of the type common to several
89	Internet specifications. It is provided as a convenience and is
90	otherwise separate from the meta language defined in the body of
91	this document, and separate from its formal status.</t>
92	</section>
93	<section title="Rule Definition">
94	<section title="Rule Naming">
95	<t> The name of a rule is simply the name itself, that is, a
96	sequence of characters, beginning with an alphabetic character,
97	and followed by a combination of alphabetics, digits, and
98	hyphens (dashes).</t>
99	<t>
100	<list style="hanging">
101	<t hangText="NOTE: " />
102	<t>Rule names are case insensitive.</t>
103	</list>
104	</t>
105	<t> The names <rulename>, <Rulename>,
106	<RULENAME>, and <rUlENamE> all
107	refer to the same rule.</t>
108	<t> Unlike original BNF, angle brackets ("<", ">")
109	are not required. However, angle brackets may be used around a
110	rule name whenever their presence facilitates in discerning the
111	use of a rule name. This is typically restricted to rule name
112	references in free-form prose, or to distinguish partial rules
113	that combine into a string not separated by white space, such
114	as shown in the discussion about repetition, below.</t>
115	</section>
116	<section title="Rule Form">
117	<t> A rule is defined by the following sequence:</t>
118	<figure>
119	<artwork><![CDATA[
120	name = elements crlf ]]></artwork>
121	</figure>
122	<t> where <name> is the name of the rule,
123	<elements> is one or more rule names or terminal
124	specifications, and <crlf> is the end-of-line
125	indicator (carriage return followed by line feed). The equal
126	sign separates the name from the definition of the rule. The
127	elements form a sequence of one or more rule names and/or value
128	definitions, combined according to the various operators
129	defined in this document, such as alternative and repetition.</t>
130	<t> For visual ease, rule definitions are left aligned. When a
131	rule requires multiple lines, the continuation lines are
132	indented. The left alignment and indentation are relative to
133	the first lines of the ABNF rules and need not match the left
134	margin of the document.</t>
135	</section>
136	<section title="Terminal Values">
137	<t> Rules resolve into a string of terminal values, sometimes
138	called characters. In ABNF, a character is merely a
139	non-negative integer. In certain contexts, a specific mapping
140	(encoding) of values into a character set (such as ASCII) will
141	be specified.</t>
142	<figure>
143	<preamble> Terminals are specified by one or more numeric
144	characters, with the base interpretation of those characters
145	indicated explicitly. The following bases are currently
146	defined:</preamble>
147	<artwork><![CDATA[
148	b = binary
149
150	d = decimal
151
152	x = hexadecimal ]]></artwork>
153	</figure>
154	<figure>
155	<preamble> Hence:</preamble>
156	<artwork><![CDATA[
157	CR = %d13
158
159	CR = %x0D
160	]]></artwork>
161	<postamble> respectively specify the decimal and hexadecimal
162	representation of <xref target="US-ASCII" /> for carriage
163	return.</postamble>
164	</figure>
165	<?rfc needLines="10" ?>
166	<figure>
167	<preamble> A concatenated string of such values is specified
168	compactly, using a period (".") to indicate a separation of
169	characters within that value. Hence:</preamble>
170	<artwork><![CDATA[
171	CRLF = %d13.10 ]]></artwork>
172	</figure>
173	<figure>
174	<preamble> ABNF permits the specification of literal text
175	strings directly, enclosed in quotation marks. Hence:</preamble>
176	<artwork><![CDATA[
177	command = "command string" ]]></artwork>
178	</figure>
179	<t> Literal text strings are interpreted as a concatenated set of
180	printable characters.</t>
181	<t>
182	<list style="hanging">
183	<t hangText="NOTE: " />
184	<t>ABNF strings are case insensitive and the character set
185	for these strings is US-ASCII. </t>
186	</list>
187	</t>
188	<figure>
189	<preamble> Hence:</preamble>
190	<artwork><![CDATA[
191	rulename = "abc" ]]></artwork>
192	</figure>
193	<figure>
194	<preamble> and:</preamble>
195	<artwork><![CDATA[
196	rulename = "aBc"
197	]]></artwork>
198	<postamble> will match "abc", "Abc", "aBc", "abC", "ABc",
199	"aBC", "AbC", and "ABC".</postamble>
200	</figure>
201	<t>
202	<list>
203	<t> To specify a rule that is case sensitive, specify the
204	characters individually. </t>
205	</list>
206	</t>
207	<figure>
208	<preamble> For example:</preamble>
209	<artwork><![CDATA[
210	rulename = %d97 %d98 %d99
211	]]></artwork>
212	</figure>
213	<figure>
214	<preamble> or</preamble>
215	<artwork><![CDATA[
216	rulename = %d97.98.99
217	]]></artwork>
218	<postamble> will match only the string that comprises only the
219	lowercase characters, abc.</postamble>
220	</figure>
221	</section>
222	<?rfc needLines="10" ?>
223	<section title="External Encodings">
224	<t> External representations of terminal value characters will
225	vary according to constraints in the storage or transmission
226	environment. Hence, the same ABNF-based grammar may have
227	multiple external encodings, such as one for a 7-bit US-ASCII
228	environment, another for a binary octet environment, and still
229	a different one when 16-bit Unicode is used. Encoding details
230	are beyond the scope of ABNF, although <xref target="CORE" />
231	provides definitions for a 7-bit US-ASCII environment as has
232	been common to much of the Internet.</t>
233	<t> By separating external encoding from the syntax, it is
234	intended that alternate encoding environments can be used for
235	the same syntax.</t>
236	</section>
237	</section>
238	<section title="Operators">
239	<section title="Concatenation: Rule1 Rule2">
240	<t> A rule can define a simple, ordered string of values (i.e., a
241	concatenation of contiguous characters) by listing a sequence
242	of rule names. For example:</t>
243	<figure>
244	<artwork><![CDATA[
245	foo = %x61 ; a
246
247	bar = %x62 ; b
248
249	mumble = foo bar foo ]]></artwork>
250	</figure>
251	<t> So that the rule <mumble> matches the lowercase
252	string "aba". </t>
253	<t> Linear white space: Concatenation is at the core of the ABNF
254	parsing model. A string of contiguous characters (values) is
255	parsed according to the rules defined in ABNF. For Internet
256	specifications, there is some history of permitting linear
257	white space (space and horizontal tab) to be freely and
258	implicitly interspersed around major constructs, such as
259	delimiting special characters or atomic strings. </t>
260	<t>NOTE: <list>
261	<t> This specification for ABNF does not provide for
262	implicit specification of linear white space.</t>
263	</list>
264	</t>
265	<t> Any grammar that wishes to permit linear white space around
266	delimiters or string segments must specify it explicitly. It is
267	often useful to provide for such white space in "core" rules
268	that are then used variously among higher-level rules. The
269	"core" rules might be formed into a lexical analyzer or simply
270	be part of the main ruleset.</t>
271	</section>
272
273	<section anchor="Alternatives" title="Alternatives: Rule1 / Rule2">
274	<t> Elements separated by a forward slash ("/") are alternatives.
275	Therefore,</t>
276	<figure>
277	<artwork><![CDATA[
278	foo / bar
279	]]></artwork>
280	<postamble> will accept <foo> or
281	<bar>.</postamble>
282	</figure>
283	<t>
284	<list style="hanging">
285	<t hangText="NOTE: " />
286	<t>A quoted string containing alphabetic characters is a
287	special form for specifying alternative characters and is
288	interpreted as a non-terminal representing the set of
289	combinatorial strings with the contained characters, in
290	the specified order but with any mixture of upper- and
291	lowercase.</t>
292	</list>
293	</t>
294	</section>
295
296	<section anchor="Incremental"
297	title="Incremental Alternatives: Rule1 =/ Rule2">
298	<t> It is sometimes convenient to specify a list of alternatives
299	in fragments. That is, an initial rule may match one or more
300	alternatives, with later rule definitions adding to the set of
301	alternatives. This is particularly useful for otherwise
302	independent specifications that derive from the same parent
303	ruleset, such as often occurs with parameter lists. ABNF
304	permits this incremental definition through the construct:</t>
305	<figure>
306	<artwork><![CDATA[
307	oldrule =/ additional-alternatives ]]></artwork>
308	</figure>
309	<figure>
310	<preamble> So that the ruleset</preamble>
311	<artwork><![CDATA[
312	ruleset = alt1 / alt2
313
314	ruleset =/ alt3
315
316	ruleset =/ alt4 / alt5 ]]></artwork>
317	</figure>
318	<figure>
319	<preamble> is the same as specifying</preamble>
320	<artwork><![CDATA[
321	ruleset = alt1 / alt2 / alt3 / alt4 / alt5 ]]></artwork>
322	</figure>
323	</section>
324	<?rfc needLines="15" ?>
325	<section anchor="Range" title="Value Range Alternatives: %c##-##">
326	<figure>
327	<preamble> A range of alternative numeric values can be
328	specified compactly, using a dash ("-") to indicate the
329	range of alternative values. Hence:</preamble>
330	<artwork><![CDATA[
331	DIGIT = %x30-39 ]]></artwork>
332	</figure>
333	<figure>
334	<preamble> is equivalent to:</preamble>
335	<artwork><![CDATA[
336	DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
337
338	"7" / "8" / "9" ]]></artwork>
339	</figure>
340	<figure>
341	<preamble> Concatenated numeric values and numeric value ranges
342	cannot be specified in the same string. A numeric value may
343	use the dotted notation for concatenation or it may use the
344	dash notation to specify one value range. Hence, to specify
345	one printable character between end-of-line sequences, the
346	specification could be:</preamble>
347	<artwork><![CDATA[
348	char-line = %x0D.0A %x20-7E %x0D.0A ]]></artwork>
349	</figure>
350	</section>
351
352	<section anchor="Sequence" title="Sequence Group: (Rule1 Rule2)">
353	<figure>
354	<preamble> Elements enclosed in parentheses are treated as a
355	single element, whose contents are strictly ordered. Thus,</preamble>
356	<artwork><![CDATA[
357	elem (foo / bar) blat
358	]]></artwork>
359	<postamble>matches (elem foo blat) or (elem bar blat),
360	and</postamble>
361	</figure>
362	<figure>
363	<artwork><![CDATA[
364	elem foo / bar blat
365	]]></artwork>
366	<postamble> matches (elem foo) or (bar blat).</postamble>
367	</figure>
368	<t>
369	<list style="hanging">
370	<t hangText="NOTE: " />
371	<t>It is strongly advised that grouping notation be used,
372	rather than relying on the proper reading of "bare"
373	alternations, when alternatives consist of multiple rule
374	names or literals. </t>
375	</list>
376	</t>
377	<figure>
378	<preamble> Hence, it is recommended that the following form be
379	used:</preamble>
380	<artwork><![CDATA[
381	(elem foo) / (bar blat)
382	]]></artwork>
383	<postamble>It will avoid misinterpretation by casual
384	readers.</postamble>
385	</figure>
386	<?rfc needLines="10" ?>
387	<t> The sequence group notation is also used within free text to
388	set off an element sequence from the prose.</t>
389	</section>
390
391	<section anchor="VarRep" title="Variable Repetition: *Rule">
392	<figure>
393	<preamble> The operator "*" preceding an element indicates
394	repetition. The full form is:</preamble>
395	<artwork><![CDATA[
396	<a>*<b>element
397	]]></artwork>
398	<postamble> where <a> and <b> are
399	optional decimal values, indicating at least
400	<a> and at most <b> occurrences
401	of the element.</postamble>
402	</figure>
403	<t> Default values are 0 and infinity so that
404	*<element> allows any number, including zero;
405	1*<element> requires at least one;
406	3*3<element> allows exactly 3; and
407	1*2<element> allows one or two.</t>
408	</section>
409
410	<section anchor="SpecRep" title="Specific Repetition: nRule">
411	<figure>
412	<preamble> A rule of the form:</preamble>
413	<artwork><![CDATA[
414	<n>element ]]></artwork>
415	</figure>
416	<figure>
417	<preamble> is equivalent to</preamble>
418	<artwork><![CDATA[
419	<n>*<n>element ]]></artwork>
420	</figure>
421	<t> That is, exactly <n> occurrences of
422	<element>. Thus, 2DIGIT is a 2-digit number, and
423	3ALPHA is a string of three alphabetic characters.</t>
424	</section>
425
426	<section anchor="OptSeq" title="Optional Sequence: [RULE]">
427	<figure>
428	<preamble> Square brackets enclose an optional element
429	sequence:</preamble>
430	<artwork><![CDATA[
431	[foo bar] ]]></artwork>
432	</figure>
433	<figure>
434	<preamble> is equivalent to</preamble>
435	<artwork><![CDATA[
436	*1(foo bar). ]]></artwork>
437	</figure>
438	</section>
439
440	<section anchor="Comment" title="Comment: ; Comment">
441	<t> A semicolon starts a comment that continues to the end of
442	line. This is a simple way of including useful notes in
443	parallel with the specifications.</t>
444	</section>
445
446	<section title="Operator Precedence">
447	<t> The various mechanisms described above have the following
448	precedence, from highest (binding tightest) at the top, to
449	lowest (loosest) at the bottom: <list>
450	<t>Rule name, prose-val, Terminal value</t>
451	<t>Comment</t>
452	<t>Value range</t>
453	<t>Repetition</t>
454	<t>Grouping, Optional</t>
455	<t>Concatenation</t>
456	<t>Alternative</t>
457	</list>
458	</t>
459	<t> Use of the alternative operator, freely mixed with
460	concatenations, can be confusing.</t>
461	<t>
462	<list>
463	<t> Again, it is recommended that the grouping operator be
464	used to make explicit concatenation groups. </t>
465	</list>
466	</t>
467	</section>
468	</section>
469
470	<section title="ABNF Definition of ABNF">
471	<t>
472	<list style="hanging">
473	<t hangText="NOTES:">
474	<list style="numbers">
475	<t>This syntax requires a formatting of rules that is
476	relatively strict. Hence, the version of a ruleset
477	included in a specification might need preprocessing
478	to ensure that it can be interpreted by an ABNF
479	parser.</t>
480	<t>This syntax uses the rules provided in <xref
481	target="CORE" />.</t>
482	</list>
483	</t>
484	</list>
485	</t>
486	<figure>
487	<artwork type="abnf"><![CDATA[
488	rulelist = 1( rule / (c-wsp c-nl) )
489
490	rule = rulename defined-as elements c-nl
491	; continues if next line starts
492	; with white space
493
494	rulename = ALPHA *(ALPHA / DIGIT / "-")
495
496	defined-as = c-wsp ("=" / "=/") c-wsp
497	; basic rules definition and
498	; incremental alternatives
499
500	elements = alternation *c-wsp
501
502	c-wsp = WSP / (c-nl WSP)
503
504	c-nl = comment / CRLF
505	; comment or newline
506
507	comment = ";" *(WSP / VCHAR) CRLF
508
509	alternation = concatenation
510	(c-wsp "/" *c-wsp concatenation)
511
512	concatenation = repetition (1c-wsp repetition)
513
514	repetition = [repeat] element
515
516	repeat = 1DIGIT / (DIGIT "" DIGIT)
517
518	element = rulename / group / option /
519	char-val / num-val / prose-val
520
521	group = "(" c-wsp alternation c-wsp ")"
522
523	option = "[" c-wsp alternation c-wsp "]"
524
525	char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE
526	; quoted string of SP and VCHAR
527	; without DQUOTE
528
529	num-val = "%" (bin-val / dec-val / hex-val)
530
531	bin-val = "b" 1*BIT
532	[ 1("." 1BIT) / ("-" 1*BIT) ]
533	; series of concatenated bit values
534	; or single ONEOF range
535
536	dec-val = "d" 1*DIGIT
537	[ 1("." 1DIGIT) / ("-" 1*DIGIT) ]
538
539	hex-val = "x" 1*HEXDIG
540	[ 1("." 1HEXDIG) / ("-" 1*HEXDIG) ]
541
542
543
544
545	prose-val = "<" *(%x20-3D / %x3F-7E) ">"
546	; bracketed string of SP and VCHAR
547	; without angles
548	; prose description, to be used as
549	; last resort ]]></artwork>
550	</figure>
551	</section>
552	<section title="Security Considerations">
553	<t> Security is truly believed to be irrelevant to this document.</t>
554	</section>
555	</middle>
556	<back>
557	<references title="Normative References">
558	<reference anchor="US-ASCII">
559	<front>
560	<title>Coded Character Set -- 7-bit American Standard Code for
561	Information Interchange</title>
562	<author>
563	<organization>American National Standards
564	Institute</organization>
565	</author>
566	<date year="1986" />
567	</front>
568	<seriesInfo name="ANSI" value="X3.4" />
569	</reference>
570	</references>
571	<references title="Informative References">
572	<reference anchor="RFC733">
573	<front>
574	<title>Standard for the format of ARPA network text messages</title>
575	<author fullname="David H. Crocker" initials="D."
576	surname="Crocker">
577	<organization>The Rand Corporation, Information Sciences
578	Department</organization>
579	<address>
580	<postal>
581	<street>1700 Main St</street>
582	<city>Santa Monica</city>
583	<region>CA</region>
584	<code>90406</code>
585	<country>US</country>
586	</postal>
587	<email>DCrocker@Rand-Unix</email>
588	</address>
589	</author>
590	<author fullname="John J. Vittal" initials="J."
591	surname="Vittal">
592	<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
593	<address>
594	<postal>
595	<street>50 Moulton St.</street>
596	<city>Cambridge</city>
597	<region>MA</region>
598	<code>02138</code>
599	<country>US</country>
600	</postal>
601	<email>Vittal@BBN-TenexD</email>
602	</address>
603	</author>
604	<author fullname="Kenneth T. Pogran" initials="K."
605	surname="Pogran">
606	<organization>Massachusets Institute of Technology (MIT),
607	Laboratory for Computer Science</organization>
608	<address>
609	<postal>
610	<street>545 Technology Square</street>
611	<city>Cambridge</city>
612	<region>MA</region>
613	<code>02139</code>
614	<country>US</country>
615	</postal>
616	<email>Pogran@MIT-Multics</email>
617	</address>
618	</author>
619	<author fullname="D. Austin Henderson, Jr." initials="D."
620	surname="Henderson">
621	<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
622	<address>
623	<postal>
624	<street>50 Moulton St.</street>
625	<city>Cambridge</city>
626	<region>MA</region>
627	<code>02138</code>
628	<country>US</country>
629	</postal>
630	<email>Henderson@BBN-TenexD</email>
631	</address>
632	</author>
633	<date day="21" month="November" year="1977" />
634	</front>
635	<seriesInfo name="RFC" value="733" />
636	</reference>
637	<reference anchor="RFC822">
638	<front>
639	<title abbrev="Standard for ARPA Internet Text Messages"
640	>Standard for the format of ARPA Internet text messages</title>
641	<author fullname="David H. Crocker" initials="D.H."
642	surname="Crocker">
643	<organization>University of Delaware, Dept. of Electrical
644	Engineering</organization>
645	<address>
646	<postal>
647	<street />
648	<city>Newark</city>
649	<region>DE</region>
650	<code>19711</code>
651	<country>US</country>
652	</postal>
653	<email>DCrocker@UDel-Relay</email>
654	</address>
655	</author>
656	<date day="13" month="August" year="1982" />
657	</front>
658	<seriesInfo name="STD" value="11" />
659	<seriesInfo name="RFC" value="822" />
660	</reference>
661
662
663
664	</references>
665	<?rfc needLines="20" ?>
666	<section title="Acknowledgements">
667	<t> The syntax for ABNF was originally specified in RFC 733. Ken L.
668	Harrenstien, of SRI International, was responsible for re-coding
669	the BNF into an Augmented BNF that makes the representation
670	smaller and easier to understand.</t>
671	<t> This recent project began as a simple effort to cull out the
672	portion of RFC 822 that has been repeatedly cited by non-email
673	specification writers, namely the description of Augmented BNF.
674	Rather than simply and blindly converting the existing text into a
675	separate document, the working group chose to give careful
676	consideration to the deficiencies, as well as benefits, of the
677	existing specification and related specifications made available
678	over the last 15 years, and therefore to pursue enhancement. This
679	turned the project into something rather more ambitious than was
680	first intended. Interestingly, the result is not massively
681	different from that original, although decisions, such as removing
682	the list notation, came as a surprise.</t>
683	<t> This "separated" version of the specification was part of the
684	DRUMS working group, with significant contributions from Jerome
685	Abela, Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett,
686	Tom Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman,
687	Pete Resnick, and Henning Schulzrinne.</t>
688	<t>Julian Reschke warrants a special thanks for converting the Draft
689	Standard version to XML source form.</t>
690	</section>
691
692	<section anchor="CORE" title="Core ABNF of ABNF">
693
694	<t>This appendix contains some basic rules that are in common use.
695	Basic rules are in uppercase. Note that these rules are only valid
696	for ABNF encoded in 7-bit ASCII or in characters sets that are a
697	superset of 7-bit ASCII.</t>
698
699	<section title="Core Rules">
700	<t> Certain basic rules are in uppercase, such as SP, HTAB, CRLF,
701	DIGIT, ALPHA, etc.</t>
702	<figure>
703	<artwork type="abnf"><![CDATA[
704	ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
705
706	BIT = "0" / "1"
707
708	CHAR = %x01-7F
709	; any 7-bit US-ASCII character,
710	; excluding NUL
711
712	CR = %x0D
713	; carriage return
714
715	CRLF = CR LF
716	; Internet standard newline
717
718	CTL = %x00-1F / %x7F
719	; controls
720
721	DIGIT = %x30-39
722	; 0-9
723
724	DQUOTE = %x22
725	; " (Double Quote)
726
727	HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
728
729	HTAB = %x09
730	; horizontal tab
731
732	LF = %x0A
733	; linefeed
734
735	LWSP = *(WSP / CRLF WSP)
736	; Use of this linear-white-space rule
737	; permits lines containing only white
738	; space that are no longer legal in
739	; mail headers and have caused
740	; interoperability problems in other
741	; contexts.
742	; Do not use when defining mail
743	; headers and use with caution in
744	; other contexts.
745
746	OCTET = %x00-FF
747	; 8 bits of data
748
749	SP = %x20
750
751	VCHAR = %x21-7E
752	; visible (printing) characters
753
754	WSP = SP / HTAB
755	; white space ]]></artwork>
756	</figure>
757	</section>
758
759	<section title="Common Encoding">
760	<t> Externally, data are represented as "network virtual ASCII"
761	(namely, 7-bit US-ASCII in an 8-bit field), with the high (8th)
762	bit set to zero. A string of values is in "network byte order",
763	in which the higher-valued bytes are represented on the
764	left-hand side and are sent over the network first.</t>
765	</section>
766	</section>
767
768
769
770	</back>
771	</rfc>

Note: See TracBrowser for help on using the repository browser.

Download in other formats: