File: rfc2223.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1123 lines) | stat: -rw-r--r-- 38,064 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123






Network Working Group                                          J. Postel
Request for Comments: 2223                                   J. Reynolds
Obsoletes: 1543, 1111, 825                                           ISI
Category: Informational                                     October 1997


                      Instructions to RFC Authors

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.   Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3
   3.   Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4
   3a.   ASCII Format Rules  . . . . . . . . . . . . . . . . . . . . 5
   3b.   PostScript Format Rules . . . . . . . . . . . . . . . . . . 6
   4.   Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   4a.   First Page Heading  . . . . . . . . . . . . . . . . . . . . 7
   4b.   Running Header  . . . . . . . . . . . . . . . . . . . . . . 8
   4c.   Running Footer  . . . . . . . . . . . . . . . . . . . . . . 8
   5.   Status Section . . . . . . . . . . . . . . . . . . . . . . . 8
   6.   Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 9
   7.   Introduction Section . . . . . . . . . . . . . . . . . . . . 9
   8.   References Section . . . . . . . . . . . . . . . . . . . .  11
   9.   Security Considerations Section  . . . . . . . . . . . . .  11
   10.  Author's Address Section . . . . . . . . . . . . . . . . .  11
   11.  Copyright Section  . . . . . . . . . . . . . . . . . . . .  11
   12.  Relation to other RFCs . . . . . . . . . . . . . . . . . .  12
   13.  Protocol Standards Process . . . . . . . . . . . . . . . .  13
   14.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   15.  Distribution Lists . . . . . . . . . . . . . . . . . . . .  14
   16.  RFC Index  . . . . . . . . . . . . . . . . . . . . . . . .  14
   17.  Security Considerations  . . . . . . . . . . . . . . . . .  14
   18.  References . . . . . . . . . . . . . . . . . . . . . . . .  14
   19.  Authors' Addresses . . . . . . . . . . . . . . . . . . . .  15
   20.  Appendix - RFC "nroff macros"  . . . . . . . . . . . . . .  16
   21.  Full Copyright Statement . . . . . . . . . . . . . . . . .  20





Postel & Reynolds            Informational                      [Page 1]

RFC 2223              Instructions to RFC Authors           October 1997


1.  Introduction

   This Request for Comments (RFC) provides information about the
   preparation of RFCs, and certain policies relating to the publication
   of RFCs.

   The RFC series of notes covers a broad range of interests.  The core
   topics are the Internet and the TCP/IP protocol suite.  However, any
   topic related to computer communication may be acceptable at the
   discretion of the RFC Editor.

   Memos proposed to be RFCs may be submitted by anyone.  One large
   source of memos that become RFCs is the Internet Engineering Task
   Force (IETF).  The IETF working groups (WGs) evolve their working
   memos (known as Internet Drafts or I-Ds) until they feel they are
   ready for publication, then the memos are reviewed by the Internet
   Engineering Steering Group (IESG), and if approved sent by the IESG
   to the RFC Editor.

   Most of the memos submitted to the RFC Editor from independent
   sources will be reviewed by the IESG for possible relationship to
   work in progress in the IETF Working Groups.

   RFCs are distributed online by being stored as public access files,
   and a short message is sent to the distribution list indicating the
   availability of the memo.

   The online files are copied by the interested people and printed or
   displayed at their site on their equipment.  This means that the
   format of the online files must meet the constraints of a wide
   variety of printing and display equipment.  (RFCs may also be
   returned via e-mail in response to an e-mail query, or RFCs may be
   found using information and database searching tools such as Gopher,
   Wais, or the World Wide Web (WWW).

   RFCs have been traditionally published and continue to be published
   in ASCII text.

   While the primary RFCs is always an ASCII text file, secondary or
   alternative versions of RFC may be provided in PostScript.  This
   decision is motivated by the desire to include diagrams, drawings,
   and such in RFCs.  PostScript documents (on paper only, so far) are
   visually more appealing and have better readability.

   PostScript was chosen for the fancy form of RFC publication over
   other possible systems (e.g., impress, interpress, oda) because of
   the perceived wide spread availability of PostScript capable
   printers.



Postel & Reynolds            Informational                      [Page 2]

RFC 2223              Instructions to RFC Authors           October 1997


   However, many RFC users read the documents online and use various
   text oriented tools (e.g., emacs, grep) to search them.  Often, brief
   excerpts from RFCs are included in e-mail.  These practices are not
   yet practical with PostScript files.

   PostScript producing systems are less standard than is desirable and
   that several of the document production systems that claim to produce
   PostScript actually produce nonstandard results.

   In the future, it may be necessary to identify a set of document
   production systems authorized for use in production of PostScript
   RFCs, based on the reasonableness of the output files they generate.

2.  Editorial Policy

   Documents proposed to be RFCs are reviewed by the RFC Editor and
   possibly by other reviewers he selects.

   The result of the review may be to suggest to the author some
   improvements to the document before publication.

   Occasionally, it may be apparent that the topic of a proposed RFC is
   also the subject of an IETF Working Group, and that the author could
   coordinate with the working group to the advantage of both.  The
   usual result of this is that a revised memo is produced as a working
   group Internet Draft and eventually emerges from the IETF process as
   a recommendation from the IESG to the RFC Editor.

   In some cases it may be determined that the submitted document is not
   appropriate material to be published as an RFC.

   In some cases it may be necessary to include in the document a
   statement based on the reviews about the ideas in the document.  This
   may be done in the case that the document suggests relevant but
   inappropriate or unsafe ideas, and other situations.

   The RFC Editor may make minor changes to the document, especially in
   the areas of style and format, but on some occasions also to the
   text.  Sometimes the RFC Editor will undertake to make more
   significant changes, especially when the format rules (see below) are
   not followed.  However, more often the memo will be returned to the
   author for the additional work.

   Documents intended to become RFCs specifying standards track
   protocols must be approved by the IESG before being sent to the RFC
   Editor.  The established procedure is that when the IESG completes
   work on a document that is to become a standards track RFC the
   communication will be from the Secretary of the IESG to the RFC



Postel & Reynolds            Informational                      [Page 3]

RFC 2223              Instructions to RFC Authors           October 1997


   Editor.  Generally, the documents in question are Internet Drafts.
   The communication usually cites the exact Internet Draft in question
   (by file name).  The RFC Editor must assume that only that file is to
   be processed to become the RFC.  If the authors have small
   corrections to the text, they should be sent to the RFC Editor
   separately (or as a "diff"), authors should not send a new version of
   the document.

   In some cases, authors prepare alternate secondary versions of RFCs
   in fancy format using PostScript.  Since the ASCII text version of
   the RFC is the primary version, the PostScript version must match the
   text version.  The RFC Editor must decide if the PostScript version
   is "the same as" the ASCII version before the PostScript version can
   be published.

   The effect of this is that the RFC Editor first processes the ASCII
   version of the memo through to publication as an RFC.  If the author
   wishes to submit a PostScript version at that point that matches the
   ASCII version (and the RFC Editor agrees that it does), then the
   PostScript version will be installed in the RFC repositories and
   announced to the community.

   Due to various time pressures on the RFC Editorial staff, the time
   elapsed between submission and publication can vary greatly.  It is
   always acceptable to query (ping) the RFC Editor about the status of
   an RFC during this time (but not more than once a week).  The two
   weeks preceding an IETF meeting are generally very busy, so RFCs
   submitted shortly before an IETF meeting are most likely to be
   published after the meeting.

3.  Format Rules

   To meet the distribution constraints, the following rules are
   established for the two allowed formats for RFCs:  ASCII and
   PostScript.

   The RFC Editor attempts to ensure a consistent RFC style.  To do this
   the RFC Editor may choose to reformat the RFC submitted.  It is much
   easier to do this if the submission matches the style of the most
   recent RFCs.  Please do look at some recent RFCs and prepare yours in
   the same style.

   You must submit an editable online document to the RFC Editor.  The
   RFC Editor may require or make minor changes in format or style and
   will insert the actual RFC number.






Postel & Reynolds            Informational                      [Page 4]

RFC 2223              Instructions to RFC Authors           October 1997


   Most of the RFCs are processed by the RFC Editor with the unix
   "nroff" program using a very simple set of the formatting commands
   (or "requests") from the "ms" macro package (see the Appendix).  If a
   memo submitted to be an RFC has been prepared by the author using
   nroff, it is very helpful to let the RFC Editor know that when it is
   submitted.

   3a.  ASCII Format Rules

      The character codes are ASCII.

      Each page must be limited to 58 lines followed by a form feed on a
      line by itself.

      Each line must be limited to 72 characters followed by carriage
      return and line feed.

      No overstriking (or underlining) is allowed.

      These "height" and "width" constraints include any headers,
      footers, page numbers, or left side indenting.

      Do not fill the text with extra spaces to provide a straight right
      margin.

      Do not do hyphenation of words at the right margin.

      Do not use footnotes.  If such notes are necessary, put them at
      the end of a section, or at the end of the document.

      Use single spaced text within a paragraph, and one blank line
      between paragraphs.

      Note that the number of pages in a document and the page numbers
      on which various sections fall will likely change with
      reformatting.  Thus cross references in the text by section number
      usually are easier to keep consistent than cross references by
      page number.

      RFCs in ASCII Format may be submitted to the RFC Editor in e-mail
      messages (or as online files) in either the finished publication
      format or in nroff.  If you plan to submit a document in nroff
      please consult the RFC Editor first.








Postel & Reynolds            Informational                      [Page 5]

RFC 2223              Instructions to RFC Authors           October 1997


   3b.  PostScript Format Rules

      Standard page size is 8 1/2 by 11 inches.

      Margin of 1 inch on all sides (top, bottom, left, and right).

      Main text should have a point size of no less than 10 points with
      a line spacing of 12 points.

      Footnotes and graph notations no smaller than 8 points with a line
      spacing of 9.6 points.

      Three fonts are acceptable: Helvetica, Times Roman, and Courier.
      Plus their bold-face and italic versions.  These are the three
      standard fonts on most PostScript printers.

      Prepare diagrams and images based on lowest common denominator
      PostScript.  Consider common PostScript printer functionality and
      memory requirements.

      The following PostScript commands should not be used:
      initgraphics, erasepage, copypage, grestoreall, initmatrix,
      initclip, banddevice, framedevice, nulldevice and renderbands.

      Note that the number of pages in a document and the page numbers
      on which various sections fall will likely differ in the ASCII and
      the PostScript versions.  Thus cross references in the text by
      section number usually are easier to keep consistent than cross
      references by page number.

      These PostScript rules are likely to changed and expanded as
      experience is gained.

      RFCs in PostScript Format may be submitted to the RFC Editor in
      e-mail messages (or as online files).  If you plan to submit a
      document in PostScript please consult the RFC Editor first.

      Note that since the ASCII text version of the RFC is the primary
      version, the PostScript version must match the text version.  The
      RFC Editor must decide if the PostScript version is "the same as"
      the ASCII version before the PostScript version can be published.










Postel & Reynolds            Informational                      [Page 6]

RFC 2223              Instructions to RFC Authors           October 1997


4.  Headers and Footers

   There is the first page heading, the running headers, and the running
   footers.

   4a.  First Page

      Please see the front page of this memo for an example of the front
      page heading.  On the first page there is no running header.  The
      top of the first page has the following items:

      Network Working Group

         The traditional heading for the group that founded the RFC
         series.  This appears on the first line on the left hand side
         of the heading.

      Request for Comments: nnnn

         Identifies this as a request for comments and specifies the
         number.  Indicated on the second line on the left side.  The
         actual number is filled in at the last moment before
         publication by the RFC Editor.

      Author

         The author's name (first initial and last name only) indicated
         on the first line on the right side of the heading.

      Organization

         The author's organization, indicated on the second line on the
         right side.

      Date

         This is the Month and Year of the RFC Publication. Indicated on
         the third line on the right side.

      Updates or Obsoletes

         If this RFC Updates or Obsoletes another RFC, this is indicated
         as third line on the left side of the heading.








Postel & Reynolds            Informational                      [Page 7]

RFC 2223              Instructions to RFC Authors           October 1997


      Category

         The category of this RFC, one of: Standards Track, Best Current
         Practice, Informational, or Experimental.  This is indicated on
         the third (if there is no Updates or Obsoletes indication) or
         fourth line of the left side.

      Other Numbers

         Other numbers in the RFC series of notes include the subseries
         of FYI (For Your Information) [4], BCP (Best Current Practice)
         [5], and STD (Standard) [6].  These are placed on the left
         side.

      Title

         The title appears, centered, below the rest of the heading.
         Periods or "dots" in the titles are not allowed.

      If there are multiple authors and if the multiple authors are from
      multiple organizations the right side heading may have additional
      lines to accommodate them and to associate the authors with the
      organizations properly.

   4b.  Running Headers

      The running header in one line (on page 2 and all subsequent
      pages) has the RFC number on the left (RFC NNNN), the (possibly
      nshortened form) title centered, and the date (Month Year) on the
      right.

   4c.  Running Footers

      The running footer in one line (on all pages) has the author's
      last name on the left, category centered, and the page number on
      the right ([Page N]).

5.  Status Section

   Each RFC must include on its first page the "Status of this Memo"
   section which contains two elements: (1) a paragraph describing the
   type of the RFC, and (2) the distribution statement.

   The content of this section will be one of the four following
   statements.






Postel & Reynolds            Informational                      [Page 8]

RFC 2223              Instructions to RFC Authors           October 1997


   Standards Track

      "This document specifies an Internet standards track protocol for
      the Internet community, and requests discussion and suggestions
      for improvements.  Please refer to the current edition of the
      "Internet Official Protocol Standards" (STD 1) for the
      standardization state and status of this protocol.  Distribution
      of this memo is unlimited."

   Best Current Practice

      "This document specifies an Internet Best Current Practices for
      the Internet Community, and requests discussion and suggestions
      for improvements.  Distribution of this memo is unlimited."

   Experimental

      "This memo defines an Experimental Protocol for the Internet
      community.  This memo does not specify an Internet standard of any
      kind.  Discussion and suggestions for improvement are requested.
      Distribution of this memo is unlimited."

   Informational

      "This memo provides information for the Internet community.  This
      memo does not specify an Internet standard of any kind.
      Distribution of this memo is unlimited."

6.  Copyright Notice

   Immediately following the Status section the statement, "Copyright
   (C) The Internet Society (date).  All Rights Reserved." is placed.
   Also, see Section 11 for the full statement that must appear at the
   end of the document.

7.  Introduction Section

   Each RFC should have an Introduction section that (among other
   things) explains the motivation for the RFC and (if appropriate)
   describes the applicability of the protocol described.

      Normally, this will be the "abstract" section from the Internet
      Draft.  If the RFC is not based on an I-D, other possibilities
      are:







Postel & Reynolds            Informational                      [Page 9]

RFC 2223              Instructions to RFC Authors           October 1997


         Protocol

            This protocol is intended to provide the bla-bla service,
            and be used between clients and servers on host computers.
            Typically the clients are on workstation hosts and the
            servers on mainframe hosts.

            or

            This protocol is intended to provide the bla-bla service,
            and be used between special purpose units such as terminal
            servers or routers and a monitoring host.

         Discussion

            The purpose of this RFC is to focus discussion on particular
            problems in the Internet and possible methods of solution.
            No proposed solutions in this document are intended as
            standards for the Internet.  Rather, it is hoped that a
            general consensus will emerge as to the appropriate solution
            to such problems, leading eventually to the adoption of
            standards.

         Interest

            This RFC is being distributed to members of the Internet
            community in order to solicit their reactions to the
            proposals contained in it.  While the issues discussed may
            not be directly relevant to the research problems of the
            Internet, they may be interesting to a number of researchers
            and implementers.

         Status Report

            In response to the need for maintenance of current
            information about the status and progress of various
            projects in the Internet community, this RFC is issued for
            the benefit of community members.  The information contained
            in this document is accurate as of the date of publication,
            but is subject to change.  Subsequent RFCs will reflect such
            changes.

      These paragraphs need not be followed word for word, but the
      general intent of the RFC must be made clear.







Postel & Reynolds            Informational                     [Page 10]

RFC 2223              Instructions to RFC Authors           October 1997


8.  References Section

   Nearly all RFCs contain citations to other documents, and these are
   listed in a References section near the end of the RFC.  There are
   many styles for references, and the RFCs have one of their own.
   Please follow the reference style used in recent RFCs.  See the
   reference section of this RFC for an example.  Please note that for
   protocols that have been assigned STD numbers, the STD number must be
   included in the reference.

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  BCP 14, RFC 2119 [3], defines these words as they
   should be interpreted in IETF documents.

9.  Security Considerations Section

   All RFCs must contain a section near the end of the document that
   discusses the security considerations of the protocol or procedures
   that are the main topic of the RFC.

10.  Author's Address Section

   Each RFC must have at the very end a section giving the author's
   address, including the name and postal address, the telephone number,
   (optional: a FAX number) and the Internet email address.

11.  Copyright Section

   Per BCP 9, RFC 2026 [2], "The following copyright notice and
   disclaimer shall be included in all ISOC standards-related
   documentation."  The following statement should be placed on the last
   page of the RFC, as the "Full Copyright Statement".

      "Copyright (C) The Internet Society (date).  All Rights Reserved.

      This document and translations of it may be copied and furnished
      to others, and derivative works that comment on or otherwise
      explain it or assist in its implementation may be prepared, copied,
      published and distributed, in whole or in part, without
      restriction of any kind, provided that the above copyright notice
      and this paragraph are included on all such copies and derivative
      works.  However, this document itself may not be modified in any
      way, such as by removing the copyright notice or references to the
      Internet Society or other Internet organizations, except as needed
      for the purpose of developing Internet standards in which case the
      procedures for copyrights defined in the Internet Standards
      process must be followed, or as required to translate it into



Postel & Reynolds            Informational                     [Page 11]

RFC 2223              Instructions to RFC Authors           October 1997


      languages other than English.

      The limited permissions granted above are perpetual and will not
      be revoked by the Internet Society or its successors or assigns.

      This document and the information contained herein is provided on
      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
      ENGINEERING TASK FORCE DISCLAIMS 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.

12.  Relation to other RFCs

   Sometimes an RFC adds information on a topic discussed in a previous
   RFC or completely replaces an earlier RFC.  There are two terms used
   for these cases respectively, Updates and Obsoletes.  A document that
   obsoletes an earlier document can stand on its own.  A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.

   Updates

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

   Obsoletes

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
      however extensive or brief that new information is; i.e., this
      document can be used alone, without reference to the older
      document.











Postel & Reynolds            Informational                     [Page 12]

RFC 2223              Instructions to RFC Authors           October 1997


      For example:

         On the Assigned Numbers RFCs the term Obsoletes should be used
         since the new document actually incorporate new information
         (however brief) into the text of existing information and is
         more up-to-date than the older document, and hence, replaces it
         and makes it Obsoletes.

   In lists of RFCs or the RFC-Index (but not on the RFCs themselves)
   the following may be used with early documents to point to later
   documents.

   Obsoleted-by

      To be used to refer to the newer document(s) that replaces the
      older document.

   Updated-by

      To be used to refer to the newer section(s) which are to be added
      to the existing, still used, document.

13.  Protocol Standards Process

   See the current "Internet Official Protocol Standards" (STD 1) memo
   for the definitive statement on protocol standards and their
   publication [1].

   The established procedure is that when the IESG completes work on a
   document that is to become a standards track RFC the communication
   will be from the Secretary of the IESG to the RFC Editor.  Generally,
   the documents in question are Internet Drafts.  The communication
   usually cites the exact Internet Draft (by file name) in question.
   The RFC Editor must assume that only that file is to be processed to
   become the RFC.  If the authors have small corrections to the text,
   they should be sent to the RFC Editor separately (or as a "diff"), do
   not send a new version of the document.

14.  Contact

   To contact the RFC Editor send an email message to:

         "rfc-editor@isi.edu".








Postel & Reynolds            Informational                     [Page 13]

RFC 2223              Instructions to RFC Authors           October 1997


15.  Distribution Lists

   The RFC announcements are distributed via two mailing lists: the
   "IETF-Announce" list, and the "RFC-DIST" list.  You don't want to be
   on both lists.

   To join (or quit) the IETF-Announce list send a message to ietf-
   request@ietf.org.

   To join (or quit) the RFC-DIST list send a message to rfc-dist-
   request@isi.edu.

16.  RFC Index

   Several organizations maintain RFC Index files, generally using the
   file name "rfc-index.txt".  The contents of such a file copied from
   one site may not be identical to that copied from another site.

17.  Security Considerations

   This RFC raises no security issues (however, see Section 9).

18.  References

   [1]  Postel, J., Editor, "Internet Official Protocol Standards", STD
        1, RFC 2200, June 1997.

   [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I Introduction to
        the F.Y.I. Notes", FYI 1, RFC 1150, March 1990.

   [5]  Postel, J., Li, T., and Y. Rekhter, "Best Current Practices",
        BCP 1, RFC 1818, August 1995.

   [6]  Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
        March 1992.










Postel & Reynolds            Informational                     [Page 14]

RFC 2223              Instructions to RFC Authors           October 1997


19.  Authors' Addresses

   Jon Postel
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone: +1 310-822-1511
   Fax:   +1 310-823-6714
   EMail: Postel@ISI.EDU


   Joyce K. Reynolds
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone: +1 310-822-1511
   Fax:   +1 310-823-6714
   EMail: jkrey@isi.edu































Postel & Reynolds            Informational                     [Page 15]

RFC 2223              Instructions to RFC Authors           October 1997


20.  Appendix - RFC "nroff macros"

   Generally, we use the very simplest nroff features.  We use the "ms"
   macros.  So, "nroff -ms input-file > output-file".  However, we could
   not get nroff to do the right thing about putting a form feed after
   the last visible line on a page and no extra line feeds before the
   first visible line of the next page.  We want:

        last visible line on page i
        ^L
        first visible line on page i+1

   So, we invented a hack to fix this.  We use a perl script called
   "fix.pl".  So the command to process the file becomes:

        nroff -ms input-file | fix.pl > output-file

   The actual perl script is:


#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /local/bin/perl

# fix.pl  17-Nov-93  Craig Milo Rogers at USC/ISI
#
#       The style guide for RFCs calls for pages to be delimited by the
# sequence <last-non-blank-line><formfeed-line><first-non-blank-line>.
# Unfortunately, NROFF is reluctant to produce output that conforms to
# this convention.  This script fixes RFC-style documents by searching
# for the token "FORMFEED[Page", replacing "FORMFEED" with spaces,
# appending a formfeed line, and deleting white space up to the next
# non-white space character.
#
#       There is one difference between this script's output and that of
# the "fix.sh" and "pg" programs it replaces:  this script includes a
# newline after the formfeed after the last page in a file, whereas the
# earlier programs left a bare formfeed as the last character in the
# file.  To obtain bare formfeeds, uncomment the second substitution
# command below.  To strip the final formfeed, uncomment the third
# substitution command below.
#
#       This script is intended to run as a filter, as in:
#
# nroff -ms input-file | fix.pl > output-file
#
#       When porting this script, please observe the following points:
#
# 1)    ISI keeps perl in "/local/bin/perl";  your system may keep it



Postel & Reynolds            Informational                     [Page 16]

RFC 2223              Instructions to RFC Authors           October 1997


#       elsewhere.
# 2)    On systems with a CRLF end-of-line convention, the "\n"s below
#       may have to be replaced with "\r\n"s.

$* = 1;                                 # Enable multiline patterns.
undef $/;                               # Read whole files in a single
                                        # gulp.

while (<>) {                            # Read the entire input file.
    s/FORMFEED(\[Page\s+\d+\])\s+/        \1\n\f\n/g;
                                        # Rewrite the end-of-pages.
#    s/\f\n$/\f/;                       # Want bare formfeed at end?
#    s/\f\n$//;                         # Want no formfeed at end?
    print;                              # Print the resultant file.
}
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






   This script can also be copied from: ftp://ftp.isi.edu/in-notes/rfc-
   editor/fix.pl

   Now as to the nroff features we actually use, following is a sample
   memo, prepared in RFC style.
























Postel & Reynolds            Informational                     [Page 17]

RFC 2223              Instructions to RFC Authors           October 1997


.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Waitzman
.ds RF PUTFFHERE[Page %]
.ds CF
.ds LH RFC 1149
.ds RH 1 April 1990
.ds CH IP Datagrams on Avian Carriers
.hy 0
.ad l
.in 0
Network Working Group                                        D. Waitzman
Request for Comments: 1149                                       BBN STC
                                                            1 April 1990


.ce
A Standard for the Transmission of IP Datagrams on Avian Carriers

.ti 0
Status of this Memo

.fi
.in 3
This memo describes an experimental method for the encapsulation of IP
datagrams in avian carriers.  This specification is primarily useful
in Metropolitan Area Networks.  This is an experimental, not recommended
standard.  Distribution of this memo is unlimited.

.ti 0
Overview and Rational

Avian carriers can provide high delay, low throughput, and low
altitude service.  The connection topology is limited to a single
point-to-point path for each carrier, used with standard carriers, but
many carriers can be used without significant interference with each
other, outside of early spring.  This is because of the 3D ether space
available to the carriers, in contrast to the 1D ether used by
IEEE802.3.  The carriers have an intrinsic collision avoidance system,
which increases availability.  Unlike some network technologies, such
as packet radio, communication is not limited to line-of-sight
distance.  Connection oriented service is available in some cities,
usually based upon a central hub topology.




Postel & Reynolds            Informational                     [Page 18]

RFC 2223              Instructions to RFC Authors           October 1997


.ti 0
Frame Format

The IP datagram is printed, on a small scroll of paper, in
hexadecimal, with each octet separated by whitestuff and blackstuff.
The scroll of paper is wrapped around one leg of the avian carrier.
A band of duct tape is used to secure the datagram's edges.  The
bandwidth is limited to the leg length.  The MTU is variable, and
paradoxically, generally increases with increased carrier age.  A
typical MTU is 256 milligrams.  Some datagram padding may be needed.

Upon receipt, the duct tape is removed and the paper copy of the
datagram is optically scanned into a electronically transmittable
form.

.ti 0
Discussion

Multiple types of service can be provided with a prioritized pecking
order.  An additional property is built-in worm detection and
eradication.  Because IP only guarantees best effort delivery, loss of
a carrier can be tolerated.  With time, the carriers are
self-regenerating.  While broadcasting is not specified, storms can
cause data loss.  There is persistent delivery retry, until the
carrier drops.  Audit trails are automatically generated, and can
often be found on logs and cable trays.

.ti 0
Security Considerations

.in 3
Security is not generally a problem in normal operation, but special
measures must be taken (such as data encryption) when avian carriers
are used in a tactical environment.

.ti 0
Author's Address

.nf
David Waitzman
BBN Systems and Technologies Corporation
BBN Labs Division
10 Moulton Street
Cambridge, MA 02238

Phone: (617) 873-4323

EMail: dwaitzman@BBN.COM



Postel & Reynolds            Informational                     [Page 19]

RFC 2223              Instructions to RFC Authors           October 1997


21.  Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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."
























Postel & Reynolds            Informational                     [Page 20]