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
|
<pre>Network Working Group G. Klyne
Request for Comments: 3864 Nine by Nine
BCP: 90 M. Nottingham
Category: Best Current Practice BEA
J. Mogul
HP Labs
September 2004
<span class="h1">Registration Procedures for Message Header Fields</span>
Status of this Memo
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.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This specification defines registration procedures for the message
header fields used by Internet mail, HTTP, Netnews and other
applications.
<span class="grey">Klyne, et al. Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Structure of this Document . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Document Terminology and Conventions . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Message Header Fields. . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Permanent and Provisional Header Fields. . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Definitions of Message Header Fields . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2.1">2.2.1</a>. Application-specific Message Header Fields. . . . <a href="#page-5">5</a>
<a href="#section-2.2.2">2.2.2</a>. MIME Header Fields. . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3">3</a>. Registry Usage Requirements. . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Registration Procedure . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Header Field Specification . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. Registration Templates . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
4.2.1. Permanent Message Header Field Registration
Template. . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
4.2.2. Provisional Message Header Field Submission
Template. . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. Submission of Registration . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. Objections to Registration . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.5">4.5</a>. Change Control . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.6">4.6</a>. Comments on Header Definitions . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.7">4.7</a>. Location of Header Field Registry. . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9">9</a>. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-10">10</a>. Full Copyright Statement . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This specification defines registration procedures for the message
header field names used by Internet mail, HTTP, newsgroup feeds and
other Internet applications. It is not intended to be a replacement
for protocol-specific registries, such as the SIP registry [<a href="#ref-30" title=""SIP: Session Initiation Protocol"">30</a>].
Benefits of a central registry for message header field names
include:
o providing a single point of reference for standardized and
widely-used header field names;
o providing a central point of discovery for established header
fields, and easy location of their defining documents;
<span class="grey">Klyne, et al. Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
o discouraging multiple definitions of a header field name for
different purposes;
o helping those proposing new header fields discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o encouraging convergence of header field name usage across multiple
applications and protocols.
The primary specification for Internet message header fields in email
is the Internet mail message format specification, <a href="./rfc2822">RFC 2822</a> [<a href="#ref-4" title=""Internet Message Format"">4</a>].
HTTP/1.0 [<a href="#ref-10" title=""Hypertext Transfer Protocol -- HTTP/1.0"">10</a>] and HTTP/1.1 [<a href="#ref-24" title=""Hypertext Transfer Protocol -- HTTP/1.1"">24</a>] define message header fields
(respectively, the HTTP-header and message-header protocol elements)
for use with HTTP. <a href="./rfc1036">RFC 1036</a> [<a href="#ref-5" title=""Standard for interchange of USENET messages"">5</a>] defines message header elements for
use with Netnews feeds. These specifications also define a number of
header fields, and provide for extension through the use of new
field-names.
There are many other Internet standards track documents that define
additional header fields for use within the same namespaces, notably
MIME [<a href="#ref-11" title=""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"">11</a>] and related specifications. Other Internet applications
that use MIME, such as SIP (<a href="./rfc3261">RFC 3261</a> [<a href="#ref-30" title=""SIP: Session Initiation Protocol"">30</a>]) may also use many of the
same header fields (but note that IANA maintains a separate registry
of header fields used with SIP).
Although in principle each application defines its own set of valid
header fields, exchange of messages between applications (e.g., mail
to Netnews gateways), common use of MIME encapsulation, and the
possibility of common processing for various message types (e.g., a
common message archive and retrieval facility) makes it desirable to
have a common point of reference for standardized and proposed header
fields. Listing header fields together reduces the chance of an
accidental collision, and helps implementers find relevant
information. The message header field registries defined here serve
that purpose.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Structure of this Document</span>
<a href="#section-2">Section 2</a> discusses the purpose of this specification, and indicates
some sources of information about defined message header fields.
<a href="#section-4">Section 4</a> defines the message header field name repositories, and
sets out requirements and procedures for creating entries in them.
<span class="grey">Klyne, et al. Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Document Terminology and Conventions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a> [<a href="#ref-2" title=""Key words for use in RFCs to Indicate Requirement Levels"">2</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Message Header Fields</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Permanent and Provisional Header Fields</span>
Many message header fields are defined in standards-track documents,
which means they have been subjected to a process of community review
and achieved consensus that they provide a useful and well-founded
capability, or represent a widespread use of which developers should
be aware. Some are defined for experimental use, typically
indicating consensus regarding their purpose but not necessarily
concerning their technical details. Many others have been defined
and adopted ad-hoc to address a locally occurring requirement; some
of these have found widespread use.
The catalogues defined here are intended to cater for all of these
header fields, while maintaining a clear distinction and status for
those which have community consensus. To this end, two repositories
are defined:
o A Permanent Message Header Field Registry, intended for headers
defined in IETF standards-track documents, those that have
achieved a comparable level of community review, or are generally
recognized to be in widespread use. The assignment policy for
such registration is "Specification Required", as defined by <a href="./rfc2434">RFC</a>
<a href="./rfc2434">2434</a> [<a href="#ref-3" title="">3</a>], where the specification must be published in an RFC
(standards-track, experimental, informational or historic), or as
an "Open Standard" in the sense of <a href="./rfc2026#section-7">RFC 2026, section 7</a> [<a href="#ref-1" title=""The Internet Standards Process -- Revision 3"">1</a>].
o A Provisional Message Header Field Repository, intended for any
header field proposed by any developer, without making any claim
about its usefulness or the quality of its definition. The policy
for recording these is "Private Use", per <a href="./rfc2434">RFC 2434</a> [<a href="#ref-3" title="">3</a>].
Neither repository tracks the syntax, semantics or type of field-
values. Only the field-names, applicable protocols and status are
registered; all other details are specified in the defining documents
referenced by repository entries. Significant updates to such
references (e.g., the replacement of a Proposed Standard RFC by a
Draft Standard RFC, but not necessarily the revision of an Internet-
draft) SHOULD be accompanied by updates to the corresponding
repository entries.
<span class="grey">Klyne, et al. Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Definitions of Message Header Fields</span>
<a href="./rfc2822">RFC 2822</a> [<a href="#ref-4" title=""Internet Message Format"">4</a>] defines a general syntax for message headers, and also
defines a number of fields for use with Internet mail. HTTP/1.0 [<a href="#ref-10" title=""Hypertext Transfer Protocol -- HTTP/1.0"">10</a>]
and HTTP/1.1 [<a href="#ref-24" title=""Hypertext Transfer Protocol -- HTTP/1.1"">24</a>] do likewise for HTTP. Additional field names are
defined in a variety of standards-track RFC documents, including: <a href="./rfc1036">RFC</a>
<a href="./rfc1036">1036</a> [<a href="#ref-5" title=""Standard for interchange of USENET messages"">5</a>], <a href="./rfc1496">RFC 1496</a> [<a href="#ref-6" title=""Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages"">6</a>], <a href="./rfc1505">RFC 1505</a> [<a href="#ref-7" title=""Encoding Header Field for Internet Messages"">7</a>], <a href="./rfc1864">RFC 1864</a> [<a href="#ref-9" title=""The Content-MD5 Header Field"">9</a>], <a href="./rfc2156">RFC 2156</a> [<a href="#ref-14" title=""MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME"">14</a>],
<a href="./rfc2183">RFC 2183</a> [<a href="#ref-15" title=""Communicating Presentation Information in Internet Messages: The Content- Disposition Header Field"">15</a>], <a href="./rfc2045">RFC 2045</a> [<a href="#ref-11" title=""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"">11</a>], <a href="./rfc2046">RFC 2046</a> [<a href="#ref-12" title=""Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"">12</a>], <a href="./rfc2557">RFC 2557</a> [<a href="#ref-23" title=""MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)"">23</a>], <a href="./rfc2227">RFC 2227</a>
[<a href="#ref-16" title=""Simple Hit-Metering and Usage-Limiting for HTTP"">16</a>], <a href="./rfc2231">RFC 2231</a> [<a href="#ref-17" title=""MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations"">17</a>], <a href="./rfc2298">RFC 2298</a> [<a href="#ref-18" title=""Message Disposition Notification"">18</a>], <a href="./rfc2369">RFC 2369</a> [<a href="#ref-19" title=""The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields"">19</a>], <a href="./rfc2421">RFC 2421</a> [<a href="#ref-21" title=""Voice Profile for Internet Mail - version 2 (VPIMv2)"">21</a>], <a href="./rfc2518">RFC</a>
<a href="./rfc2518">2518</a> [<a href="#ref-22" title=""HTTP Extensions for Distributed Authoring -- WEBDAV"">22</a>], <a href="./rfc2617">RFC 2617</a> [<a href="#ref-25" title=""HTTP Authentication: Basic and Digest Access Authentication"">25</a>], <a href="./rfc2821">RFC 2821</a> [<a href="#ref-26" title=""Simple Mail Transfer Protocol"">26</a>], <a href="./rfc2912">RFC 2912</a> [<a href="#ref-27" title=""Indicating Media Features for MIME Content"">27</a>], <a href="./rfc2919">RFC 2919</a>
[<a href="#ref-28" title=""List-Id: A Structured Field and Namespace for the Identification of Mailing Lists"">28</a>], <a href="./rfc2965">RFC 2965</a> [<a href="#ref-29" title=""HTTP State Management Mechanism"">29</a>], and <a href="./rfc3282">RFC 3282</a> [<a href="#ref-31" title=""Content Language Headers"">31</a>].
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Application-specific Message Header Fields</span>
Internet applications that use similar message headers include
Internet mail [<a href="#ref-26" title=""Simple Mail Transfer Protocol"">26</a>] [<a href="#ref-4" title=""Internet Message Format"">4</a>], NNTP newsgroup feeds [<a href="#ref-5" title=""Standard for interchange of USENET messages"">5</a>], HTTP web access
[<a href="#ref-24" title=""Hypertext Transfer Protocol -- HTTP/1.1"">24</a>] and any other that uses MIME [<a href="#ref-11" title=""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"">11</a>] encapsulation of message
content.
In some cases (notably HTTP [<a href="#ref-24" title=""Hypertext Transfer Protocol -- HTTP/1.1"">24</a>]), the header syntax and usage is
redefined for the specific application. This registration is
concerned only with the allocation and specification of field names,
and not with the details of header implementation in specific
protocols.
In some cases, the same field name may be specified differently (by
different documents) for use with different application protocols;
e.g., The Date: header field used with HTTP has a different syntax
than the Date: used with Internet mail. In other cases, a field name
may have a common specification across multiple protocols (ignoring
protocol-specific lexical and character set conventions); e.g., this
is generally the case for MIME header fields with names of the form
'Content-*'.
Thus, we need to accommodate application-specific fields, while
wishing to recognize and promote (where appropriate) commonality of
other fields across multiple applications. Common repositories are
used for all applications, and each registered header field specifies
the application protocol for which the corresponding definition
applies. A given field name may have multiple registry entries for
different protocols; in the Permanent Message Header Field registry,
a given header field name may be registered only once for any given
protocol. (In some cases, the registration may reference several
defining documents.)
<span class="grey">Klyne, et al. Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. MIME Header Fields</span>
Some header fields with names of the form Content-* are associated
with the MIME data object encapsulation and labelling framework.
These header fields can meaningfully be applied to a data object
separately from the protocol used to carry it.
MIME is used with email messages and other protocols that specify a
MIME-based data object format. MIME header fields used with such
protocols are defined in the registry with the protocol "mime", and
as such are presumed to be usable in conjunction with any protocol
that conveys MIME objects.
Other protocols do not convey MIME objects, but define a number of
header fields with similar names and functions to MIME. Notably,
HTTP defines a number of entity header fields that serve a purpose in
HTTP similar to MIME header fields in email. Some of these header
fields have the same names and similar functions to their MIME
counterparts (though there are some variations). Such header fields
must be registered separately for any non-MIME-carrying protocol with
which they may be used.
It is poor practice to reuse a header field name from another
protocol simply because the fields have similar (even "very similar")
meanings. Protocols should share header field names only when their
meanings are identical in all foreseeable circumstances. In
particular, new header field names of the form Content-* should not
be defined for non-MIME-carrying protocols unless their specification
is exactly the same as in MIME.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Registry Usage Requirements</span>
RFCs defining new header fields for Internet mail, HTTP, or MIME MUST
include appropriate header registration template(s) (as given in
<a href="#section-4.2">Section 4.2</a>) for all headers defined in the document in their IANA
considerations section. Use of the header registry MAY be mandated
by other protocol specifications, however, in the absence of such a
mandate use of the registry is not required.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Registration Procedure</span>
The procedure for registering a message header field is:
1. Construct a header field specification
2. Prepare a registration template
3. Submit the registration template
<span class="grey">Klyne, et al. Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Header Field Specification</span>
Registration of a new message header field starts with construction
of a proposal that describes the syntax, semantics and intended use
of the field. For entries in the Permanent Message Header Field
Registry, this proposal MUST be published as an RFC, or as an Open
Standard in the sense described by <a href="./rfc2026#section-7">RFC 2026, section 7</a> [<a href="#ref-1" title=""The Internet Standards Process -- Revision 3"">1</a>].
A registered field name SHOULD conform at least to the syntax defined
by <a href="./rfc2822">RFC 2822</a> [<a href="#ref-4" title=""Internet Message Format"">4</a>], section 3.6.8.
Further, the "." character is reserved to indicate a naming sub-
structure and MUST NOT be included in any registered field name.
Currently, no specific sub-structure is defined; if used, any such
structure MUST be defined by a standards track RFC document.
Header field names may sometimes be used in URIs, URNs and/or XML.
To comply with the syntactic constraints of these forms, it is
recommended that characters in a registered field name are restricted
to those that can be used without escaping in a URI [<a href="#ref-20" title=""Uniform Resource Identifiers (URI): Generic Syntax"">20</a>] or URN [<a href="#ref-13" title=""URN Syntax"">13</a>],
and that are also legal in XML [<a href="#ref-32" title=""Extensible Markup Language (XML) 1.0 (2nd ed)"">32</a>] element names.
Thus, for maximum flexibility, header field names SHOULD further be
restricted to just letters, digits, hyphen ('-') and underscore ('_')
characters, with the first character being a letter or underscore.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Registration Templates</span>
The registration template for a message header field may be contained
in the defining document, or prepared separately.
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Permanent Message Header Field Registration Template</span>
A header registered in the Permanent Message Header Field Registry
MUST be published as an RFC or as an "Open Standard" in the sense
described by <a href="./rfc2026#section-7">RFC 2026, section 7</a> [<a href="#ref-1" title=""The Internet Standards Process -- Revision 3"">1</a>], and MUST have a name which is
unique among all the registered permanent field names that may be
used with the same application protocol.
The registration template has the following form.
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
Header field name:
The name requested for the new header field. This MUST conform to
the header field specification details noted in <a href="#section-4.1">Section 4.1</a>.
<span class="grey">Klyne, et al. Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
Applicable protocol:
Specify "mail" (<a href="./rfc2822">RFC 2822</a>), "mime" (<a href="./rfc2045">RFC 2045</a>), "http" (<a href="./rfc2616">RFC 2616</a>),
"netnews" (<a href="./rfc1036">RFC 1036</a>), or cite any other standards-track RFC
defining the protocol with which the header is intended to be
used.
Status:
Specify "standard", "experimental", "informational", "historic",
"obsoleted", or some other appropriate value according to the type
and status of the primary document in which it is defined. For
non-IETF specifications, those formally approved by other
standards bodies should be labelled as "standard"; others may be
"informational" or "deprecated" depending on the reason for
registration.
Author/Change controller:
For Internet standards-track, state "IETF". For other open
standards, give the name of the publishing body (e.g., ANSI, ISO,
ITU, W3C, etc.). For other specifications, give the name, email
address, and organization name of the primary specification
author. A postal address, home page URI, telephone and fax
numbers may also be included.
Specification document(s):
Reference to document that specifies the header for use with the
indicated protocol, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant
sections MAY also be included, but is not required.
Related information:
Optionally, citations to additional documents containing further
relevant information. (This part of the registry may also be used
for IESG comments.) Where a primary specification refers to
another document for substantial technical detail, the referenced
document is usefully mentioned here.
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. Provisional Message Header Field Submission Template</span>
Registration as a Provisional Message Header Field does not imply any
kind of endorsement by the IETF, IANA or any other body.
The main requirements for a header field to be included in the
provisional repository are that it MUST have a citable specification,
and there MUST NOT be a corresponding entry (with same field name and
protocol) in the permanent header field registry.
<span class="grey">Klyne, et al. Best Current Practice [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
The specification SHOULD indicate an email address for sending
technical comments and discussion of the proposed message header.
The submission template has the following form.
PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:
Header field name:
The name proposed for the new header field. This SHOULD conform
to the field name specification details noted in <a href="#section-4.1">Section 4.1</a>.
Applicable protocol:
Specify "mail" (<a href="./rfc2822">RFC 2822</a>), "mime" (<a href="./rfc2045">RFC 2045</a>), "http" (<a href="./rfc2616">RFC 2616</a>),
"netnews" (<a href="./rfc1036">RFC 1036</a>), or cite any other standards-track RFC
defining the protocol with which the header is intended to be
used.
Status:
Specify: "provisional". This will be updated if and when the
header registration is subsequently moved to the permanent
registry.
Author/Change controller:
The name, email address, and organization name of the submission
author, who may authorize changes to or retraction of the
repository entry. A postal address, home page URI, telephone and
fax numbers may also be included.
If the proposal comes from a standards body working group, give
the name and home page URI of the working group, and an email
address for discussion of or comments on the specification.
Specification document(s):
Reference to document that specifies the header for use with the
indicated protocol. The document MUST be an RFC, a current
Internet-draft or the URL of a publicly accessible document (so
IANA can verify availability of the specification). An indication
of the relevant sections MAY also be included, but is not
required.
NOTE: if the specification is available in printed form only,
then an Internet draft containing full reference to the paper
document should be published and cited in the registration
template. The paper specification MAY be cited under related
information.
Related information:
Optionally, citations to additional documents containing further
relevant information.
<span class="grey">Klyne, et al. Best Current Practice [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Submission of Registration</span>
The registration template is submitted for incorporation in one of
the IANA message header field repositories by one of the following
methods:
o An IANA considerations section in a defining RFC, calling for
registration of the message header and referencing information as
required by the registration template within the same document.
Registration of the header is then processed as part of the RFC
publication process.
o Send a copy of the template to the designated email discussion
list [<a href="#ref-33" title=""Mail address for announcement of new header field submissions"">33</a>] [<a href="#ref-34" title=""Mail address for subscription to ietf-message- headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO THE MAILING LIST ITSELF)"">34</a>]. Allow a reasonable period - at least 2 weeks -
for discussion and comments, then send the template to IANA at the
designated email address [<a href="#ref-35" title=""Mail address for submission of new header field templates"">35</a>]. IANA will publish the template
information if the requested name and the specification document
meet the criteria noted in <a href="#section-4.1">Section 4.1</a> and <a href="#section-4.2.2">Section 4.2.2</a>, unless
the IESG or their designated expert have requested that it not be
published (see <a href="#section-4.4">Section 4.4</a>). IESG's designated expert should
confirm to IANA that the registration criteria have been
satisfied.
When a new entry is recorded in the permanent message header field
registry, IANA will remove any corresponding entries (with the same
field name and protocol) from the provisional registry.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Objections to Registration</span>
Listing of an entry in the provisional repository should not be
lightly refused. An entry MAY be refused if there is some credible
reason to believe that such registration will be harmful. In the
absence of such objection, IANA SHOULD allow any registration that
meets the criteria set out in <a href="#section-4.1">Section 4.1</a> and <a href="#section-4.2.2">Section 4.2.2</a>. Some
reasonable grounds for refusal might be:
o There is IETF consensus that publication is considered likely to
harm the Internet technical infrastructure in some way.
o Disreputable or frivolous use of the registration facilities.
o The proposal is sufficiently lacking in purpose, or misleading
about its purpose, that it can be held to be a waste of time and
effort.
o Conflict with some current IETF activity.
<span class="grey">Klyne, et al. Best Current Practice [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
Note that objections or disagreements about technical detail are not,
of themselves, considered grounds to refuse listing in the
provisional repository. After all, one of its purposes is to allow
developers to communicate with a view to combining their ideas,
expertise and energy to the maximum benefit of the Internet
community.
Publication in an RFC or other form of Open Standard document (per
<a href="./rfc2026">RFC 2026</a> [<a href="#ref-1" title=""The Internet Standards Process -- Revision 3"">1</a>], section 7) is sufficient grounds for publication in the
permanent registry.
To assist IANA in determining whether or not there is a sustainable
objection to any registration, IESG nominates a designated expert to
liaise with IANA about new registrations. For the most part, the
designated expert's role is to confirm to IANA that the registration
criteria have been satisfied.
The IESG or their designated expert MAY require any change or
commentary to be attached to any registry entry.
The IESG is the final arbiter of any objection.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Change Control</span>
Change control of a header field registration is subject to the same
condition as the initial registration; i.e., publication (or
reclassification) of an Open Standards specification for a Permanent
Message Header Field, or on request of the indicated author/change
controller for a Provisional Message Header (like the original
submission, subject to review on the designated email discussion list
[<a href="#ref-33" title=""Mail address for announcement of new header field submissions"">33</a>].)
A change to a permanent message header field registration MAY be
requested by the IESG.
A change to or retraction of any Provisional Message Header Field
Repository entry MAY be requested by the IESG or designated expert.
IANA MAY remove any Provisional Message Header Field Repository entry
whose corresponding specification document is no longer available
(e.g., expired Internet-draft, or URL not resolvable). Anyone may
notify IANA of any such cases by sending an email to the designated
email address [<a href="#ref-35" title=""Mail address for submission of new header field templates"">35</a>]. Before removing an entry for this reason, IANA
SHOULD contact the registered Author/Change controller to determine
whether a replacement for the specification document (consistent with
the requirements of section <a href="#section-4.2.2">Section 4.2.2</a>) is available.
<span class="grey">Klyne, et al. Best Current Practice [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
It is intended that entries in the Permanent Message Header Field
Registry may be used in the construction of URNs (per <a href="./rfc2141">RFC 2141</a> [<a href="#ref-13" title=""URN Syntax"">13</a>])
which have particular requirements for uniqueness and persistence
(per <a href="./rfc1737">RFC 1737</a> [<a href="#ref-8" title=""Functional Requirements for Uniform Resource Names"">8</a>]). Therefore, once an entry is made in the
Permanent Message Header Registry, the combination of the header name
and applicable protocol MUST NOT subsequently be registered for any
other purpose. (This is not to preclude revision of the applicable
specification(s) within the appropriate IETF Consensus rules, and
corresponding updates to the specification citation in the header
registration.)
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Comments on Header Definitions</span>
Comments on proposed registrations should be sent to the designated
email discussion list [<a href="#ref-33" title=""Mail address for announcement of new header field submissions"">33</a>].
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. Location of Header Field Registry</span>
The message header field registry is accessible from IANA's web site
<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/</a>
<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">message-header-index.html</a>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This specification calls for:
o A new IANA registry for permanent message header fields per
<a href="#section-4">Section 4</a> of this document. The policy for inclusion in this
registry is described in <a href="#section-4.1">Section 4.1</a> and <a href="#section-4.2.1">Section 4.2.1</a>.
o A new IANA repository listing provisional message header fields
per <a href="#section-4">Section 4</a> of this document. The policy for inclusion in this
registry is described in <a href="#section-4.1">Section 4.1</a> and <a href="#section-4.2.2">Section 4.2.2</a>.
o IESG appoints a designated expert to advise IANA whether
registration criteria for proposed registrations have been
satisfied.
No initial registry entries are provided.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
No security considerations are introduced by this specification
beyond those already inherent in the use of message headers.
<span class="grey">Klyne, et al. Best Current Practice [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The shape of the registries described here owes much to energetic
discussion of previous versions by many denizens of the IETF-822
mailing list.
The authors also gratefully acknowledge the contribution of those who
provided valuable feedback on earlier versions of this memo: Charles
Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle
Cotton.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "The Internet Standards Process -- Revision 3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp9">9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.
[<a id="ref-2">2</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-3">3</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>, October 1998.
[<a id="ref-4">4</a>] Resnick, P., Ed., "Internet Message Format", <a href="./rfc2822">RFC 2822</a>, April
2001.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-5">5</a>] Horton, M. and R. Adams, "Standard for interchange of USENET
messages", <a href="./rfc1036">RFC 1036</a>, December 1987.
[<a id="ref-6">6</a>] Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for
downgrading messages from X.400/88 to X.400/84 when MIME
content-types are present in the messages", <a href="./rfc1496">RFC 1496</a>, August
1993.
[<a id="ref-7">7</a>] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header
Field for Internet Messages", <a href="./rfc1505">RFC 1505</a>, August 1993.
[<a id="ref-8">8</a>] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", <a href="./rfc1737">RFC 1737</a>, December 1994.
[<a id="ref-9">9</a>] Myers, J. and M. Rose, "The Content-MD5 Header Field", <a href="./rfc1864">RFC 1864</a>,
October 1995.
[<a id="ref-10">10</a>] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", <a href="./rfc1945">RFC 1945</a>, May 1996.
<span class="grey">Klyne, et al. Best Current Practice [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
[<a id="ref-11">11</a>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
<a href="./rfc2045">RFC 2045</a>, November 1996.
[<a id="ref-12">12</a>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", <a href="./rfc2046">RFC 2046</a>, November
1996.
[<a id="ref-13">13</a>] Moats, R., "URN Syntax", <a href="./rfc2141">RFC 2141</a>, May 1997.
[<a id="ref-14">14</a>] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and <a href="./rfc822">RFC 822</a>/MIME", <a href="./rfc2156">RFC 2156</a>, January 1998.
[<a id="ref-15">15</a>] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", <a href="./rfc2183">RFC 2183</a>, August 1997.
[<a id="ref-16">16</a>] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting
for HTTP", <a href="./rfc2227">RFC 2227</a>, October 1997.
[<a id="ref-17">17</a>] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", <a href="./rfc2231">RFC</a>
<a href="./rfc2231">2231</a>, November 1997.
[<a id="ref-18">18</a>] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition
Notification", <a href="./rfc3798">RFC 3798</a>, May 2004.
[<a id="ref-19">19</a>] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for
Core Mail List Commands and their Transport through Message
Header Fields", <a href="./rfc2369">RFC 2369</a>, July 1998.
[<a id="ref-20">20</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", <a href="./rfc2396">RFC 2396</a>, August
1998.
[<a id="ref-21">21</a>] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
version 2 (VPIMv2)", <a href="./rfc3801">RFC 3801</a>, June 2004.
[<a id="ref-22">22</a>] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen,
"HTTP Extensions for Distributed Authoring -- WEBDAV", <a href="./rfc2518">RFC 2518</a>,
February 1999.
[<a id="ref-23">23</a>] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME
Encapsulation of Aggregate Documents, such as HTML (MHTML)", <a href="./rfc2557">RFC</a>
<a href="./rfc2557">2557</a>, March 1999.
<span class="grey">Klyne, et al. Best Current Practice [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
[<a id="ref-24">24</a>] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
[<a id="ref-25">25</a>] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", <a href="./rfc2617">RFC 2617</a>, June 1999.
[<a id="ref-26">26</a>] Klensin, J., Ed., "Simple Mail Transfer Protocol", <a href="./rfc2821">RFC 2821</a>,
April 2001.
[<a id="ref-27">27</a>] Klyne, G., "Indicating Media Features for MIME Content", <a href="./rfc2912">RFC</a>
<a href="./rfc2912">2912</a>, September 2000.
[<a id="ref-28">28</a>] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
Namespace for the Identification of Mailing Lists", <a href="./rfc2919">RFC 2919</a>,
March 2001.
[<a id="ref-29">29</a>] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
<a href="./rfc2965">RFC 2965</a>, October 2000.
[<a id="ref-30">30</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
[<a id="ref-31">31</a>] Alvestrand, H., "Content Language Headers", <a href="./rfc3282">RFC 3282</a>, May 2002.
[<a id="ref-32">32</a>] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
Recommendation xml, October 2000,
<<a href="http://www.w3.org/TR/2000/REC-xml-20001006">http://www.w3.org/TR/2000/REC-xml-20001006</a>>.
[<a id="ref-33">33</a>] "Mail address for announcement of new header field submissions",
Mail address: ietf-message-headers@lists.ietf.org
[<a id="ref-34">34</a>] "Mail address for subscription to ietf-message-
headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO
THE MAILING LIST ITSELF)", Mail address: ietf-message-headers-
request@lists.ietf.org
[<a id="ref-35">35</a>] "Mail address for submission of new header field templates",
Mail address: iana@iana.org
<span class="grey">Klyne, et al. Best Current Practice [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Authors' Addresses</span>
Graham Klyne
Nine by Nine
EMail: GK-IETF@ninebynine.org
URI: <a href="http://www.ninebynine.net/">http://www.ninebynine.net/</a>
Mark Nottingham
BEA Systems
235 Montgomery St.
Level 15
San Francisco, CA 94104
USA
EMail: mnot@pobox.com
Jeffrey C. Mogul
HP Labs
1501 Page Mill Road
Palo Alto, CA 94304
US
EMail: JeffMogul@acm.org
<span class="grey">Klyne, et al. Best Current Practice [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3864">RFC 3864</a> Header Field Registration September 2004</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Klyne, et al. Best Current Practice [Page 17]
</pre>
|
