One document matched: draft-ietf-drums-MHRegistry-03.txt
Differences from draft-ietf-drums-MHRegistry-02.txt
Network Working Group Jacob Palme
Internet Draft Stockholm University/KTH, Sweden
draft-ietf-drums-MHRegistry-03.txt January 1998
Category-to-be: Informational Expires August 1998
Mail and Netnews Header field Registration Procedure
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
This memo provides information for the Internet community.
This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 1998. All Rights Reserved.
Abstract
Various IETF standards and http, e-mail and netnews software
products use various http, e-mail and netnews header fields. This
document specifies a procedure for the registration of http,
e-mail and netnews header field names, to reduce the risk that two
different products use the same header field name in different
ways (homonyms) or that several different header field names are
used with identical meaning (synonyms).
Changes from version 02 of this draft
Also http header fieldss are now included in the registry, not as
before only e-mail and netnews header fields.
Added text that also fields from Internet drafts can be registered
on a temporary basis, such registration expires with the Internet
draft:
3.1 Registration of headers from Internet drafts
Headers in Internet drafts can be registered on a temporary
basis, so that the header registry can be used to find also
such headers. If the IETF draft expires, such headers must
either be removed from the registry, or changed to reflect
their new status (as an IETF standard or as a non-standard
documented separately from IETF).
Expiration month: (For a header field from an Internet draft,
this must be the expiration date of the draft. After this
time, the registration must either be removed or changed. The
word "unlimited" can be used for fields without an expiration
month.)
Changed paragraph about "X-" headers:
Because of this, an IANA registry for http, e-mail and
Netnews header field names is needed. This registry can
contain header fields starting with "X-", even though such
header fields cannot be specified in IETF standards. The
registry can also contain header fields not starting with
"X-", even though such fields are not part of IETF standards.
There is no promise that such non-standard field names, not
starting with "X-", will not be used in future standards, but
normally future standards can be expected not to use field
names from the header registry in ways which are incompatible
with existing usage of such fields as specified in the
registry.
Added text that the IESG can change any header registration.
Minor changes to registered headers, which will not cause
problems for those who have already implemented the header,
can be done by the person or organisation who has change
control for the header. This person or organisation can also
add to the register advance notice about future changes under
development. The IESG additionally has the right to modify an
header field registration, even without permission from the
change controller. This right for the IESG should of course
be used with great caution.
The name of the mailing list has been changed from "mail-headers"
to "message-headers" to allow also http and netnews header fields.
Table of contents
1. Introduction
2. Which Header fields are Registered
3. Who can Register a Header field Name
3.1 Registration of headers from Internet drafts
4. Registration Procedure
4.1 Registration Template
4.2 Present the Request for Registration to the
Community
4.3 Submit the Header field name to the IANA for
Registration
4.4 Changes to registered headers
5. Clarifications On Specific Issues
5.1 Requirements for a Limited Number of Header
Fields
5.2 Header field Status
5.3 Requirements for a Published Specification
5.4 Identification of Security Considerations
5.5 Recommendations and Standards Status
6. Security Considerations
7. Acknowledgments
8. Copyright
9. References
10. Author's address
11. Appendix: Examples of the publication format of the
header registry
11.1 Header registry when published as plain
formatted text
11.2 Header registry when published in HTML format
11.3 Header registry when published as a
tab-separated table
1. Introduction
Many different Internet standards, other RFCs and http, e-mail and
netnews software products define header fields which may occur on
http headings, Internet mail headings and/or Netnews headings.
There is an obvious risk for
Honomyns: The same header field name is used in different ways by
different software products.
Synonyms: Several different header fields for exactly the same
use.
The solution, to allow header field names beginning with "X-" for
non-standard header field names has several drawbacks. One is that
it does not preclude two different products using the same "X-"
header field name with different semantic meaning. Another is that
if an "X-" header field gets popular and much used, and is to
become a standard, there is a problem with removing the "X-" in
front of an already much used header field.
Because of this, an IANA registry for http, e-mail and Netnews
header field names is needed. This registry can contain header
fields starting with "X-", even though such header fields cannot
be specified in IETF standards. The registry can also contain
header fields not starting with "X-", even though such fields are
not part of IETF standards. There is no promise that such
non-standard field names, not starting with "X-", will not be used
in future standards, but normally future standards can be expected
not to use field names from the header registry in ways which are
incompatible with existing usage of such fields as specified in
the registry.
The following words are used in this memo with the meaning
specified below:
heading Formatted text at the top of a message, ended
by CRLFCRLF
header field One field in the heading, beginning with a
header field name, colon, and followed by the
field value(s). Other words sometimes used
for this is "header" or "heading field".
2. Which Header fields are Registered
The header field name registry can contain header fields from the
following sources:
- Internet standards
- RFCs which are not Internet standards
- Non-Internet standards
- Other commonly used header fields
- Headers implemented in new products
- Sometimes used header fields whose use is discouraged. The use
of a header field name may be discouraged because it is badly
defined, ambigous or used in different ways by different
software. The purpose of registering discouraged header fields
is to avoid their use in their present or any other future
semantic meaning.
The registry can contain header fields used in e-mail message
headings, MIME content headings, http headings and Netnews article
headings.
3. Who can Register a Header field Name
Header field names from Internet standards are registered (or the
registration modified) by IETF together with the standard
specifying the header field.
Header fields in other RFCs are registered (or the registration
modified) when the RFCs are published.
Anyone can propose the registry of additional header fields, but
such header fields should be approved by the IETF application area
managers before accepted in the registry. This approval should be
given if the header field seems reasonable and not in conflict
with current usage or other header fields in ways which might
cause problem. It is not necessary for approval that the area
manager likes the header field or wants it to be progressed into
an IETF standard. The procedure described in this memo is followed
by the IANA for review and approval of new http, e-mail and
netnews header fields. This is not a formal standards process, but
rather an administrative procedure intended to allow community
comment and sanity checking without excessive time delay.
3.1 Registration of headers from Internet drafts
Headers in Internet drafts can be registered on a temporary basis,
so that the header registry can be used to find also such headers.
If the IETF draft expires, such headers must either be removed
from the registry, or changed to reflect their new status (as an
IETF standard or as a non-standard documented separately from
IETF).
4. Registration Procedure
4.1 Registration Template
To: message-headers@segate.sunet.se
Subject: Registration of header field: XXX
Header field name:
Header field status (choices, see section
5.2 Header field Status below)
Applicability:
(One of COMMON, LIMITED USE or OBSOLETE)
What is the header field used for:
Who can set or modify the header field:
Protocols which use this header field:
(One or more of E-MAIL MESSAGE HEADING,
E-MAIL CONTENT HEADING, HTTP HEADING,
USENET NEWS HEADING)
Application programs which use this header field:
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification:
Person & email address to contact for further information:
Author/Change controller:
Expiration month: (For a header field from an Internet draft,
this must be the expiration date of the draft. After this
time, the registration must either be removed or changed. The
word "unlimited" can be used for fields without an expiration
month.)
(Any other information that the author deems interesting may
be added below this line.)
4.2 Present the Request for Registration to the Community
Send a proposed header field to the
"message-headers@segate.sunet.se" mailing list. This mailing list
has been established for the sole purpose of reviewing proposed
e-mail, netnews and http header fields. You can subscribe to the
list by sending a message to "listserv@segate.sunet.se" containing
in the text a line with
"subscribe message-headers " followed by your name (not your
e-mail address), and unsubscribe with a message "unsubscribe
message-headers". You can also subscribe through the WWW to
http://segate.sunet.se/archives/message-headers.html
Archives of this list are available
by anonymous FTP from
ftp://segate.sunet.se/lists/message-headers/
by HTTP from
http://segate.sunet.se/archives/message-headers.html
by E-MAIL
send a message to
LISTSERV@SEGATE.SUNET.SE with the text "INDEX message-headers"
to get a list of the archive files, and then a new message
"GET <file name>" to retrieve the archive files.
The FTP and E-MAIL archives are best if you want to retrieve all
messages during a month or more, while the HTTP archives are
better if you want to browse and find particular messages to
download.
The intent of the public posting is to solicit comments and
feedback on the choice of header field name, the unambiguity of
the references with respect to versions and external profiling
information, the choice of which OIDs to use, and a review of the
security considerations section. It should be noted that the
proposed header field name does not need to make sense for every
possible application. If the header field name is intended for a
limited or specific use, this should be noted in the submission.
4.3 Submit the Header field name to the IANA for Registration
After at least two weeks, submit the proposed header field to the
IANA for registration. The request and supporting documentation
should be sent to "iana@isi.edu". IANA will ask the application
area directors for approval. If approved, IANA will register the
header field, assign an OID under the IANA branch, and make the
header field registration available to the community.
IANA should keep a data base of registered header fields. IANA
should regularly publish the contents of this data base in the
following formats, which can be generated automatically from the
data base:
(1) In plain formatted ASCII text as shown in section 11.1.
(2) In HTML format as shown in section 11.2.
(3) As ASCII text with HTAB between fields and CRLF between lines
as shown in section 11.3.
Format (1) and (2) are good for human reading, format (3) is good
for input to a data base.
The header field will be listed in the periodically issued
"Assigned Numbers" RFC [2]. The header field description may be
published as an Informational RFC by sending it to
"rfc-editor@isi.edu" (please follow the instructions to RFC
authors [3]).
4.4 Changes to registered headers
Minor changes to registered headers, which will not cause problems
for those who have already implemented the header, can be done by
the person or organisation who has change control for the header.
This person or organisation can also add to the register advance
notice about future changes under development. The IESG
additionally has the right to modify an header field registration,
even without permission from the change controller. This right for
the IESG should of course be used with great caution.
Changes made by an revised version of an IETF standard should be
made at the same time as the publication of the revised standard.
Other changes require the same approval procedure as for
registration of new headers.
5. Clarifications On Specific Issues
5.1 Requirements for a Limited Number of Header Fields
Issue: In the asynchronous mail environment, where information on
the capabilities of the remote mail agent is not available to the
sender, maximum interoperability is attained by restricting the
number of header fields used to those "common" header fields
expected to be widely implemented. This was asserted as a reason
to limit the number of possible header fields and resulted in a
registration process with a significant hurdle and delay for those
registering header fields.
5.2 Header field Status
Any header field in the registry should be marked with a status,
which has one of the values specified below:
IETF standard Specified in an IETF standard.
IETF draft standard Specified in an IETF draft standard.
IETF proposed Specified in an IETF proposed standard.
standard
IETF experimental Specified in an IETF experimental
standard standard.
Internet draft Header from an Internet draft. If/when
the Internet draft expires, the header
registry must be changed to indicate its
new defining document, for example an
IETF standard.
X.400. Used to mark header fields which are
defined in RFC 1327 and other standards
for use in messages from or to Internet
mail/X.400 gateways, and which have not
been standardized for general usage in
the exchange of messages between
Internet mail-based systems.
Other standard Defined in standard developed by another
standards making body than IETF.
Non-standard This header field is not specified in
any of the RFCs which define Internet
protocols, including Internet Standards,
Draft Standards, Proposed Standards and
Experimental Standards. The header field
appears here because it sometimes
appears in http, e-mail or Netnews.
Usage of these header fields is not in
general recommended. Some header field
proposed in ongoing IETF standards
development work, but not yet accepted,
are also marked in this way.
discouraged This header field, which is non-standard
or historical, is known to create
problems and should not be generated.
Handling of such header fields in
incoming mail should be done with great
caution.
controversial The meaning and usage of this header
field is controversial, i.e. different
implementors have chosen to implement
the header field in different ways.
Because of this, such header fields
should be handled with caution and
understanding of the different possible
interpretations.
5.3 Requirements for a Published Specification
If header fields registered are specified in a separate document,
this document should be published as an RFC. Other specifications
can in some cases also be accepted if they are publicly available
on the Internet.
The information specified in section 4.1 Registration Template
above should be provided.
5.4 Identification of Security Considerations
The registration process requires the identification of any known
security problems with the header field name.
It is not required that the header field be secure or that it be
free from risks, but that the known risks be identified.
Publication of a header field name does not require an exhaustive
security review.
5.5 Recommendations and Standards Status
Issue: The registration of a header field does not imply
endorsement, approval, or recommendation by IANA or IETF or even
certification that the specification is adequate.
6. Security Considerations
This memo does not address specific security issues but outlines a
security review process for header fields.
7. Acknowledgments
Harald Tveit Alvestrand, Ned Freed, Olle Järnefors, Larry
Masinter, Keith Moore, Nick Smith and several other people have
helped in developing this document. I alone take responsibility
for any errors which may still be in it.
8. Copyright
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
9. References
Ref. Author, title IETF status
(July 1996)
---- ------------------------------------------ -------------
-
[1] J. Postel: "Simple Mail Transfer Standard,
Protocol", STD 10, RFC 821, August 1982. Recommended
[2] D. Crocker: "Standard for the format of Standard,
ARPA Internet text messages." STD 11, RFC Recommended
822, August 1982.
[3] M.R. Horton, R. Adams: "Standard for Not an
interchange of USENET messages", RFC 1036, offi-cial IETF
December 1987. standard, but
in reality a
de-facto
standard for
Netnews
[4] M. Sirbu: "A Content-Type header field for Standard,
internet messages", RFC 1049, March 1988. Recommended,
but can in the
future be
expected to be
replaced by
MIME
[5] R. Braden (editor): "Requirements for Standard,
Internet Hosts -- Application and Required
Support", STD-3, RFC 1123, October 1989.
[6] D. Robinson, R. Ullman: "Encoding Header Non-standard
field for Internet Messages", RFC 1154,
April 1990.
[7] S. Hardcastle-Kille: "Mapping between Proposed
X.400(1988) / ISO 10021 and RFC 822", RFC standard,
1327 May 1992. elective
[8] H. Alvestrand & J. Romaguera: "Rules for Proposed
Downgrading Messages from X.400/88 to standard,
X.400/84 When MIME Content-Types are elective
Present in the Messages", RFC 1496, August
1993.
[9] A. Costanzo: "Encoding Header field for Non-standard
Internet Messages", RFC 1154, April 1990.
[10] A. Costanzo, D. Robinson: "Encoding Header Experimental
field for Internet Messages", RFC 1505,
August 1993.
[11] N. Borenstein & N. Freed: "MIME Draft Standard,
(Multipurpose Internet Mail Extensions) elective
Part One: Mechanisms for Specifying and
Describing the Format of Internet Message
Bodies", RFC 1521, Sept 1993.
[12] H. Alvestrand: "Tags for the Proposed
Identification of Languages", RFC 1766, standard,
February 1995. elective
[13] J. Palme: "Electronic Mail", Artech House Non-standard
publishers, London-Boston January 1995.
[14] R. Troost, S. Dorner: "Communicating Experimental
Presentation Information in Internet
Messages: The Content-Disposition Header
field", RFC 1806, June 1995.
[15] B. Kantor, P. Lapsley, "Network News Proposed
Transfer Protocol: "A Proposed Standard standard
for the Stream-Based Transmission of
News", RFC 977, January 1986.
[16] 1848 PS S. Crocker, N. Freed, J. Proposed
Galvin, S. Murphy, "MIME Object Security standard
Services", RFC 1848, March 1995.
[17] J. Myers, M. Rose: The Content-MD5 Header Draft standard
field, RFC 1864, October 1995.
[18] M. Horton, UUCP mail interchange format Not an official
standard, RFC 976, Januari 1986. IETF standard,
but in reality
a de-facto
standard for
Netnews
[19] R. Fielding, J. Gettys, J. Mogul, H. Proposed
Frystyk. T. Berners-Lee: Hypertext standard
Transfer Protocol -- HTTP/1.1, RFC 2068,
January 1997.
[20] G. Vaudreuil: Voice Profile for Internet Experimental
Mail, RFC 1911, February 1996.
[21] H. Spencer: News Article Format and Not even an
Transmission, June 1994, RFC, but still
FTP://zoo.toronto.edu/pub/news.ps.Z widely used and
FTP://zoo.toronto.edu/pub/news.txt.Z partly almost a
de-facto
This document is often referenced under standard for
the name "son-of-RFC1036". Netnews
[22] J. Palme: Common Internet Message Header Informational
fields.
draft-ietf-mailext-mail-attributes-07.txt.
January 1997.
[23] PICS Label Distribution Label Syntax and Other standard
Communication Protocols, World Wide Web
Consortium, October 1996.
[24] Eudora Pro Macintosh User Manual, Qualcomm Non-standard
Inc., 1988-1995.
10. Author's address
Jacob Palme Phone: +46-8-16 16 67
Stockholm University/KTH Fax: +46-8-783 08 29
Electrum 230 E-mail: jpalme@dsv.su.se
S-164 40 Kista, Sweden
11. Appendix: Examples of the publication format of the header
registry
11.1 Header registry when published as plain formatted text
Header name: Content-Location:
Header status: IETF Proposed Standard
Applicability: COMMON
Use: Gives an URL corresponding to a content
part. The content part may, but need not,
be retrievable using this URL. Used when
sending HTML combined with related
objects as aggregate MIME objects.
Who can set or modify: Creator of aggregate MIME object
Protocols which use it: E-MAIL MESSAGE HEADING, E-MAIL CONTENT
HEADING, HTTP HEADING, USENET NEWS
HEADING
Applications which use Several e-mail clients and web browsers
it:
Encoding MIME (RFC 2047) and URLBODY (RFC 2017)
considerations:
Security Various, none serious. Can be avoided by
considerations: careful impelementation. See RFC 2110 for
details.
Interoperability Can interoperate with non-compliant
software,
considerations: body part will be provided without its
URL.
Published RFC 2110: MIME Encapsulation of Aggregate
specification: Documents, such as HTML (MHTML), March
1997.
Contact person: Jacob Palme <jpalme@dsv.su.se> and Alex
Hopmann <alexhop@microsoft.com>
Change controller: IETF (MHTML working group), chair Einar
Stefferud <stef@nma.com>
Other information: IETF is working on a revision of RFC
2110. See URL
http://www.dsv.su.se/~jpalme/ietf/
mhtml.html for more information.
11.2 Header registry when published in HTML format
The HTML document below can also be found at URL
http://www.dsv.su.se/~jpalme/ietf/iana-header-field-registry.html
<H2><A NAME="html-format"></A>Header registry in HTML format</H2>
<H3>Table of contents</H3>
<P><I>(Not yet complete)</I>
<MENU>
<LI>Content-Base
<LI>Content-Conversion
<LI>Content-Description
<LI>Content-Disposition
<LI>Contetn-ID
<LI>Content-Identifier
<LI>Content-Language
<LI>Content-Length
<LI><A HREF="#Content-Location">Content-Location</A>
<LI>Content-MD5
<LI>Content-Return
<LI>Content-SGML-Entity
<LI>Content-Transfer-Encoding
<LI>Content-Type
</MENU>
<H4>Content-Location</H4>
<P><TABLE BORDER=1>
<TR>
<TD>
<P><A NAME="Content-Location"></A>Header name:
</TD><TD>
<P>Content-Location:
</TD></TR>
<TR>
<TD>
<P>Header status:
</TD><TD>
<P>IETF Proposed Standard
</TD></TR>
<TR>
<TD>
<P>Applicability:
</TD><TD>
<P>COMMON
</TD></TR>
<TR>
<TD>
<P>Use:
</TD><TD>
<P>Gives an URL corresponding to a content part. The
content part may, but need not, be retrievable using
this URL. Used when sending HTML combined with related
objects as aggregate MIME objects.
</TD></TR>
<TR>
<TD>
<P>Who can set or modify:
</TD><TD>
<P>Creator of aggregate MIME object
</TD></TR>
<TR>
<TD>
<P>Protocols which use it:
</TD><TD>
<P>E-MAIL MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP
HEADING, USENET NEWS HEADING
</TD></TR>
<TR>
<TD>
<P>Applications which use it:
</TD><TD>
<P>Several e-mail clients and web browsers
</TD></TR>
<TR>
<TD>
<P>Encoding considerations:
</TD><TD>
<P>MIME (RFC 2047) and URLBODY (RFC 2017)
</TD></TR>
<TR>
<TD>
<P>Security considerations:
</TD><TD>
<P>Various, none serious. Can be avoided by careful
impelementation. See RFC 2110 for details.
</TD></TR>
<TR>
<TD>
<P>Interoperability considerations:
</TD><TD>
<P>Can interoperate with non-compliant software, body
part will be provided without its URL.
</TD></TR>
<TR>
<TD>
<P>Published specification:
</TD><TD>
<P>RFC 2110: MIME Encapsulation of Aggregate Documents,
such as HTML (MHTML), March 1997.
</TD></TR>
<TR>
<TD>
<P>Contact person:
</TD><TD>
<P>Jacob Palme <jpalme@dsv.su.se> and Alex Hopmann
<alexhop@microsoft.com>
</TD></TR>
<TR>
<TD>
<P>Change controller:
</TD><TD>
<P>IETF (MHTML working group), chair Einar Stefferud
<stef@nma.com>
</TD></TR>
<TR>
<TD>
<P>Other information:
</TD><TD>
<P>IETF is working on a revision of RFC 2110. See URL
<A HREF=
"http://www.dsv.su.se/~jpalme/ietf/mhtml.html">
http://www.dsv.su.se/~jpalme/ietf/mhtml.html</A>
for more information.
</TD></TR>
</TABLE>
11.3 Header registry when published as a tab-separated table
To agree with the allowed formats for RFCs, the section below is
encoded with the quoted-printable encoding method. This means that
the Horizontal Tab (HT) character is replaced by the string "=09"
and that all occurences of "=" followed by End-Of-Line should be
deleted from the text below to get the actual format. The IANA
published document should *not* be encoded with quoted-printable.
Header name:=09Header status:=09Applicability:=09Use:=09Who =
can set or modify:=09Protocols which use it:=09Applications =
which use it:=09Encoding considerations:=09Security =
considerations:=09Interoperability considerations:=
=09Published specification:=09Contact person:=09Change =
controller:=09Other information:
Content-Location:=09IETF Proposed Standard=09COMMON=09Gives an=
URL corresponding to a content part. The content part may,=
but need not, be retrievable using this URL. Used when=
sending HTML combined with related objects as aggregate=
MIME objects.=09Creator of aggregate MIME object=09E-MAIL=
MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP HEADING, USENET=
NEWS HEADING=09Several e-mail clients and web browsers=09MIME=
(RFC 2047) and URLBODY (RFC 2017)=09Various, none serious. Can=
be avoided by careful impelementation. See RFC 2110 for=
details.=09Can interoperate with non-compliant software, body=
part will be provided without its URL.=09RFC 2110: MIME=
Encapsulation of Aggregate Documents, such as HTML (MHTML),=
March 1997.=09Jacob Palme <jpalme@dsv.su.se> and Alex Hopmann=
<alexhop@microsoft.com>=09IETF (MHTML working group), chair=
Einar Stefferud <stef@nma.com>=09IETF is working on a revision=
of RFC 2110. =
See URL http://www.dsv.su.se/~jpalme/ietf/mhtml.html for more=
information.
| PAFTECH AB 2003-2026 | 2026-04-22 23:19:56 |