Context Navigation

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

Last change on this file since 573 was 311, checked in by julian.reschke@…, 14 years ago
Update orig RFCs, also add 2145 and 5234
Property svn:executable set to ``*
File size: 33.1 KB

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

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

Download in other formats: