idnits 2.17.1 draft-ietf-drums-MHRegistry-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-drums-MHRegistry-03', contains other characters than digits, lowercase letters and dash. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 850 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 578 has weird spacing: '...ecurity sta...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9385 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 507, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 530, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 534, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 538, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 542, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 548, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 551, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 555, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 561, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 565, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 568, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 573, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 577, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 581, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 584, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 591, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 596, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 599, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 607, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 612, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 616, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1036 (ref. '3') (Obsoleted by RFC 5536, RFC 5537) ** Downref: Normative reference to an Historic RFC: RFC 1049 (ref. '4') ** Obsolete normative reference: RFC 1154 (ref. '6') (Obsoleted by RFC 1505) ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1496 (ref. '8') -- Duplicate reference: RFC1154, mentioned in '9', was also mentioned in '6'. ** Obsolete normative reference: RFC 1154 (ref. '9') (Obsoleted by RFC 1505) ** Downref: Normative reference to an Experimental RFC: RFC 1505 (ref. '10') ** Obsolete normative reference: RFC 1521 (ref. '11') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1766 (ref. '12') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 1806 (ref. '14') (Obsoleted by RFC 2183) ** Obsolete normative reference: RFC 977 (ref. '15') (Obsoleted by RFC 3977) ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. '16') ** Downref: Normative reference to an Unknown state RFC: RFC 976 (ref. '18') ** Obsolete normative reference: RFC 2068 (ref. '19') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 1911 (ref. '20') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) -- Duplicate reference: RFC1036, mentioned in '21', was also mentioned in '3'. ** Obsolete normative reference: RFC 1036 (ref. '21') (Obsoleted by RFC 5536, RFC 5537) -- Unexpected draft version: The latest known version of draft-ietf-mailext-mail-attributes is -06, but you're referring to -07. ** Downref: Normative reference to an Informational draft: draft-ietf-mailext-mail-attributes (ref. '22') -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' Summary: 27 errors (**), 0 flaws (~~), 27 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jacob Palme 2 Internet Draft Stockholm University/KTH, Sweden 3 draft-ietf-drums-MHRegistry-03.txt January 1998 4 Category-to-be: Informational Expires August 1998 6 Mail and Netnews Header field Registration Procedure 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. 28 This memo does not specify an Internet standard of any kind. 29 Distribution of this memo is unlimited. 31 Copyright (C) The Internet Society 1998. All Rights Reserved. 33 Abstract 35 Various IETF standards and http, e-mail and netnews software 36 products use various http, e-mail and netnews header fields. This 37 document specifies a procedure for the registration of http, 38 e-mail and netnews header field names, to reduce the risk that two 39 different products use the same header field name in different 40 ways (homonyms) or that several different header field names are 41 used with identical meaning (synonyms). 43 Changes from version 02 of this draft 45 Also http header fieldss are now included in the registry, not as 46 before only e-mail and netnews header fields. 48 Added text that also fields from Internet drafts can be registered 49 on a temporary basis, such registration expires with the Internet 50 draft: 52 3.1 Registration of headers from Internet drafts 54 Headers in Internet drafts can be registered on a temporary 55 basis, so that the header registry can be used to find also 56 such headers. If the IETF draft expires, such headers must 57 either be removed from the registry, or changed to reflect 58 their new status (as an IETF standard or as a non-standard 59 documented separately from IETF). 61 Expiration month: (For a header field from an Internet draft, 62 this must be the expiration date of the draft. After this 63 time, the registration must either be removed or changed. The 64 word "unlimited" can be used for fields without an expiration 65 month.) 67 Changed paragraph about "X-" headers: 69 Because of this, an IANA registry for http, e-mail and 70 Netnews header field names is needed. This registry can 71 contain header fields starting with "X-", even though such 72 header fields cannot be specified in IETF standards. The 73 registry can also contain header fields not starting with 74 "X-", even though such fields are not part of IETF standards. 75 There is no promise that such non-standard field names, not 76 starting with "X-", will not be used in future standards, but 77 normally future standards can be expected not to use field 78 names from the header registry in ways which are incompatible 79 with existing usage of such fields as specified in the 80 registry. 82 Added text that the IESG can change any header registration. 84 Minor changes to registered headers, which will not cause 85 problems for those who have already implemented the header, 86 can be done by the person or organisation who has change 87 control for the header. This person or organisation can also 88 add to the register advance notice about future changes under 89 development. The IESG additionally has the right to modify an 90 header field registration, even without permission from the 91 change controller. This right for the IESG should of course 92 be used with great caution. 94 The name of the mailing list has been changed from "mail-headers" 95 to "message-headers" to allow also http and netnews header fields. 97 Table of contents 99 1. Introduction 100 2. Which Header fields are Registered 101 3. Who can Register a Header field Name 102 3.1 Registration of headers from Internet drafts 103 4. Registration Procedure 104 4.1 Registration Template 105 4.2 Present the Request for Registration to the 106 Community 107 4.3 Submit the Header field name to the IANA for 108 Registration 109 4.4 Changes to registered headers 110 5. Clarifications On Specific Issues 111 5.1 Requirements for a Limited Number of Header 112 Fields 113 5.2 Header field Status 114 5.3 Requirements for a Published Specification 115 5.4 Identification of Security Considerations 116 5.5 Recommendations and Standards Status 117 6. Security Considerations 118 7. Acknowledgments 119 8. Copyright 120 9. References 121 10. Author's address 122 11. Appendix: Examples of the publication format of the 123 header registry 124 11.1 Header registry when published as plain 125 formatted text 126 11.2 Header registry when published in HTML format 127 11.3 Header registry when published as a 128 tab-separated table 130 1. Introduction 132 Many different Internet standards, other RFCs and http, e-mail and 133 netnews software products define header fields which may occur on 134 http headings, Internet mail headings and/or Netnews headings. 135 There is an obvious risk for 137 Honomyns: The same header field name is used in different ways by 138 different software products. 140 Synonyms: Several different header fields for exactly the same 141 use. 143 The solution, to allow header field names beginning with "X-" for 144 non-standard header field names has several drawbacks. One is that 145 it does not preclude two different products using the same "X-" 146 header field name with different semantic meaning. Another is that 147 if an "X-" header field gets popular and much used, and is to 148 become a standard, there is a problem with removing the "X-" in 149 front of an already much used header field. 151 Because of this, an IANA registry for http, e-mail and Netnews 152 header field names is needed. This registry can contain header 153 fields starting with "X-", even though such header fields cannot 154 be specified in IETF standards. The registry can also contain 155 header fields not starting with "X-", even though such fields are 156 not part of IETF standards. There is no promise that such 157 non-standard field names, not starting with "X-", will not be used 158 in future standards, but normally future standards can be expected 159 not to use field names from the header registry in ways which are 160 incompatible with existing usage of such fields as specified in 161 the registry. 163 The following words are used in this memo with the meaning 164 specified below: 166 heading Formatted text at the top of a message, ended 167 by CRLFCRLF 169 header field One field in the heading, beginning with a 170 header field name, colon, and followed by the 171 field value(s). Other words sometimes used 172 for this is "header" or "heading field". 174 2. Which Header fields are Registered 176 The header field name registry can contain header fields from the 177 following sources: 179 - Internet standards 180 - RFCs which are not Internet standards 181 - Non-Internet standards 182 - Other commonly used header fields 183 - Headers implemented in new products 184 - Sometimes used header fields whose use is discouraged. The use 185 of a header field name may be discouraged because it is badly 186 defined, ambigous or used in different ways by different 187 software. The purpose of registering discouraged header fields 188 is to avoid their use in their present or any other future 189 semantic meaning. 191 The registry can contain header fields used in e-mail message 192 headings, MIME content headings, http headings and Netnews article 193 headings. 195 3. Who can Register a Header field Name 197 Header field names from Internet standards are registered (or the 198 registration modified) by IETF together with the standard 199 specifying the header field. 201 Header fields in other RFCs are registered (or the registration 202 modified) when the RFCs are published. 204 Anyone can propose the registry of additional header fields, but 205 such header fields should be approved by the IETF application area 206 managers before accepted in the registry. This approval should be 207 given if the header field seems reasonable and not in conflict 208 with current usage or other header fields in ways which might 209 cause problem. It is not necessary for approval that the area 210 manager likes the header field or wants it to be progressed into 211 an IETF standard. The procedure described in this memo is followed 212 by the IANA for review and approval of new http, e-mail and 213 netnews header fields. This is not a formal standards process, but 214 rather an administrative procedure intended to allow community 215 comment and sanity checking without excessive time delay. 217 3.1 Registration of headers from Internet drafts 219 Headers in Internet drafts can be registered on a temporary basis, 220 so that the header registry can be used to find also such headers. 221 If the IETF draft expires, such headers must either be removed 222 from the registry, or changed to reflect their new status (as an 223 IETF standard or as a non-standard documented separately from 224 IETF). 226 4. Registration Procedure 228 4.1 Registration Template 230 To: message-headers@segate.sunet.se 231 Subject: Registration of header field: XXX 233 Header field name: 235 Header field status (choices, see section 236 5.2 Header field Status below) 238 Applicability: 239 (One of COMMON, LIMITED USE or OBSOLETE) 241 What is the header field used for: 243 Who can set or modify the header field: 245 Protocols which use this header field: 246 (One or more of E-MAIL MESSAGE HEADING, 247 E-MAIL CONTENT HEADING, HTTP HEADING, 248 USENET NEWS HEADING) 250 Application programs which use this header field: 252 Encoding considerations: 254 Security considerations: 256 Interoperability considerations: 258 Published specification: 260 Person & email address to contact for further information: 262 Author/Change controller: 264 Expiration month: (For a header field from an Internet draft, 265 this must be the expiration date of the draft. After this 266 time, the registration must either be removed or changed. The 267 word "unlimited" can be used for fields without an expiration 268 month.) 270 (Any other information that the author deems interesting may 271 be added below this line.) 273 4.2 Present the Request for Registration to the Community 275 Send a proposed header field to the 276 "message-headers@segate.sunet.se" mailing list. This mailing list 277 has been established for the sole purpose of reviewing proposed 278 e-mail, netnews and http header fields. You can subscribe to the 279 list by sending a message to "listserv@segate.sunet.se" containing 280 in the text a line with 281 "subscribe message-headers " followed by your name (not your 282 e-mail address), and unsubscribe with a message "unsubscribe 283 message-headers". You can also subscribe through the WWW to 284 http://segate.sunet.se/archives/message-headers.html 286 Archives of this list are available 287 by anonymous FTP from 288 ftp://segate.sunet.se/lists/message-headers/ 290 by HTTP from 291 http://segate.sunet.se/archives/message-headers.html 293 by E-MAIL 294 send a message to 295 LISTSERV@SEGATE.SUNET.SE with the text "INDEX message-headers" 296 to get a list of the archive files, and then a new message 297 "GET " to retrieve the archive files. 299 The FTP and E-MAIL archives are best if you want to retrieve all 300 messages during a month or more, while the HTTP archives are 301 better if you want to browse and find particular messages to 302 download. 304 The intent of the public posting is to solicit comments and 305 feedback on the choice of header field name, the unambiguity of 306 the references with respect to versions and external profiling 307 information, the choice of which OIDs to use, and a review of the 308 security considerations section. It should be noted that the 309 proposed header field name does not need to make sense for every 310 possible application. If the header field name is intended for a 311 limited or specific use, this should be noted in the submission. 313 4.3 Submit the Header field name to the IANA for Registration 315 After at least two weeks, submit the proposed header field to the 316 IANA for registration. The request and supporting documentation 317 should be sent to "iana@isi.edu". IANA will ask the application 318 area directors for approval. If approved, IANA will register the 319 header field, assign an OID under the IANA branch, and make the 320 header field registration available to the community. 322 IANA should keep a data base of registered header fields. IANA 323 should regularly publish the contents of this data base in the 324 following formats, which can be generated automatically from the 325 data base: 327 (1) In plain formatted ASCII text as shown in section 11.1. 329 (2) In HTML format as shown in section 11.2. 331 (3) As ASCII text with HTAB between fields and CRLF between lines 332 as shown in section 11.3. 334 Format (1) and (2) are good for human reading, format (3) is good 335 for input to a data base. 337 The header field will be listed in the periodically issued 338 "Assigned Numbers" RFC [2]. The header field description may be 339 published as an Informational RFC by sending it to 340 "rfc-editor@isi.edu" (please follow the instructions to RFC 341 authors [3]). 343 4.4 Changes to registered headers 345 Minor changes to registered headers, which will not cause problems 346 for those who have already implemented the header, can be done by 347 the person or organisation who has change control for the header. 348 This person or organisation can also add to the register advance 349 notice about future changes under development. The IESG 350 additionally has the right to modify an header field registration, 351 even without permission from the change controller. This right for 352 the IESG should of course be used with great caution. 354 Changes made by an revised version of an IETF standard should be 355 made at the same time as the publication of the revised standard. 357 Other changes require the same approval procedure as for 358 registration of new headers. 360 5. Clarifications On Specific Issues 362 5.1 Requirements for a Limited Number of Header Fields 364 Issue: In the asynchronous mail environment, where information on 365 the capabilities of the remote mail agent is not available to the 366 sender, maximum interoperability is attained by restricting the 367 number of header fields used to those "common" header fields 368 expected to be widely implemented. This was asserted as a reason 369 to limit the number of possible header fields and resulted in a 370 registration process with a significant hurdle and delay for those 371 registering header fields. 373 5.2 Header field Status 375 Any header field in the registry should be marked with a status, 376 which has one of the values specified below: 378 IETF standard Specified in an IETF standard. 380 IETF draft standard Specified in an IETF draft standard. 382 IETF proposed Specified in an IETF proposed standard. 383 standard 385 IETF experimental Specified in an IETF experimental 386 standard standard. 388 Internet draft Header from an Internet draft. If/when 389 the Internet draft expires, the header 390 registry must be changed to indicate its 391 new defining document, for example an 392 IETF standard. 394 X.400. Used to mark header fields which are 395 defined in RFC 1327 and other standards 396 for use in messages from or to Internet 397 mail/X.400 gateways, and which have not 398 been standardized for general usage in 399 the exchange of messages between 400 Internet mail-based systems. 402 Other standard Defined in standard developed by another 403 standards making body than IETF. 405 Non-standard This header field is not specified in 406 any of the RFCs which define Internet 407 protocols, including Internet Standards, 408 Draft Standards, Proposed Standards and 409 Experimental Standards. The header field 410 appears here because it sometimes 411 appears in http, e-mail or Netnews. 412 Usage of these header fields is not in 413 general recommended. Some header field 414 proposed in ongoing IETF standards 415 development work, but not yet accepted, 416 are also marked in this way. 418 discouraged This header field, which is non-standard 419 or historical, is known to create 420 problems and should not be generated. 421 Handling of such header fields in 422 incoming mail should be done with great 423 caution. 425 controversial The meaning and usage of this header 426 field is controversial, i.e. different 427 implementors have chosen to implement 428 the header field in different ways. 429 Because of this, such header fields 430 should be handled with caution and 431 understanding of the different possible 432 interpretations. 434 5.3 Requirements for a Published Specification 436 If header fields registered are specified in a separate document, 437 this document should be published as an RFC. Other specifications 438 can in some cases also be accepted if they are publicly available 439 on the Internet. 441 The information specified in section 4.1 Registration Template 442 above should be provided. 444 5.4 Identification of Security Considerations 446 The registration process requires the identification of any known 447 security problems with the header field name. 449 It is not required that the header field be secure or that it be 450 free from risks, but that the known risks be identified. 451 Publication of a header field name does not require an exhaustive 452 security review. 454 5.5 Recommendations and Standards Status 456 Issue: The registration of a header field does not imply 457 endorsement, approval, or recommendation by IANA or IETF or even 458 certification that the specification is adequate. 460 6. Security Considerations 462 This memo does not address specific security issues but outlines a 463 security review process for header fields. 465 7. Acknowledgments 467 Harald Tveit Alvestrand, Ned Freed, Olle J�rnefors, Larry 468 Masinter, Keith Moore, Nick Smith and several other people have 469 helped in developing this document. I alone take responsibility 470 for any errors which may still be in it. 472 8. Copyright 474 "Copyright (C) The Internet Society (date). All Rights Reserved. 476 This document and translations of it may be copied and furnished 477 to others, and derivative works that comment on or otherwise 478 explain it or assist in its implmentation may be prepared, copied, 479 published and distributed, in whole or in part, without 480 restriction of any kind, provided that the above copyright notice 481 and this paragraph are included on all such copies and derivative 482 works. However, this document itself may not be modified in any 483 way, such as by removing the copyright notice or references to the 484 Internet Society or other Internet organizations, except as needed 485 for the purpose of developing Internet standards in which case the 486 procedures for copyrights defined in the Internet Standards 487 process must be followed, or as required to translate it into 488 languages other than English. 490 The limited permissions granted above are perpetual and will not 491 be revoked by the Internet Society or its successors or assigns. 493 This document and the information contained herein is provided on 494 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 495 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 496 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 497 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 498 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 499 PURPOSE." 501 9. References 503 Ref. Author, title IETF status 504 (July 1996) 505 ---- ------------------------------------------ ------------- 506 - 507 [1] J. Postel: "Simple Mail Transfer Standard, 508 Protocol", STD 10, RFC 821, August 1982. Recommended 510 [2] D. Crocker: "Standard for the format of Standard, 511 ARPA Internet text messages." STD 11, RFC Recommended 512 822, August 1982. 514 [3] M.R. Horton, R. Adams: "Standard for Not an 515 interchange of USENET messages", RFC 1036, offi-cial IETF 516 December 1987. standard, but 517 in reality a 518 de-facto 519 standard for 520 Netnews 522 [4] M. Sirbu: "A Content-Type header field for Standard, 523 internet messages", RFC 1049, March 1988. Recommended, 524 but can in the 525 future be 526 expected to be 527 replaced by 528 MIME 530 [5] R. Braden (editor): "Requirements for Standard, 531 Internet Hosts -- Application and Required 532 Support", STD-3, RFC 1123, October 1989. 534 [6] D. Robinson, R. Ullman: "Encoding Header Non-standard 535 field for Internet Messages", RFC 1154, 536 April 1990. 538 [7] S. Hardcastle-Kille: "Mapping between Proposed 539 X.400(1988) / ISO 10021 and RFC 822", RFC standard, 540 1327 May 1992. elective 542 [8] H. Alvestrand & J. Romaguera: "Rules for Proposed 543 Downgrading Messages from X.400/88 to standard, 544 X.400/84 When MIME Content-Types are elective 545 Present in the Messages", RFC 1496, August 546 1993. 548 [9] A. Costanzo: "Encoding Header field for Non-standard 549 Internet Messages", RFC 1154, April 1990. 551 [10] A. Costanzo, D. Robinson: "Encoding Header Experimental 552 field for Internet Messages", RFC 1505, 553 August 1993. 555 [11] N. Borenstein & N. Freed: "MIME Draft Standard, 556 (Multipurpose Internet Mail Extensions) elective 557 Part One: Mechanisms for Specifying and 558 Describing the Format of Internet Message 559 Bodies", RFC 1521, Sept 1993. 561 [12] H. Alvestrand: "Tags for the Proposed 562 Identification of Languages", RFC 1766, standard, 563 February 1995. elective 565 [13] J. Palme: "Electronic Mail", Artech House Non-standard 566 publishers, London-Boston January 1995. 568 [14] R. Troost, S. Dorner: "Communicating Experimental 569 Presentation Information in Internet 570 Messages: The Content-Disposition Header 571 field", RFC 1806, June 1995. 573 [15] B. Kantor, P. Lapsley, "Network News Proposed 574 Transfer Protocol: "A Proposed Standard standard 575 for the Stream-Based Transmission of 576 News", RFC 977, January 1986. 577 [16] 1848 PS S. Crocker, N. Freed, J. Proposed 578 Galvin, S. Murphy, "MIME Object Security standard 579 Services", RFC 1848, March 1995. 581 [17] J. Myers, M. Rose: The Content-MD5 Header Draft standard 582 field, RFC 1864, October 1995. 584 [18] M. Horton, UUCP mail interchange format Not an official 585 standard, RFC 976, Januari 1986. IETF standard, 586 but in reality 587 a de-facto 588 standard for 589 Netnews 591 [19] R. Fielding, J. Gettys, J. Mogul, H. Proposed 592 Frystyk. T. Berners-Lee: Hypertext standard 593 Transfer Protocol -- HTTP/1.1, RFC 2068, 594 January 1997. 596 [20] G. Vaudreuil: Voice Profile for Internet Experimental 597 Mail, RFC 1911, February 1996. 599 [21] H. Spencer: News Article Format and Not even an 600 Transmission, June 1994, RFC, but still 601 FTP://zoo.toronto.edu/pub/news.ps.Z widely used and 602 FTP://zoo.toronto.edu/pub/news.txt.Z partly almost a 603 de-facto 604 This document is often referenced under standard for 605 the name "son-of-RFC1036". Netnews 607 [22] J. Palme: Common Internet Message Header Informational 608 fields. 609 draft-ietf-mailext-mail-attributes-07.txt. 610 January 1997. 612 [23] PICS Label Distribution Label Syntax and Other standard 613 Communication Protocols, World Wide Web 614 Consortium, October 1996. 616 [24] Eudora Pro Macintosh User Manual, Qualcomm Non-standard 617 Inc., 1988-1995. 619 10. Author's address 621 Jacob Palme Phone: +46-8-16 16 67 622 Stockholm University/KTH Fax: +46-8-783 08 29 623 Electrum 230 E-mail: jpalme@dsv.su.se 624 S-164 40 Kista, Sweden 626 11. Appendix: Examples of the publication format of the header 627 registry 629 11.1 Header registry when published as plain formatted text 631 Header name: Content-Location: 632 Header status: IETF Proposed Standard 633 Applicability: COMMON 634 Use: Gives an URL corresponding to a content 635 part. The content part may, but need not, 636 be retrievable using this URL. Used when 637 sending HTML combined with related 638 objects as aggregate MIME objects. 639 Who can set or modify: Creator of aggregate MIME object 640 Protocols which use it: E-MAIL MESSAGE HEADING, E-MAIL CONTENT 641 HEADING, HTTP HEADING, USENET NEWS 642 HEADING 643 Applications which use Several e-mail clients and web browsers 644 it: 645 Encoding MIME (RFC 2047) and URLBODY (RFC 2017) 646 considerations: 647 Security Various, none serious. Can be avoided by 648 considerations: careful impelementation. See RFC 2110 for 649 details. 650 Interoperability Can interoperate with non-compliant 651 software, 652 considerations: body part will be provided without its 653 URL. 654 Published RFC 2110: MIME Encapsulation of Aggregate 655 specification: Documents, such as HTML (MHTML), March 656 1997. 657 Contact person: Jacob Palme and Alex 658 Hopmann 659 Change controller: IETF (MHTML working group), chair Einar 660 Stefferud 661 Other information: IETF is working on a revision of RFC 662 2110. See URL 663 http://www.dsv.su.se/~jpalme/ietf/ 664 mhtml.html for more information. 666 11.2 Header registry when published in HTML format 668 The HTML document below can also be found at URL 669 http://www.dsv.su.se/~jpalme/ietf/iana-header-field-registry.html 671

