-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-iab-rfcv3-preptool-latest.html
836 lines (789 loc) · 61 KB
/
draft-iab-rfcv3-preptool-latest.html
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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>RFC v3 Prep Tool Description</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.2" rel="Chapter" title="2 v3 Prep Tool Usage Scenarios"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Internet-Draft Submission"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Canonical RFC Preparation"/>
<link href="#rfc.section.5" rel="Chapter" title="5 What the v3 Prep Tool Does"/>
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 XML Sanitization"/>
<link href="#rfc.section.5.1.1" rel="Chapter" title="5.1.1 XInclude Processing"/>
<link href="#rfc.section.5.1.2" rel="Chapter" title="5.1.2 DTD Removal"/>
<link href="#rfc.section.5.1.3" rel="Chapter" title="5.1.3 Processing Instruction Removal"/>
<link href="#rfc.section.5.1.4" rel="Chapter" title="5.1.4 Validity Check"/>
<link href="#rfc.section.5.1.5" rel="Chapter" title="5.1.5 Check “anchor”"/>
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Defaults"/>
<link href="#rfc.section.5.2.1" rel="Chapter" title="5.2.1 “version” Insertion"/>
<link href="#rfc.section.5.2.2" rel="Chapter" title="5.2.2 “seriesInfo” Insertion"/>
<link href="#rfc.section.5.2.3" rel="Chapter" title="5.2.3 <date> Insertion"/>
<link href="#rfc.section.5.2.4" rel="Chapter" title="5.2.4 “prepTime” Insertion"/>
<link href="#rfc.section.5.2.5" rel="Chapter" title="5.2.5 <ol> Group “start” Insertion"/>
<link href="#rfc.section.5.2.6" rel="Chapter" title="5.2.6 Attribute Default Value Insertion"/>
<link href="#rfc.section.5.2.7" rel="Chapter" title="5.2.7 Section “toc” attribute"/>
<link href="#rfc.section.5.2.8" rel="Chapter" title="5.2.8 “removeInRFC” Warning Paragraph"/>
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Normalization"/>
<link href="#rfc.section.5.3.1" rel="Chapter" title="5.3.1 “month” Attribute"/>
<link href="#rfc.section.5.3.2" rel="Chapter" title="5.3.2 ASCII Attribute Processing"/>
<link href="#rfc.section.5.3.3" rel="Chapter" title="5.3.3 “title” Conversion"/>
<link href="#rfc.section.5.4" rel="Chapter" title="5.4 Generation"/>
<link href="#rfc.section.5.4.1" rel="Chapter" title="5.4.1 “expiresDate” Insertion"/>
<link href="#rfc.section.5.4.2" rel="Chapter" title="5.4.2 <boilerplate> Insertion"/>
<link href="#rfc.section.5.4.2.1" rel="Chapter" title="5.4.2.1 Compare <rfc> “submissionType” and <seriesInfo> “stream”"/>
<link href="#rfc.section.5.4.2.2" rel="Chapter" title="5.4.2.2 ‘Status of this Memo’ Insertion"/>
<link href="#rfc.section.5.4.2.3" rel="Chapter" title="5.4.2.3 Copyright Insertion"/>
<link href="#rfc.section.5.4.3" rel="Chapter" title="5.4.3 <reference> “target” Insertion"/>
<link href="#rfc.section.5.4.4" rel="Chapter" title="5.4.4 <name> Slugification"/>
<link href="#rfc.section.5.4.5" rel="Chapter" title="5.4.5 <reference> Sorting"/>
<link href="#rfc.section.5.4.6" rel="Chapter" title="5.4.6 “pn” Numbering"/>
<link href="#rfc.section.5.4.7" rel="Chapter" title="5.4.7 <iref> Numbering"/>
<link href="#rfc.section.5.4.8" rel="Chapter" title="5.4.8 <xref> processing"/>
<link href="#rfc.section.5.4.8.1" rel="Chapter" title="5.4.8.1 “derivedContent” Insertion (With Content)"/>
<link href="#rfc.section.5.4.8.2" rel="Chapter" title="5.4.8.2 “derivedContent” Insertion (Without Content)"/>
<link href="#rfc.section.5.4.9" rel="Chapter" title="5.4.9 <relref> Processing"/>
<link href="#rfc.section.5.5" rel="Chapter" title="5.5 Inclusion"/>
<link href="#rfc.section.5.5.1" rel="Chapter" title="5.5.1 <artwork> Processing"/>
<link href="#rfc.section.5.5.2" rel="Chapter" title="5.5.2 <sourcecode> Processing"/>
<link href="#rfc.section.5.6" rel="Chapter" title="5.6 RFC Production Mode Cleanup"/>
<link href="#rfc.section.5.6.1" rel="Chapter" title="5.6.1 <note> Removal"/>
<link href="#rfc.section.5.6.2" rel="Chapter" title="5.6.2 <cref> Removal"/>
<link href="#rfc.section.5.6.3" rel="Chapter" title="5.6.3 <link> Processing"/>
<link href="#rfc.section.5.6.4" rel="Chapter" title="5.6.4 XML Comment Removal"/>
<link href="#rfc.section.5.6.5" rel="Chapter" title="5.6.5 “xml:base” and “originalSrc” Removal"/>
<link href="#rfc.section.5.6.6" rel="Chapter" title="5.6.6 Compliance Check"/>
<link href="#rfc.section.5.7" rel="Chapter" title="5.7 Finalization"/>
<link href="#rfc.section.5.7.1" rel="Chapter" title="5.7.1 “scripts” Insertion"/>
<link href="#rfc.section.5.7.2" rel="Chapter" title="5.7.2 Pretty-Format"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Additional Uses for the Prep Tool"/>
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Security Considerations"/>
<link href="#rfc.section.9" rel="Chapter" title="9 Acknowledgements"/>
<link href="#rfc.references" rel="Chapter" title="10 Informative References"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.5.1 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Hoffman, P. and J. Hildebrand" />
<meta name="dct.identifier" content="urn:ietf:id:draft-iab-rfcv3-preptool-03" />
<meta name="dct.issued" scheme="ISO8601" content="2016-7-18" />
<meta name="dct.abstract" content="This document describes some aspects of the “prep tool” that is expected to be created when the new RFC v3 specification is deployed." />
<meta name="description" content="This document describes some aspects of the “prep tool” that is expected to be created when the new RFC v3 specification is deployed." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">P. Hoffman</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">ICANN</td>
</tr>
<tr>
<td class="left">Intended status: Informational</td>
<td class="right">J. Hildebrand</td>
</tr>
<tr>
<td class="left">Expires: January 19, 2017</td>
<td class="right">Cisco</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">July 18, 2016</td>
</tr>
</tbody>
</table>
<p class="title">RFC v3 Prep Tool Description<br />
<span class="filename">draft-iab-rfcv3-preptool-03</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>This document describes some aspects of the “prep tool” that is expected to be created when the new RFC v3 specification is deployed.</p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on January 19, 2017.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<li>2. <a href="#rfc.section.2">v3 Prep Tool Usage Scenarios</a></li>
<li>3. <a href="#rfc.section.3">Internet-Draft Submission</a></li>
<li>4. <a href="#rfc.section.4">Canonical RFC Preparation</a></li>
<li>5. <a href="#rfc.section.5">What the v3 Prep Tool Does</a></li>
<ul><li>5.1. <a href="#rfc.section.5.1">XML Sanitization</a></li>
<ul><li>5.1.1. <a href="#rfc.section.5.1.1">XInclude Processing</a></li>
<li>5.1.2. <a href="#rfc.section.5.1.2">DTD Removal</a></li>
<li>5.1.3. <a href="#rfc.section.5.1.3">Processing Instruction Removal</a></li>
<li>5.1.4. <a href="#rfc.section.5.1.4">Validity Check</a></li>
<li>5.1.5. <a href="#rfc.section.5.1.5">Check “anchor”</a></li>
</ul><li>5.2. <a href="#rfc.section.5.2">Defaults</a></li>
<ul><li>5.2.1. <a href="#rfc.section.5.2.1">“version” Insertion</a></li>
<li>5.2.2. <a href="#rfc.section.5.2.2">“seriesInfo” Insertion</a></li>
<li>5.2.3. <a href="#rfc.section.5.2.3"><date> Insertion</a></li>
<li>5.2.4. <a href="#rfc.section.5.2.4">“prepTime” Insertion</a></li>
<li>5.2.5. <a href="#rfc.section.5.2.5"><ol> Group “start” Insertion</a></li>
<li>5.2.6. <a href="#rfc.section.5.2.6">Attribute Default Value Insertion</a></li>
<li>5.2.7. <a href="#rfc.section.5.2.7">Section “toc” attribute</a></li>
<li>5.2.8. <a href="#rfc.section.5.2.8">“removeInRFC” Warning Paragraph</a></li>
</ul><li>5.3. <a href="#rfc.section.5.3">Normalization</a></li>
<ul><li>5.3.1. <a href="#rfc.section.5.3.1">“month” Attribute</a></li>
<li>5.3.2. <a href="#rfc.section.5.3.2">ASCII Attribute Processing</a></li>
<li>5.3.3. <a href="#rfc.section.5.3.3">“title” Conversion</a></li>
</ul><li>5.4. <a href="#rfc.section.5.4">Generation</a></li>
<ul><li>5.4.1. <a href="#rfc.section.5.4.1">“expiresDate” Insertion</a></li>
<li>5.4.2. <a href="#rfc.section.5.4.2"><boilerplate> Insertion</a></li>
<ul><li>5.4.2.1. <a href="#rfc.section.5.4.2.1">Compare <rfc> “submissionType” and <seriesInfo> “stream”</a></li>
<li>5.4.2.2. <a href="#rfc.section.5.4.2.2">‘Status of this Memo’ Insertion</a></li>
<li>5.4.2.3. <a href="#rfc.section.5.4.2.3">Copyright Insertion</a></li>
</ul><li>5.4.3. <a href="#rfc.section.5.4.3"><reference> “target” Insertion</a></li>
<li>5.4.4. <a href="#rfc.section.5.4.4"><name> Slugification</a></li>
<li>5.4.5. <a href="#rfc.section.5.4.5"><reference> Sorting</a></li>
<li>5.4.6. <a href="#rfc.section.5.4.6">“pn” Numbering</a></li>
<li>5.4.7. <a href="#rfc.section.5.4.7"><iref> Numbering</a></li>
<li>5.4.8. <a href="#rfc.section.5.4.8"><xref> processing</a></li>
<ul><li>5.4.8.1. <a href="#rfc.section.5.4.8.1">“derivedContent” Insertion (With Content)</a></li>
<li>5.4.8.2. <a href="#rfc.section.5.4.8.2">“derivedContent” Insertion (Without Content)</a></li>
</ul><li>5.4.9. <a href="#rfc.section.5.4.9"><relref> Processing</a></li>
</ul><li>5.5. <a href="#rfc.section.5.5">Inclusion</a></li>
<ul><li>5.5.1. <a href="#rfc.section.5.5.1"><artwork> Processing</a></li>
<li>5.5.2. <a href="#rfc.section.5.5.2"><sourcecode> Processing</a></li>
</ul><li>5.6. <a href="#rfc.section.5.6">RFC Production Mode Cleanup</a></li>
<ul><li>5.6.1. <a href="#rfc.section.5.6.1"><note> Removal</a></li>
<li>5.6.2. <a href="#rfc.section.5.6.2"><cref> Removal</a></li>
<li>5.6.3. <a href="#rfc.section.5.6.3"><link> Processing</a></li>
<li>5.6.4. <a href="#rfc.section.5.6.4">XML Comment Removal</a></li>
<li>5.6.5. <a href="#rfc.section.5.6.5">“xml:base” and “originalSrc” Removal</a></li>
<li>5.6.6. <a href="#rfc.section.5.6.6">Compliance Check</a></li>
</ul><li>5.7. <a href="#rfc.section.5.7">Finalization</a></li>
<ul><li>5.7.1. <a href="#rfc.section.5.7.1">“scripts” Insertion</a></li>
<li>5.7.2. <a href="#rfc.section.5.7.2">Pretty-Format</a></li>
</ul></ul><li>6. <a href="#rfc.section.6">Additional Uses for the Prep Tool</a></li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a></li>
<li>8. <a href="#rfc.section.8">Security Considerations</a></li>
<li>9. <a href="#rfc.section.9">Acknowledgements</a></li>
<li>10. <a href="#rfc.references">Informative References</a></li>
<li><a href="#rfc.authors">Authors' Addresses</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">For the future of the RFC format, the RFC Editor has decided that XML (using the XML2RFCv3 vocabulary <a href="#I-D.iab-xml2rfc">[I-D.iab-xml2rfc]</a>) is the canonical format, in the sense that it is the data that is the authorized, recognized, accepted, and archived version of the document. See <a href="#RFC6949">[RFC6949]</a> for more detail on this.</p>
<p id="rfc.section.1.p.2">Most people will read other formats, such as HTML, PDF, ASCII text, or other formats of the future, however. In order to ensure each of these formats is as similar as possible to one another as well as the canonical XML, there is a desire that the translation from XML into the other formats will be straightforward syntactic translation. To make that happen, a good amount of data will need to be in the XML format that is not there today. That data will be added by a program called the “prep tool”, which will often run as a part of the xml2rfc process.</p>
<p id="rfc.section.1.p.3">This draft specifies the steps that the prep tool will have to take. As changes to <a href="#I-D.iab-xml2rfc">[I-D.iab-xml2rfc]</a> are made, this document will be updated.</p>
<p id="rfc.section.1.p.4">The details (particularly any vocabularies) described in this document are expected to change based on experience gained in implementing the RFC Production Center’s (RPC) toolset. Revised documents will be published capturing those changes as the toolset is completed. Other implementers must not expect those changes to remain backwards-compatible with the details described in this document.</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#v3-prep-tool-usage-scenarios" id="v3-prep-tool-usage-scenarios">v3 Prep Tool Usage Scenarios</a></h1>
<p id="rfc.section.2.p.1">The prep tool will have several settings:</p>
<p/>
<ul>
<li>Internet-Draft preparation</li>
<li>Canonical RFC preparation</li>
</ul>
<p id="rfc.section.2.p.3">There are only a few differences between the two settings. For example, the boilerplate output will be different, as will the date output on the front page.</p>
<p id="rfc.section.2.p.4">Note that this only describes what the IETF-sponsored prep tool does. Others might create their own work-alike prep tools for their own formatting needs. However, an output format developer does not need to change the prep tool in order to create their own formatter: they only need to be able to consume prepared text. The IETF-sponsored prep tool runs in two different modes: “I-D” mode when the tool is run during Internet-Draft submission and processing, and “RFC production mode” when the tool is run by the RFC Production Center while producing an RFC.</p>
<p id="rfc.section.2.p.5">This tool is described as if it is a separate tool so that we can reason about its architectural properties. In actual implementation, it might be a part of a larger suite of functionality.</p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#internet-draft-submission" id="internet-draft-submission">Internet-Draft Submission</a></h1>
<p id="rfc.section.3.p.1">When the IETF draft submission tool accepts v3 XML as an input format, the submission tool runs the submitted file through the prep tool. This is called “I-D mode” in this document. If the tool finds no errors, it keeps two XML files: the submitted file and the prepped file.</p>
<p id="rfc.section.3.p.2">The prepped file provides a record of what a submitter was attesting to at the time of submission. It represents a self-contained record of what any external references resolved to at the time of submission.</p>
<p id="rfc.section.3.p.3">The prepped file is used by the IETF formatters to create outputs such as HTML, PDF, and text (or the tools act in a way indistinguishable from this). The message sent out by the draft submission tool includes a link to the original XML as well as the other outputs, including the prepped XML.</p>
<p id="rfc.section.3.p.4">The prepped XML can be used by tools not yet developed to output new formats that have as similar output as possible to the current IETF formatters. For example, if the IETF creates a .mobi output renderer later, it can run that renderer on all of the prepped XML that has been saved, ensuring that the content of included external references and all of the part numbers and boilerplate will be the same as what was produced by the previous IETF formatters at the time the document was first uploaded.</p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#canonical-rfc-preparation" id="canonical-rfc-preparation">Canonical RFC Preparation</a></h1>
<p id="rfc.section.4.p.1">During AUTH48, the RPC will run the prep tool in canonical RFC production mode and make the results available to the authors so they can see what the final output might look like. When the document has passed AUTH48 review, the RPC runs the prep tool in canonical RFC production mode one last time, locks down the canonicalized XML, runs the formatters for the publication formats, and publishes all of those.</p>
<p id="rfc.section.4.p.2">This document assumes that the prep tool will be used in the following manner by the RPC; they may use something different, or with different configuration.</p>
<p id="rfc.section.4.p.3">Similarly to I-D’s, the prepped XML can be used later to re-render the output formats, or to generate new formats.</p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#steps" id="steps">What the v3 Prep Tool Does</a></h1>
<p id="rfc.section.5.p.1">The steps listed here are in order of processing. In all cases where the prep tool would “add” an attribute or element, if that attribute or element already exists, the prep tool will check that the attribute or element has valid values. If the value is incorrect, the prep tool will warn with the old and new values, then replace the incorrect value with the new value.</p>
<p id="rfc.section.5.p.2">Currently, the IETF uses a tool called “idnits” to check text input to the Internet-Drafts publishing process. idnits indicates if it encountered any errors, and also provide text with all of the warnings and errors in a human-readable form. The prep tool should probably check for as many of these errors and warnings as possible when it is processing the XML input. For the moment, tooling might run idnts on the text output from the prepared XML. The list below contains some of those errors and warnings, but the deployed version of the prep tool may contain additional steps to include more or the checks from idnits.</p>
<h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> <a href="#sanitization" id="sanitization">XML Sanitization</a></h1>
<p id="rfc.section.5.1.p.1">These steps will ensure that the input document is properly formatted, and that all XML processing has been performed.</p>
<h1 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1.</a> <a href="#xinclude-processing" id="xinclude-processing">XInclude Processing</a></h1>
<p id="rfc.section.5.1.1.p.1">Process all <x:include> elements. Note: <x:include>d XML may include more <x:include>s (with relative references resolved against the base URI potentially modified by a previously inserted xml:base attribute). The tool may be configurable with a limit on the depth of recursion.</p>
<h1 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2.</a> <a href="#dtd-removal" id="dtd-removal">DTD Removal</a></h1>
<p id="rfc.section.5.1.2.p.1">Fully process any Document Type Definitions (DTDs) in the input document, then remove the DTD. At a minimum, this entails processing the entity references and includes for external files.</p>
<h1 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3.</a> <a href="#pi-removal" id="pi-removal">Processing Instruction Removal</a></h1>
<p id="rfc.section.5.1.3.p.1">Remove processing instructions.</p>
<h1 id="rfc.section.5.1.4"><a href="#rfc.section.5.1.4">5.1.4.</a> <a href="#validity-check" id="validity-check">Validity Check</a></h1>
<p id="rfc.section.5.1.4.p.1">Check the input against the RNG in <a href="#I-D.iab-xml2rfc">[I-D.iab-xml2rfc]</a>. If the input is not valid, give an error.</p>
<h1 id="rfc.section.5.1.5"><a href="#rfc.section.5.1.5">5.1.5.</a> <a href="#check-anchor" id="check-anchor">Check “anchor”</a></h1>
<p id="rfc.section.5.1.5.p.1">Check all elements for “anchor” attributes. If any “anchor” attribute begins with “s-“, “f-“, “t-“, or “i-“, give an error.</p>
<h1 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a> <a href="#defaults" id="defaults">Defaults</a></h1>
<p id="rfc.section.5.2.p.1">These steps will ensure that all default values have been filled in to the XML, in case the defaults change at a later date. Steps in this section will not overwrite existing values in the input file.</p>
<h1 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1.</a> <a href="#version-insertion" id="version-insertion">“version” Insertion</a></h1>
<p id="rfc.section.5.2.1.p.1">If the <rfc> element has a “version” attribute with a value other than “3”, give an error. If the <rfc> element has no “version” attribute, add one with the value “3”.</p>
<h1 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2.</a> <a href="#seriesinfo-insertion" id="seriesinfo-insertion">“seriesInfo” Insertion</a></h1>
<p id="rfc.section.5.2.2.p.1">If the <front> element of the <rfc> element does not already have a <seriesInfo> element, add a <seriesInfo> element with the name attribute based on the mode in which the preptool is running (“Internet-Draft” for Draft mode and “RFC” for RFC production mode) and a value that is the input filename minus any extension for Internet-Drafts, and is a number specified by the RFC Editor for RFCs.</p>
<h1 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3.</a> <a href="#date-insertion" id="date-insertion"><date> Insertion</a></h1>
<p id="rfc.section.5.2.3.p.1">If the <front> element in the <rfc> element does not contain a <date> element, add it and fill in the “day”, “month”, and “year” attibutes from the current date. If the <front> element in the <rfc> element has a <date> element with “day”, “month”, and “year” attibutes, but the date indicated is more than three days in the past or is in the future, give a warning. If the <front> element in the <rfc> element has a <date> element with some but not all of the “day”, “month”, and “year” attibutes, give an error.</p>
<h1 id="rfc.section.5.2.4"><a href="#rfc.section.5.2.4">5.2.4.</a> <a href="#preptime-insertion" id="preptime-insertion">“prepTime” Insertion</a></h1>
<p id="rfc.section.5.2.4.p.1">If the input document includes a “prepTime” attribute of <rfc>, exit with an error.</p>
<p id="rfc.section.5.2.4.p.2">Fill in the “prepTime” attribute of <rfc> with the current datetime.</p>
<h1 id="rfc.section.5.2.5"><a href="#rfc.section.5.2.5">5.2.5.</a> <a href="#ol-group-start-insertion" id="ol-group-start-insertion"><ol> Group “start” Insertion</a></h1>
<p id="rfc.section.5.2.5.p.1">Add a “start” attribute to every <ol> element containing a group that does not already have a start.</p>
<h1 id="rfc.section.5.2.6"><a href="#rfc.section.5.2.6">5.2.6.</a> <a href="#attribute-default-value-insertion" id="attribute-default-value-insertion">Attribute Default Value Insertion</a></h1>
<p id="rfc.section.5.2.6.p.1">Fill in any default values for attributes on elements, except “keepWithNext” and “keepWithPrevious” of <t>, and “toc” of <section>. Some default values can be found in the Relax NG schema, while others can be found in the prose describing the elements in <a href="#I-D.iab-xml2rfc">[I-D.iab-xml2rfc]</a>).</p>
<h1 id="rfc.section.5.2.7"><a href="#rfc.section.5.2.7">5.2.7.</a> <a href="#section-toc" id="section-toc">Section “toc” attribute</a></h1>
<p id="rfc.section.5.2.7.p.1">For each <section>, modify the “toc” attribute to be either “include” or “exclude”:</p>
<p/>
<ul>
<li>for sections that have an ancestor of <boilerplate>, use “exclude”</li>
<li>else for sections that have a descendant that has toc=”include”, use “include”. If the section has toc=”exclude” in the input, this is an error.</li>
<li>else for sections that are children of a section with toc=”exclude”, use “exclude”.</li>
<li>else for sections that are deeper than rfc/@tocDepth, use “exclude”</li>
<li>else use “include”</li>
</ul>
<h1 id="rfc.section.5.2.8"><a href="#rfc.section.5.2.8">5.2.8.</a> <a href="#remove-in-rfc-warning" id="remove-in-rfc-warning">“removeInRFC” Warning Paragraph</a></h1>
<p id="rfc.section.5.2.8.p.1">If in I-D mode, if there is a <note> or <section> element with a “removeInRFC” attribute that has the value “true”, add a paragraph to the top of the element with the text “This note is to be removed before publishing as an RFC.” or “This section…”, unless a paragraph consisting of that exact text already exists.</p>
<h1 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3.</a> <a href="#normalization" id="normalization">Normalization</a></h1>
<p id="rfc.section.5.3.p.1">These steps will ensure that ideas that can be expressed in multiple different ways in the input document are only found in one way in the prepared document.</p>
<h1 id="rfc.section.5.3.1"><a href="#rfc.section.5.3.1">5.3.1.</a> <a href="#normalize-month-attribute" id="normalize-month-attribute">“month” Attribute</a></h1>
<p id="rfc.section.5.3.1.p.1">Normalize the values of “month” attributes in all <date> elements in <front> elements in <rfc> elements to numeric values.</p>
<h1 id="rfc.section.5.3.2"><a href="#rfc.section.5.3.2">5.3.2.</a> <a href="#ascii-atttribute-processing" id="ascii-atttribute-processing">ASCII Attribute Processing</a></h1>
<p id="rfc.section.5.3.2.p.1">In every <email>, <organization>, <street>, <city>, <region>, <country>, and <code> element, if there is an “ascii” attribute and the value of that attribute is the same as the content of the element, remove the “ascii” element and issue a warning about the removal.</p>
<p id="rfc.section.5.3.2.p.2">In every <author> element, if there is an “asciiFullname”, “asciiInitials”, or “asciiSurname” attribute, check the content of that element against its matching “fullname”, “initials”, or “surname” element (respectively). If the two are the same, remove the “ascii*” elelement and issue a warning about the removal.</p>
<h1 id="rfc.section.5.3.3"><a href="#rfc.section.5.3.3">5.3.3.</a> <a href="#title-conversion" id="title-conversion">“title” Conversion</a></h1>
<p id="rfc.section.5.3.3.p.1">For every <section>, <note>, <figure>, <references>, and <texttable> element that has a (deprecated) “title” attribute, remove the “title” attribute and insert a <name> element with the title from the attribute.</p>
<h1 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4.</a> <a href="#generation" id="generation">Generation</a></h1>
<p id="rfc.section.5.4.p.1">These steps will generate new content, overriding existing similar content in the input document. Some of these steps are important enough that they specify a warning to be generated when the content being overwritten does not match the new content.</p>
<h1 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1.</a> <a href="#expiresdate-insertion" id="expiresdate-insertion">“expiresDate” Insertion</a></h1>
<p id="rfc.section.5.4.1.p.1">If in I-D mode, fill in “expiresDate” attribute of <rfc> based on the <date> element of the document’s <front> element.</p>
<h1 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2.</a> <a href="#boilerplate-insertion" id="boilerplate-insertion"><boilerplate> Insertion</a></h1>
<p id="rfc.section.5.4.2.p.1">Create a <boilerplate> element if it does not exist. If there are any children of the <boilerplate> element, produce a warning that says “Existing boilerplate being removed. Other tools, specifically the draft submission tool, will treat this condition as an error” and remove the existing children.</p>
<h1 id="rfc.section.5.4.2.1"><a href="#rfc.section.5.4.2.1">5.4.2.1.</a> <a href="#compare-submission" id="compare-submission">Compare <rfc> “submissionType” and <seriesInfo> “stream”</a></h1>
<p id="rfc.section.5.4.2.1.p.1">Verify that <rfc> “submissionType” and <seriesInfo> “stream” are the same if they are both present. If either is missing, add it. Note that both have a default value of “IETF”.</p>
<h1 id="rfc.section.5.4.2.2"><a href="#rfc.section.5.4.2.2">5.4.2.2.</a> <a href="#status-of-this-memo-insertion" id="status-of-this-memo-insertion">‘Status of this Memo’ Insertion</a></h1>
<p id="rfc.section.5.4.2.2.p.1">Add the “Status of this Memo” section to the <boilerplate> element with current values. The application will use the “submissionType”, and “consensus” attributes of the <rfc> element, the <workgroup> element, and the “status” and “stream” attributes of the <seriesInfo> element, to determine which <a href="#I-D.iab-rfc5741bis">[I-D.iab-rfc5741bis]</a> boilerplate to include, as described in Appendix A of <a href="#I-D.iab-xml2rfc">[I-D.iab-xml2rfc]</a>.</p>
<h1 id="rfc.section.5.4.2.3"><a href="#rfc.section.5.4.2.3">5.4.2.3.</a> <a href="#copyright-insertion" id="copyright-insertion">Copyright Insertion</a></h1>
<p id="rfc.section.5.4.2.3.p.1">Add the “Copyright Notice” section to the <boilerplate> element. The application will use the “ipr” and “submissionType” attributes of the <rfc> element and the <date> element to determine which portions and which version of the TLP to use, as described in A.1 of <a href="#I-D.iab-xml2rfc">[I-D.iab-xml2rfc]</a>.</p>
<h1 id="rfc.section.5.4.3"><a href="#rfc.section.5.4.3">5.4.3.</a> <a href="#reference-target-insertion" id="reference-target-insertion"><reference> “target” Insertion</a></h1>
<p id="rfc.section.5.4.3.p.1">For any <reference> element that does not already have a “target” attribute, fill the target attribute in if the element has one or more <seriesinfo> child element(s) and the “name” attribute of the <seriesinfo> element is “RFC”, “Internet-Draft”, or “DOI” or other value for which it is clear what the “target” should be. The particular URLs for RFCs, Internet-Drafts, and DOIs for this step will be specified later by the RFC Editor and the IESG. These URLs might also be different before and after the v3 format is adopted.</p>
<h1 id="rfc.section.5.4.4"><a href="#rfc.section.5.4.4">5.4.4.</a> <a href="#name-slugification" id="name-slugification"><name> Slugification</a></h1>
<p id="rfc.section.5.4.4.p.1">Add a “slugifiedName” attribute to each <name> element that does not contain one; replace the attribute if it contains a value that begins with “n-“.</p>
<h1 id="rfc.section.5.4.5"><a href="#rfc.section.5.4.5">5.4.5.</a> <a href="#reference-sorting" id="reference-sorting"><reference> Sorting</a></h1>
<p id="rfc.section.5.4.5.p.1">If the “sortRefs” attribute of the <rfc> element is true, sort the <reference>s and <referencegroup>s lexically by the value of the “anchor” attribute, as modified by the “to” attribute of any <displayreference> element. The RFC Editor needs to determine what the rules for lexical sorting are. The authors of this document acknowledge that getting consensus on this will be a difficult task.</p>
<h1 id="rfc.section.5.4.6"><a href="#rfc.section.5.4.6">5.4.6.</a> <a href="#part-numbering" id="part-numbering">“pn” Numbering</a></h1>
<p id="rfc.section.5.4.6.p.1">Add “pn” attributes for all parts. Parts are:</p>
<p/>
<ul>
<li><section> in <middle>: pn=’s-1.4.2’</li>
<li><references>: pn=’s-12’ or pn=’s-12.1’</li>
<li><abstract>: pn=’s-abstract’</li>
<li><note>: pn=’s-note-2’</li>
<li><section> in <boilerplate>: pn=’s-boilerplate-1’</li>
<li><table>: pn=’t-3’</li>
<li><figure>: pn=’f-4’</li>
<li><artwork>, <aside>, <blockquote>, <dt>, <li>, <sourcecode>, <t>: pn=’p-[section]-[counter]’</li>
</ul>
<h1 id="rfc.section.5.4.7"><a href="#rfc.section.5.4.7">5.4.7.</a> <a href="#iref-numbering" id="iref-numbering"><iref> Numbering</a></h1>
<p id="rfc.section.5.4.7.p.1">In every <iref> element, create a document-unique “pn” attribute. The value of the “pn” attribute will start with ‘i-‘, and use the item attribute, the subitem attribute (if it exists), and a counter to ensure uniqueness. For example, the first instance of “<iref item=’foo’ subitem=’bar’>” will get the irefid ‘i-foo-bar-1’.</p>
<h1 id="rfc.section.5.4.8"><a href="#rfc.section.5.4.8">5.4.8.</a> <a href="#xref-processing" id="xref-processing"><xref> processing</a></h1>
<h1 id="rfc.section.5.4.8.1"><a href="#rfc.section.5.4.8.1">5.4.8.1.</a> <a href="#xref-derivedcontent-insertion-with-content" id="xref-derivedcontent-insertion-with-content">“derivedContent” Insertion (With Content)</a></h1>
<p id="rfc.section.5.4.8.1.p.1">For each <xref> element that has content, fill the “derivedContent” with the element content, having first trimmed the whitespace from ends of content text. Issue a warning if the “derivedContent” attribute already exists and has a different value from what was being filled in.</p>
<h1 id="rfc.section.5.4.8.2"><a href="#rfc.section.5.4.8.2">5.4.8.2.</a> <a href="#xref-derivedcontent-insertion-without-content" id="xref-derivedcontent-insertion-without-content">“derivedContent” Insertion (Without Content)</a></h1>
<p id="rfc.section.5.4.8.2.p.1">For each <xref> element that does not have content, fill the “derivedContent” based on the “format” attribute.</p>
<p/>
<ul>
<li>For format=’counter’, the “derivedContent” is the section, figure, table, or ordered list number of the element with anchor equal to the xref target.</li>
<li>For format=’default’ and the “target” attribute points to a <reference> or <referencegroup> element, the “derivedContent” is the value of the “target” attribute (or the “to” attribute of a <displayreference> element for the targeted <reference>).</li>
<li>For format=’default’ and the “target” attribute points to a <section>, <figure>, or <table>, the “derivedContent” is the name of the thing pointed to, such as “Section 2.3”, “Figure 12”, or “Table 4”.</li>
<li>For format=’title’, if the target is a <reference> element, the “derivedContent” attribute is the name of the reference, extracted from the <title> child of the <front> child of the reference.</li>
<li>For format=’title’, if the target element has a <name> child element, the “derivedContent” attribute is the text content of that <name> element concatenated with the text content of each descendant node of <name> (that is, stripping out all of the XML markup, leaving only the text).</li>
<li>For format=’title’, if the target element does not contain a <name> child element, the “derivedContent” attribute is the value of the “target” attribute with no other adornment. Issue a warning if the “derivedContent” attribute already exists and has a different value from what was being filled in.</li>
</ul>
<h1 id="rfc.section.5.4.9"><a href="#rfc.section.5.4.9">5.4.9.</a> <a href="#relref-processing" id="relref-processing"><relref> Processing</a></h1>
<p id="rfc.section.5.4.9.p.1">If any <relref> element’s “target” attribute refers to anything but a <reference> element, give an error.</p>
<p id="rfc.section.5.4.9.p.2">For each <relref> element, fill in the “derivedLink” attribute.</p>
<h1 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5.</a> <a href="#inclusion" id="inclusion">Inclusion</a></h1>
<p id="rfc.section.5.5.p.1">These steps will include external files into the output document.</p>
<h1 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1.</a> <a href="#artwork-processing" id="artwork-processing"><artwork> Processing</a></h1>
<p/>
<ol>
<li>If an <artwork> element has a “src” attribute where no scheme is specified, copy the “src” attribute value to the “originalSrc” attribute, and replace the “src” value with a URI that uses the “file:” scheme in a path relative to the file being processed. See <a href="#securitycons">Section 8</a> for warnings about this step. This will likely be one of the most common authoring approaches.</li>
<li>If an <artwork> element has a “src” attribute with a “file:” scheme, and if processing the URL would cause the processor to retrieve a file that is not in the same directory, or a subdirectory, as the file being processed, give an error. If the “src” has any shellmeta strings (such as “`”, “$USER”, and so on) that would be processed, give an error. Replace the “src” attribute with a URI that uses the “file:” scheme in a path relative to the file being processed. This rule attempts to prevent <artwork src=’file:///etc/passwd’> and similar security issues. See <a href="#securitycons">Section 8</a> for warnings about this step.</li>
<li>If an <artwork> element has a “src” attribute, and the element has content, give an error.</li>
<li>If an <artwork> element has type=’svg’ and there is a “src” attribute, the data needs to be moved into the content of the <artwork> element. <ul><li>If the “src” URI scheme is “data:”, fill the content of the <artwork> element with that data and remove the “src” attribute.</li><li>If the “src” URI scheme is “file:”, “http:”, or “https:”, fill the content of the <artwork> element with the resolved XML from the URI in the “src” attribute. If there is no “originalSrc” attribute, add an “originalSrc” attribute with the value of the URI and remove the “src” attribute.</li><li>If the <artwork> element has an “alt” attribute, and the SVG does not have a <desc> element, add the <desc> element with the contents of the “alt” attribute.</li></ul></li>
<li>If an <artwork> element has type=’binary-art’, the data needs to be in a “src” attribute with a URI scheme of “data:”. If the “src” URI scheme is “file:”, “http:”, or “https:”, resolve the URL. Replace the “src” attribute with a “data:” URI, and add an “originalSrc” attribute with the value of the URI. For the “http:” and “https:” URI schemes, the mediatype of the “data:” URI will be the Content-Type of the HTTP response. For the “file:” URI scheme, the mediatype of the “data:” URI needs to be guessed with heuristics (this is possibly a bad idea). This also fails for content that includes binary images but uses a type other than “binary-art”. Note: since this feature can’t be used for RFCs at the moment, this entire feature might be de-prioritized.</li>
<li>If an <artwork> element does not have type=’svg’ or type=’binary-art’ and there is a “src” attribute, the data needs to be moved into the content of the <artwork> element. Note that this step assumes that all of the preferred types other than “binary-art” are text, which is possibly wrong. <ul><li>If the “src” URI scheme is “data:”, fill the content of the <artwork> element with the correctly-escaped form of that data and remove the “src” attribute.</li><li>If the “src” URI scheme is “file:”, “http:”, or “https:”, fill the content of the <artwork> element with the correctly-escaped form of the resolved text from the URI in the “src” attribute. If there is no “originalSrc” attribute, add an “originalSrc” attribute with the value of the URI and remove the “src” attribute.</li></ul></li>
</ol>
<h1 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2.</a> <a href="#sourcecode-processing" id="sourcecode-processing"><sourcecode> Processing</a></h1>
<p/>
<ol>
<li>If a <sourcecode> element has a “src” attribute where no scheme is specified, copy the “src” attribute value to the “originalSrc” attribute, and replace the “src” value with a URI that uses the “file:” scheme in a path relative to the file being processed. See <a href="#securitycons">Section 8</a> for warnings about this step. This will likely be one of the most common authoring approaches.</li>
<li>If a <sourcecode> element has a “src” attribute with a “file:” scheme, and if processing the URL would cause the processor to retrieve a file that is not in the same directory, or a subdirectory, as the file being processed, give an error. If the “src” has any shellmeta strings (such as “`”, “$USER”, and so on) that would be processed , give an error. Replace the “src” attribute with a URI that uses the “file:” scheme in a path relative to the file being processed. This rule attempts to prevent <sourcecode src=’file:///etc/passwd’> and similar security issues. See <a href="#securitycons">Section 8</a> for warnings about this step.</li>
<li>If a <sourcecode> element has a “src” attribute, and the element has content, give an error.</li>
<li>If a <sourcecode> element has a “src” attribute, the data needs to be moved into the content of the <sourcecode> element. <ul><li>If the “src” URI scheme is “data:”, fill the content of the <sourcecode> element with that data and remove the “src” attribute.</li><li>If the “src” URI scheme is “file:”, “http:”, or “https:”, fill the content of the <sourcecode> element with the resolved XML from the URI in the “src” attribute. If there is no “originalSrc” attribute, add an “originalSrc” attribute with the value of the URI and remove the “src” attribute.</li></ul></li>
</ol>
<h1 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6.</a> <a href="#rfc-production-mode-cleanup" id="rfc-production-mode-cleanup">RFC Production Mode Cleanup</a></h1>
<p id="rfc.section.5.6.p.1">These steps provide extra cleanup of the output document in RFC production mode.</p>
<h1 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1.</a> <a href="#note-removal" id="note-removal"><note> Removal</a></h1>
<p id="rfc.section.5.6.1.p.1">If in RFC production mode, if there is a <note> or <section> element with a “removeInRFC” attribute that has the value “true”, remove the element.</p>
<h1 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2.</a> <a href="#cref-removal" id="cref-removal"><cref> Removal</a></h1>
<p id="rfc.section.5.6.2.p.1">If in RFC production mode, remove all <cref> elements.</p>
<h1 id="rfc.section.5.6.3"><a href="#rfc.section.5.6.3">5.6.3.</a> <a href="#link-processing" id="link-processing"><link> Processing</a></h1>
<p/>
<ol>
<li>If in RFC production mode, remove all <link> elements whose “rel” attribute has the value “alternate”.</li>
<li>If in RFC production mode, check if there is a <link> element with the current ISSN for the RFC series (2070-1721); if not, add <link rel=”item” href=”urn:issn:2070-1721”>.</li>
<li>If in RFC production mode, check if there is a <link> element with a DOI for this RFC; if not, add one of the form <link rel=”describedBy” href=”https://dx.doi.org/10.17487/rfcdd”> where “dd” is the number of the RFC, such as “https://dx.doi.org/10.17487/rfc2109”. The URI is described in <a href="#RFC7669">[RFC7669]</a>. If there was already a <link> element with a DOI for this RFC, check that the “href” value has the right format.</li>
<li>If in RFC production mode, check if there is a <link> element with the file name of the Internet-Draft that became this RFC the form <link rel=”convertedFrom” href=”https://datatracker.ietf.org/doc/draft-tttttttttt/”>. If one does not exist, give an error.</li>
</ol>
<h1 id="rfc.section.5.6.4"><a href="#rfc.section.5.6.4">5.6.4.</a> <a href="#xml-comment-removal" id="xml-comment-removal">XML Comment Removal</a></h1>
<p id="rfc.section.5.6.4.p.1">If in RFC production mode, remove XML comments.</p>
<h1 id="rfc.section.5.6.5"><a href="#rfc.section.5.6.5">5.6.5.</a> <a href="#base-originalsrc-removal" id="base-originalsrc-removal">“xml:base” and “originalSrc” Removal</a></h1>
<p id="rfc.section.5.6.5.p.1">If in RFC production mode, remove all “xml:base” or “originalSrc” attributes from all elements.</p>
<h1 id="rfc.section.5.6.6"><a href="#rfc.section.5.6.6">5.6.6.</a> <a href="#compliance-check" id="compliance-check">Compliance Check</a></h1>
<p id="rfc.section.5.6.6.p.1">If in RFC production mode, ensure that the result is in full compliance to v3 schema, without any deprecated elements or attributes, and give an error if any issues are found.</p>
<h1 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7.</a> <a href="#finalization" id="finalization">Finalization</a></h1>
<p id="rfc.section.5.7.p.1">These steps provide the finishing touches on the output document.</p>
<h1 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1.</a> <a href="#scripts-insertion" id="scripts-insertion">“scripts” Insertion</a></h1>
<p id="rfc.section.5.7.1.p.1">Determine all the characters used in the document, and fill in the “scripts” attribute for <rfc>.</p>
<h1 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2.</a> <a href="#pretty" id="pretty">Pretty-Format</a></h1>
<p id="rfc.section.5.7.2.p.1">Pretty-format the XML output. (Note: there are many tools that do an adequate job.)</p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#additional-uses-for-the-prep-tool" id="additional-uses-for-the-prep-tool">Additional Uses for the Prep Tool</a></h1>
<p id="rfc.section.6.p.1">There will be a need for Internet-Draft authors who include files from their local disk (such as for <artwork src=”mydrawing.svg”/>) to have the contents of those files inlined to their drafts before submitting them to the Internet-Draft processor. (There is a possibility that the Internet-Draft processor will allow XML files and accompanying files to be submitted at the same time, but this seems troublesome from a security, portability, and complexity standpoint.) For these users, having a local copy of the prep tool that has an option to just inline all local files would be terribly useful. That option would be a proper subset of the steps given in <a href="#steps">Section 5</a>.</p>
<p id="rfc.section.6.p.2">A feature that might be useful in a local prep tool would be the inverse of the “just inline” option would be “extract all”. This would allow a user who has a v3 RFC or Internet-Draft to dump all of the <artwork> and <sourcecode> elements into local files instead of having to find each one in the XML. This option might even do as much validation as possible on the extracted <sourcecode> elements. This feature might also remove some of the features added by the prep tool (such as part numbers and slugifiedName’s starting with “n-“) in order to make the resulting file easier to edit.</p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#ianacons" id="ianacons">IANA Considerations</a></h1>
<p id="rfc.section.7.p.1">None.</p>
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#securitycons" id="securitycons">Security Considerations</a></h1>
<p id="rfc.section.8.p.1">Steps in this document attempt to prevent the <artwork> and <sourcecode> entities from exposing the contents of files outside the directory in which the document being processed resides. For example, values starting with “/”, “./”, or “../” should generate errors.</p>
<p id="rfc.section.8.p.2">The security considerations in <a href="#RFC3470">[RFC3470]</a> apply here. In specific, processing XML external references can expose a prep tool implementation to various threats by causing the implementation to access external resources automatically. It is important to disallow arbitrary access to such external references within XML data from untrusted sources.</p>
<h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a></h1>
<p id="rfc.section.9.p.1">Many people contributed valuable ideas to this document. Special thanks go to Robert Sparks for his in-depth review and contributions early in the development of this document, and to Julian Reschke for his help getting the document structured more clearly.</p>
<h1 id="rfc.references"><a href="#rfc.references">10.</a> Informative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="I-D.iab-rfc5741bis">[I-D.iab-rfc5741bis]</b>
</td>
<td class="top"><a>Halpern, J.</a>, <a>Daigle, L.</a> and <a>O. Kolkman</a>, "<a href="http://tools.ietf.org/html/draft-iab-rfc5741bis-02">On RFC Streams, Headers, and Boilerplates</a>", Internet-Draft draft-iab-rfc5741bis-02, February 2016.</td>
</tr>
<tr>
<td class="reference">
<b id="I-D.iab-xml2rfc">[I-D.iab-xml2rfc]</b>
</td>
<td class="top"><a>Hoffman, P.</a>, "<a href="http://tools.ietf.org/html/draft-iab-xml2rfc-04">The "xml2rfc" version 3 Vocabulary</a>", Internet-Draft draft-iab-xml2rfc-04, June 2016.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC3470">[RFC3470]</b>
</td>
<td class="top"><a>Hollenbeck, S.</a>, <a>Rose, M.</a> and <a>L. Masinter</a>, "<a href="http://tools.ietf.org/html/rfc3470">Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols</a>", BCP 70, RFC 3470, DOI 10.17487/RFC3470, January 2003.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6949">[RFC6949]</b>
</td>
<td class="top"><a>Flanagan, H.</a> and <a>N. Brownlee</a>, "<a href="http://tools.ietf.org/html/rfc6949">RFC Series Format Requirements and Future Development</a>", RFC 6949, DOI 10.17487/RFC6949, May 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7669">[RFC7669]</b>
</td>
<td class="top"><a>Levine, J.</a>, "<a href="http://tools.ietf.org/html/rfc7669">Assigning Digital Object Identifiers to RFCs</a>", RFC 7669, DOI 10.17487/RFC7669, October 2015.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.authors">
<a href="#rfc.authors">Authors' Addresses</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Paul Hoffman</span>
<span class="n hidden">
<span class="family-name">Hoffman</span>
</span>
</span>
<span class="org vcardline">ICANN</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Joe Hildebrand</span>
<span class="n hidden">
<span class="family-name">Hildebrand</span>
</span>
</span>
<span class="org vcardline">Cisco</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
</address>
</div>
</body>
</html>