datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Registration Procedures for Message Header Fields
RFC 3864

Document type: RFC - Best Current Practice (September 2004)
Also Known As BCP 90
Was draft-klyne-msghdr-registry (individual in app area)
Document stream: IETF
Last updated: 2013-11-01
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3864 (Best Current Practice)
Responsible AD: Ned Freed
Send notices to: <JeffMogul@acm.org>, <mnot@mnot.net>, <GK-IETF@ninebynine.org>

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

           Registration Procedures for Message Header Fields

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.

Klyne, et al.            Best Current Practice                  [Page 1]
RFC 3864               Header Field Registration          September 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Structure of this Document . . . . . . . . . . . . . . .  3
       1.2.  Document Terminology and Conventions . . . . . . . . . .  4
   2.  Message Header Fields. . . . . . . . . . . . . . . . . . . . .  4
       2.1.  Permanent and Provisional Header Fields. . . . . . . . .  4
       2.2.  Definitions of Message Header Fields . . . . . . . . . .  5
             2.2.1. Application-specific Message Header Fields. . . .  5
             2.2.2. MIME Header Fields. . . . . . . . . . . . . . . .  6
   3.  Registry Usage Requirements. . . . . . . . . . . . . . . . . .  6
   4.  Registration Procedure . . . . . . . . . . . . . . . . . . . .  6
       4.1.  Header Field Specification . . . . . . . . . . . . . . .  7
       4.2.  Registration Templates . . . . . . . . . . . . . . . . .  7
             4.2.1. Permanent Message Header Field Registration
                    Template. . . . . . . . . . . . . . . . . . . . .  7
             4.2.2. Provisional Message Header Field Submission
                    Template. . . . . . . . . . . . . . . . . . . . .  8
       4.3.  Submission of Registration . . . . . . . . . . . . . . . 10
       4.4.  Objections to Registration . . . . . . . . . . . . . . . 10
       4.5.  Change Control . . . . . . . . . . . . . . . . . . . . . 11
       4.6.  Comments on Header Definitions . . . . . . . . . . . . . 12
       4.7.  Location of Header Field Registry. . . . . . . . . . . . 12
   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 13
       8.2.  Informative References . . . . . . . . . . . . . . . . . 13
   9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
   10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17

1.  Introduction

   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 [30].

   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;

Klyne, et al.            Best Current Practice                  [Page 2]
RFC 3864               Header Field Registration          September 2004

   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, RFC 2822 [4].
   HTTP/1.0 [10] and HTTP/1.1 [24] define message header fields
   (respectively, the HTTP-header and message-header protocol elements)
   for use with HTTP.  RFC 1036 [5] defines message header elements for
   use with Netnews feeds.  These specifications also define a number of

[include full document text]