Header registry in HTML format

672

Table of contents

673

(Not yet complete) 674

675
  • Content-Base 676
  • Content-Conversion 677
  • Content-Description 678
  • Content-Disposition 679
  • Contetn-ID 680
  • Content-Identifier 681
  • Content-Language 682
  • Content-Length 683
  • Content-Location 684
  • Content-MD5 685
  • Content-Return 686
  • Content-SGML-Entity 687
  • Content-Transfer-Encoding 688
  • Content-Type 689
    • 690

    Content-Location

    691

    692 693 698 699 704 705 710 711 719 720 725 726 732 733 738 739 744 745 751 752 758 759 765 766 772 773 779 780 789
    694

    Header name: 695

    		696

    Content-Location: 697

    700

    Header status: 701

    		702

    IETF Proposed Standard 703

    706

    Applicability: 707

    		708

    COMMON 709

    712

    Use: 713

    		714

    Gives an URL corresponding to a content part. The 715 content part may, but need not, be retrievable using 716 this URL. Used when sending HTML combined with related 717 objects as aggregate MIME objects. 718

    721

    Who can set or modify: 722

    		723

    Creator of aggregate MIME object 724

    727

    Protocols which use it: 728

    		729

    E-MAIL MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP 730 HEADING, USENET NEWS HEADING 731

    734

    Applications which use it: 735

    		736

    Several e-mail clients and web browsers 737

    740

    Encoding considerations: 741

    		742

    MIME (RFC 2047) and URLBODY (RFC 2017) 743

    746

    Security considerations: 747

    		748

    Various, none serious. Can be avoided by careful 749 impelementation. See RFC 2110 for details. 750

    753

    Interoperability considerations: 754

    		755

    Can interoperate with non-compliant software, body 756 part will be provided without its URL. 757

    760

    Published specification: 761

    		762

    RFC 2110: MIME Encapsulation of Aggregate Documents, 763 such as HTML (MHTML), March 1997. 764

    767

    Contact person: 768

    		769

    Jacob Palme <jpalme@dsv.su.se> and Alex Hopmann 770 <alexhop@microsoft.com> 771

    774

    Change controller: 775

    		776

    IETF (MHTML working group), chair Einar Stefferud 777 <stef@nma.com> 778

    781

    Other information: 782

    		783

    IETF is working on a revision of RFC 2110. See URL 784 786 http://www.dsv.su.se/~jpalme/ietf/mhtml.html 787 for more information. 788

    791 11.3 Header registry when published as a tab-separated table 793 To agree with the allowed formats for RFCs, the section below is 794 encoded with the quoted-printable encoding method. This means that 795 the Horizontal Tab (HT) character is replaced by the string "=09" 796 and that all occurences of "=" followed by End-Of-Line should be 797 deleted from the text below to get the actual format. The IANA 798 published document should *not* be encoded with quoted-printable. 800 Header name:=09Header status:=09Applicability:=09Use:=09Who = 801 can set or modify:=09Protocols which use it:=09Applications = 802 which use it:=09Encoding considerations:=09Security = 803 considerations:=09Interoperability considerations:= 804 =09Published specification:=09Contact person:=09Change = 805 controller:=09Other information: 806 Content-Location:=09IETF Proposed Standard=09COMMON=09Gives an= 807 URL corresponding to a content part. The content part may,= 808 but need not, be retrievable using this URL. Used when= 809 sending HTML combined with related objects as aggregate= 810 MIME objects.=09Creator of aggregate MIME object=09E-MAIL= 811 MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP HEADING, USENET= 812 NEWS HEADING=09Several e-mail clients and web browsers=09MIME= 813 (RFC 2047) and URLBODY (RFC 2017)=09Various, none serious. Can= 814 be avoided by careful impelementation. See RFC 2110 for= 815 details.=09Can interoperate with non-compliant software, body= 816 part will be provided without its URL.=09RFC 2110: MIME= 817 Encapsulation of Aggregate Documents, such as HTML (MHTML),= 818 March 1997.=09Jacob Palme and Alex Hopmann= 819 =09IETF (MHTML working group), chair= 820 Einar Stefferud =09IETF is working on a revision= 821 of RFC 2110. = 822 See URL http://www.dsv.su.se/~jpalme/ietf/mhtml.html for more= 823 information.