Based on recent discussion and several recent drafts, there seem
to be a number of relevant issues that are often overlooked when
a new message field is proposed. For future reference, here is a
suggested list of items that should be addressed by any message
field proposal:
1. Utility of the field; what purpose does it serve, and to whom.
How is it envisioned that the field will be used?
2. Semantics of the field; what does it mean?
3. Syntax of the field (using RFC 2234/2822 grammar).
3a. If the field syntax uses any keywords, what keyword values
are defined, what mechanisms are specified for registering
additional keywords, what provisions are made for testing
and experimental use, etc.
4. Minimum and maximum number of instances of the field
permitted per header, per message or per report section.
5. Permitted and/or required context for the field. Is it
permitted or required in message headers, in MIME-part
headers, as a per-message field in one or more
multipart/report report types, as a per-recipient field in
a multipart/report report type, etc. Are there any specific
conditions that affect whether or not the field may/must
be included?
6. Do any existing mechanisms require amendment to
address handling of the proposed field? Examples include
message/partial fragmentation and reassembly,
handling by gateways, and processing by MSAs.
7. How does the field fit into the overall message format;
is the field a trace field, an address field, etc.?
8. Is a Resent- version of the field applicable?
9. Is the field or any portions considered experimental in
the sense of RFC 3692 (viz. requiring specific configuration
to enable use)?
Can anybody think of additional considerations (other than
the obvious ones which are required in all RFCs (security
considerations, IP disclosure, etc.))?