One document matched: draft-ietf-fax-implementers-guide-01.txt
Differences from draft-ietf-fax-implementers-guide-00.txt
IETF Fax Working Group Vivian Cancio
Internet Draft Xerox Corporation
Category: Work-in-progress Mike Moldovan
Intended Category: Informational G3Nova Technology, Inc.
Hiroshi Tamura
Ricoh Company, LTD.
9 March 2000
Expires: September 2000
Implementers Guide for Facsimile Using Internet Mail
<draft-ietf-fax-implementers-guide-01.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
[[INTENDED STATUS: This memo provides information for the Internet
community. It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.]]
Copyright Notice
Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract
This document is intended for the implementers of
software which uses email to send to facsimiles using RFC 2305 and 2532.
This is an informational document and its guidelines do not supersede the
referenced documents.
Cancio, Moldovan, Tamura Work-in-progress [Page 1]
Internet draft Implementers Guide 1 March 2000
Table of contents
1. Introduction
1.1 Organization of this document
1.2 Convention of this document
1.3 Discussion of this document
2. Terminology
3. Implementation Issues Specific to Simple Mode
3.1 Simple Mode Fax Senders
3.1.1 Multipart-alternative
3.2 Simple Mode Fax Receivers
3.2.1 Multipart-alternative and Storage Capacity
4. Implementation Issues Specific to Extended Mode
4.1 Multipart-alternative
4.2 Correlation of MDN with Original Message
4.3 Correlation of DSN with Original Message
4.4 Extended Mode Receivers
4.4.1 Confirmation of receipt and processing
4.4.1.1 Discrepancies in MDN [7] Interpretation
4.4.2 Extended Mode Receivers which are MTAs
(or ESMTP servers)
4.4.3 Extended Mode Receivers which are POP3/IMAP4
5. Implementation Issues the File Format
5.1 IFD Placement in TIFF file & Profile-S Constraints
5.2 Precautions for implementers of RFC 2301 [4]
5.2.1 Typical Reader Errors in Headers
5.2.2 Typical IFD Errors
5.2.3 IFD Entry Errors
5.2.4 Strip Errors
5.2.5 Image Errors
5.2.6 Profile Specific Errors
6. Implementation Issues for Internet Fax Addressing
6.1 Conventional email addresses
6.2 Internet Fax Offramp Addresses Per RFC 2303/3204
7. Known Open Implementation Issues
7.1 Email and Traditional Facsimile Headers
7.2 Simple Mode
7.3 Extended Mode
8. Security considerations
9. Acknowledgements
10. References
11. Authors' addresses
Full copyright statement
Revision history
Cancio, Moldovan, Tamura Work-in-progress [Page 2]
Internet draft Implementers Guide 9 March 2000
1. Introduction
This document clarifies published RFCs which standardize facsimile communications using Internet Email. The intent is to prevent implementations that deviate in such a way as to cause interoperability problems.
1.1 Organization of this document
See Section 2 for terminology.
a) Simple mode clarifications
b) Extended mode clarifications
c) File format clarifications
d) Fax Addressing Clarifications
e) Open implementation issues
1.2. Convention of this document
[[[Editorial comments from authors are embedded in triple brackets
and will be removed before publication]]]
1.3 Discussion of this document
Discussion of this document should take place on the Internet fax
mailing list hosted by the Internet Mail Consortium (IMC). Please
send comments regarding this document to:
ietf-fax@imc.org
To subscribe to this list, send a message with the body 'subscribe'
to "ietf-fax-request@imc.org".
To see what has gone on before you subscribed, please see the
mailing list archive at:
http://www.imc.org/ietf-fax/
2. Terminology
Simple Mode - Refers to RFC 2305, "A Simple Mode of Facsimile
Using Internet Mail"
Extended Mode - Refers to RFC 2532, "Extended Facsimile using
Internet Mail"
TIFF-FX - Refers to RFC 2301, "File Format for Internet fax"
UA - User Agent
DSN - Delivery Status Notification
MDN - Message Disposition Notification
In examples: - "C:" is used to indicates lines sent by the client, and
"S:" to indicate those sent by the server.
MTA - Message Transfer Agent
Cancio, Moldovan, Tamura Work-in-progress [Page 3]
Internet draft Implementers Guide 9 March 2000
3. Implementation Issues Specific to Simple Mode
3.1 Simple Mode Fax Senders
3.1.1 Multipart/alternative
Although a requirement of MIME compliance (see RFC 2046, Section 5.1.4), some email client implementations are not capable of correctly processing messages with a MIME Content-Type of "multipart/alternative". If a sender is unsure if the recipient is able to correctly process a message with a Content-Type of "multipart/alternative", the sender should assume the worst and not use this MIME Content-Type.
In the absence of a standard mechanism to determine the recipient's capabilities, a sender should avoid sending multipart/alternative. At this time there is not standard mechanism to determine this capability in a recipient.
3.2 Simple Mode Fax Receivers
3.2.1 Multipart/alternative and Storage Capacity
Devices with little storage capacity are unable to cache previous parts of a multipart/alternative message. In order for such devices to correctly process only one part of a multipart/alternative message, such devices may simply use the first process-able part of a multipart/alternative message. This is viable because the parts within a multipart/alternative are always sent in least-fidelity to most-fidelity order.
This behavior means that even if subsequent, higher-fidelity parts may have been process-able they will not be used.
This behavior can cause user dissatisfaction because when two (high-fidelity but) low-memory devices are used with each other, the lowest-fidelity part of the multipart/alternative will be processed.
The solution to this problem is for the sender to determine the capability of the recipient. However a mechanism to determine the recipient capabilities prior to an initial message sent to the recipient doesn't yet exist on the Internet.
The Extended Mode mechanism described in RFC 2532 [3], Section 3.3 enables a recipient to include its capabilities in a confirmation notice, in a DSN if the recipient device is an RFC 2532/ESMTP compliant server or in an MDN if the recipient is only an UA.
Cancio, Moldovan, Tamura Work-in-progress [Page 4]
Internet draft Implementers Guide 9 March 2000
4. Implementation Issues Specific to Extended Mode
4.1 Multipart/Alternative
Sections 3.1.1 and 3.2.1 are also applicable to this mode.
4.2. Correlation of MDN with Original Message
To re-iterate a paragraph from section 2.1, RFC 2298 [9], it is
included here:
A message that contains a Disposition-Notification-To header SHOULD
also contain a Message_ID header as specified in RFC 822 [?]. This
will permit automatic correlation of MDNs with original messages by
user agents.
4.3 Correlation of DSN with Original Message
Similar to the requirement to correlate an MDN, above, DSNs also need to be correlated. This is best done using the ENVID parameter in the "MAIL" command. See Sections 3 and 5.4 of RFC 1891 [5] for details.
4.4 Extended Mode Receivers
4.4.1 Confirmation of receipt and processing
Confirmation that the facsimile image (TIFF-FX attachment) was delivered and successfully processed is an important aspect of the extended mode of facsimile using Internet mail. Implementers of the Extended Mode [3] should provide consistency in the feedback provided to senders in the form of error codes and/or failure/successful messages.
4.4.1.1 Discrepancies in MDN [7] Interpretation
The value of receiving an acknowledgement of 'processability' from
an Extended Mode recipient is the success or failure to process the
TIFF-FX file attachment. The attachment constitutes the facsimile
message and not the body-content of the message. Therefore a
Extended Mode sender would expect, and it is recommended, that the
Extended Mode receiver responds with a MDN to indicates the success
or failure to decode and process the TIFF-FX file attachment.
An Extended Mode sender must be aware that RFC 2298 [7] does not make
this distinction and consequently MDNs may be received which do not
associate the feedback information to the attached TIFF-FX file but
to the body-content part of the message.
[[[Dan Wing had an I-D that solved this problem. We can resurrect?]]]
Cancio, Moldovan, Tamura Work-in-progress [Page 5]
Internet draft Implementers Guide 9 March 2000
4.4.2 Extended Mode Receivers which are MTAs (or ESMTP servers)
NOTE: There are no new definitions here. This section explains
how to use DSN and status code for ESMTP server devices.
It is strongly encouraged that SMTP server-based implementations should implement "SMTP Service Extension for Returning Enhanced Error Codes" [6]. This standard is easy to implement and it allows detailed standardized success and error indications to be returned to the sender by the submitting MTA.
4.4.2.1 Examples for Receivers which are MTAs (or ESMTP servers)
These examples are provided as illustration only. They should not be interpreted as limiting the protocol or the DSN form.
If examples conflict with the definitions (RFC 1891/1893/1894/2034), the example is wrong. The definitions are not superseded here.
a) Success Case
In the following example the sender <jean@water.line.com> sends a message to receiver <ifax@water.line.com> which is an ESMTP server and the receiver successfully decodes the message.
SMTP Sequence:
S: 220 copper.point.com SMTP service ready
C: EHLO water.line.com
S: 250-copper.point.com
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@water.line.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@water.line.com> ok
C: RCPT TO:<ifax@water.line.com> NOTIFY=SUCCESS,FAILURE
S: 250 2.1.5 Recipient <ifax@water.line.com> ok
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
...
...
...
C: .
S: 250 2.0.0 Message accepted
C: QUIT
S: 221 2.0.0 Goodbye
Cancio, Moldovan, Tamura Work-in-progress [Page 6]
Internet draft Implementers Guide 9 March 2000
DSN (to jean@water.line.com):
Date: Mon, 12 Dec 1999 19:01:57 +0900
From: postmaster@copper.point.com
Message-ID: <19991212190157.01234@copper.point.com>
To: jean@water.line.com
Subject: Delivery Notification (success)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121854870001
--JUK199912121854870001
Content-type: text/plain;
Your message (id MM123456) was successfully delivered to
ifax@water.line.com.
--JUK199912121854870001
Content-type: message/delivery-status
Reporting-MTA: dns; copper.point.com
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@water.line.com
Action: delivered
Status: 2.1.5 (Destination address valid)
Diagnostic-Code: smtp; 250 Recipient <ifax@water.line.com> ok
--JUK199912121854870001
Content-type: message/rfc822
(headers of returned message go here)
--JUK199912121854870001--
b) Failure Case 1
In this example the receiver is unable to decode the attached file AFTER receiving the complete message.
SMTP Sequence:
This is the same as the case a). After the sequence, a decode error occurs at the receiver.
Cancio, Moldovan, Tamura Work-in-progress [Page 7]
Internet draft Implementers Guide 9 March 2000
DSN(to jean@water.line.com):
Date: Mon, 12 Dec 1999 19:31:20 +0900
From: postmaster@copper.point.com
Message-ID: <19991212193120.87652@copper.point.com>
To: jean@water.line.com
Subject: Delivery Notification (failure)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121934240002
--JUK199912121934240002
Content-type: text/plain;
Your message (id MM123456) to ifax@water.line.com resulted in an error
in attempt to decode the attached file.
--JUK199912121934240002
Content-type: message/delivery-status
Reporting-MTA: dns; copper.point.com
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@water.line.com
Action: Failed
Status: 5.6.1 (Media not supported)
Diagnostic-Code: smtp; 554 Decode error
--JUK199912121934240002
Content-type: message/rfc822
(headers of returned message go here)
--JUK199912121934240002
Cancio, Moldovan, Tamura Work-in-progress [Page 8]
Internet draft Implementers Guide 9 March 2000
c) Failure Case 2
In this example the receiver is unable to decode the attached file BEFORE receiving the complete message.
SMTP sequence:
S: 220 copper.point.com SMTP service ready
C: EHLO air.rect.com
S: 250-copper.point.com
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@water.line.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@water.line.com> ok
C: RCPT TO:<ifax@water.line.com> NOTIFY=SUCCESS,FAILURE
S: 250 2.1.5 Recipient <ifax@water.line.com> ok
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
...
... (the attached file cannot be decoded by receiver)
...
C: .
S: 554 5.6.1 Media not supported
C: QUIT
S: 221 2.0.0 Goodbye
DSN:
Note: The previous MTA then generates the DSN that is forwarded to the original sender. A receiving UA can not generate a DSN.
4.4.3 Extended Mode Receivers which are POP3/IMAP4
NOTE: There are no new definitions here. The definitions of disposition-types
and disposition-modifiers are defined in RFC 2298[7]. This section
explains how POP3/IMAP4 devices may use the already defined values.
When a message is received with the Disposition-Notification-To header,
And the receiver has determined if the message is process-able, it may generate
a (negative confirmation) MDN in case of error or a (positive confirmation) MDN if the MDN is requested by the sender.
a) Success case
If the original sender receives MDNs which have "displayed", "dispatched" or "processed" disposition-type without disposition-modifier, the receiver may have possibly received or decoded the attached TIFF-FX file that it sent. It does not guarantee that the receiver displays, print or save the attached TIFF-FX file See Section 4.4.1.1, Discrepancies in MDN Interpretation.
Cancio, Moldovan, Tamura Work-in-progress [Page 9]
Internet draft Implementers Guide 1 March 2000
b) Failure case
If the original sender receives an MDNs with an "error" or "warning" disposition-modifier, it is possible that the receiver could not receive or decode the attached TIFF-FX file. [[[Currently there is not way to associate the disposition-type with the handling of the main body of the message or the attached TIFF-FX file]]].
4.4.3.1 Examples
These examples are provided as illustration only. They should not be interpreted as limiting the protocol or the MDN form. If examples conflicts with the MDN definition[7], the example are wrong.
a) Success example
NOTE: The third component of this MDN is not here. It is optional.
Date: 14 Dec 1999 17:48:44 +0900
From: ken_recipient@bronze.dot.com
Message-ID: <19991214174844.98765@silver.dot.com>
Subject: Disposition notification(Return Receipt:dispatched)
To: mary@silver.dot.com
Mime-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="61FD1001_IFAX"
--61FD1001_IFAX
Content-Type: text/plain
This is a Return Receipt for the mail that you sent to
"ken_recipient@bronze.dot.com". This is no guarantee that
the message body/the attached file has been displayed,
printed or saved.
--61FD1001_IFAX
Content-Type: message/disposition-notification
Reporting-UA: mary-ifax.silver.dot.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@bronze.dot.com
Final-Recipient: rfc822;ken_recipient@bronze.dot.com
Original-Message-ID: <19991214174010O.mary@silver.dot.com>
Disposition: automatic-action/MDN-send-automatically; dispatched
--61FD1001_IFAX--
Cancio, Moldovan, Tamura Work-in-progress [Page 10]
Internet draft Implementers Guide 1 March 2000
b) Failure example
Date: 14 Dec 1999 19:48:44 +0900
From: ken_recipient@bronze.dot.com
Message-ID: <19991214194844.67325@silver.dot.com>
Subject: Disposition notification(Return Receipt:processed/error)
To: mary@silver.dot.com
Mime-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="84FD1011_IFAX"
--84FD1011_IFAX
Content-Type: text/plain
This is a Return Receipt for the mail that you sent to
"ken_recipient@bronze.dot.com". Decoding error occurred
in the attached file.
--84FD1011_IFAX
Content-Type: message/disposition-notification
Reporting-UA: mary-ifax.silver.dot.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@bronze.dot.com
Final-Recipient: rfc822;ken_recipient@bronze.dot.com
Original-Message-ID: <199912141823123.mary@silver.dot.com>
Disposition: automatic-action/MDN-send-automatically; processed/error
--84FD1011_IFAX
Content-Type: message/rfc822
[original message goes here]
--84FD1011_IFAX--
5. Implementation Issues Specific to the File Format
5.1 IFD Placement in TIFF file & Profile S Constraints
Low memory devices, which support resolutions greater than the required Profile-S may be memory-constrained such that those devices cannot properly handle arbitrary placement of TIFF IFDs within a TIFF file.
To interoperate with a receiver that is constrained, it is strongly recommended that senders always place the IFD at the beginning of the TIFF-FX file when using any of the Profiles defined in RFC 2301.
5.2 Precautions for implementers of RFC 2301 [4]
Interoperability testing of the File Format for Internet Fax [4] yielded useful
Cancio, Moldovan, Tamura Work-in-progress [Page 11]
Internet draft Implementers Guide 9 March 2000
information that may help developers avoid the same mistakes.
The following compiled list of TIFF/RFC 2301 [4] errors where encountered during interoperability testing and is provided so that implementers can take precautionary measures.
5.2.1 Typical Reader Errors in Headers
a) Although Profile S in TIFF-FX requires little-endian, readers implementing profiles other than Profile-S may be constrained and only read little-endian, even when the specifications permits encoding in both little-endian and big-endian.
Consequently, implementers generating big-endian order (bytes 0-1 equal to 4D4Dh) should be aware of potential interoperability problems with such constrained receivers.
b) TIFF Readers should not expect that the byte order (bytes 0-1 of the Image File Header) be equal to only "II"(4949h) or "MM"(4D4Dh). They should be able to accept other values and exit gracefully.
c) Implementers should not expect that the "magic number" (bytes 2-3 of
the Image File Header) be equal to 42 (2Ah) -- other values were
found during testing.
d) Implementers should be careful of the first IFD offset pointing beyond
the end of the TIFF-FX file.
e) Implementers should be aware that the first IFD offset is not always
found on a word boundary.
5.2.2 Typical IFD Errors
a) Implementers should be cautious when generating a TIFF profile with
a second or third IFD. They should make sure that the offsets for the
extra IFDs do not point outside the file.
b) Implementers should be careful not to overlap the IFDs with other
TIFF profile data such as strip image data or header data.
c) Implementers should be aware that some readers have difficulties
handling TIFF profiles with the following IFD positions: IFD at
the end of the profile, IFD intercalated with another IFD data like
XResolution, DateTime, strip image data, etc.
d) Implementers should be aware that some legacy readers have difficulties
handling profiles that have child IFDs. There is a high probability
that some of these readers will have trouble accessing all the child IFDs
e) Implementers should also be aware that some readers do not recognize the
GlobalParametersIFD).
Cancio, Moldovan, Tamura Work-in-progress [Page 12]
Internet draft Implementers Guide 9 March 2000
5.2.3 IFD Entry Errors
Implementers should make sure when generating a TIFF profile that:
a) All entries exist. Missing entries make it impossible to read the
image data.
b) Tags will not have two types of data (for example SHORT or LONG).
c) Tags do not have the wrong type of data (for example RATIONAL instead
of SRATIONAL.
d) The count of type is correct for a specified tag (it is not null and
the matches the tag ID)
e) Tags appear in the right order in the IFD.
f) Tags as PageNumber or ImageLayer have values that match the number
of IFDs or the image data.
g) Tags are unique within an IFD.
5.2.4 Strip Errors
Implementers should make sure when generating a TIFF profile that:
a) Strip data is not overlapped with another file data
b) The strip offset does not point outside file
c) The strip length is not null or the strip offset + strip length
does not point outside file
d) There is only one bit order (not more) specified for data storing.
5.2.5 Image Errors
a) Implementers should be cautious when generating a TIFF profile that the type of image tags and the data from the strip data match. (e.g. If in case of a
B&W image, the PhotometricInterpretation tag value is 0 (bit 0 means white) the image will appear inverted).
b) Implementers should be cautious when generating a TIFF profile that for the special color spaces (ITULAB, YCBCR, CMYK) the parameters used for transformations are correct and compliant to the specification.
c) Implementers should make sure when generating a TIFF profile that the tag values for XPosition and YPosition are correct.
Cancio, Moldovan, Tamura Work-in-progress [Page 13]
Internet draft Implementers Guide 9 March 2000
5.2.6 Profile Specific Errors
a) Implementers should make sure when generating a TIFF profile that all combinations of tag values are correct. Special attention should be given to the sets: XResolution, YResolution and ImageWidth and PhotometricInterpretation, SamplesPerPixel, and BitsPerSample.
b) Implementers should make sure when generating a TIFF profile M that the compression used for the layers is correct. Typical errors are for the Mask layer not be compressed with a black and white compression and the Background and Foreground layer not to be compressed with a color compression.
6. Implementation Issues for Internet Fax Addressing
TBD [[[ Section will be removed if not needed ]]]
7. Known Open Implementation Issues
7.1 Email and Traditional Facsimile Headers
In reference to the TIFF Encoded images generated in the general case where the end to end transmission is all Internet mail and there is no onramp or offramp to the GSTN.
Should senders rasterize the classic time/date, page number or CSID data into the TIFF page image before the SMTP transmission to preserve the "look and feel" and general end user expectations of what a "fax" looks like?
8. Security considerations
With regards to this document, Sections 5 in RFC 2305 [2] and Section 4 in RFC 2532 [3] apply.
9. Acknowledgements
The authors gratefully acknowledge the following persons who
contributed or made comments on earlier versions of this memo:
Dan Wing, Ryuji Iwazaki, Graham Klyne, and James Rafferty.
10. References
[1] RFC 2542, "Terminology and Goals for Internet Fax"
Larry Masinter, Xerox Corporation
March 1999.
Cancio, Moldovan, Tamura Work-in-progress [Page 14]
Internet draft Implementers Guide 9 March 2000
[2] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail"
Toyoda, K., Ohno, H., Murai, J. and D. Wing
March 1998.
[3] RFC 2532, "Extended Facsimile Using Internet Mail"
Larry Masinter, Xerox Corporation
Dan Wing, Cisco Systems
March 1999.
[4] RFC 2301 "File Format for Internet Fax", McIntyre, L., Zilles,
S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty,
March 1998.
[5] RFC 1891 "SMTP Service Extension for Delivery Status Notification",
Moore, K., January 1996.
[6] RFC 1893 "Enhanced Mail System Status Codes", Vaudreuil, G.,
January 1996
[7] RFC 1894 "An Extensible Message Format for Delivery Status Notifications",
Moore, K., Vaudreuil, G.,
January 1996
[8] RFC 2034 "SMTP Service Extension for Returning Enhanced Error Codes",
Freed, N.,
October 1996
[9] RFC 2298 "An Extensible Message Format for Message Disposition
Notifications", Fajman, R.
March 1998
11. Authors' addresses
Vivian Cancio
Xerox Corporation
Mailstop PAHV-211
3400 Hillview Ave.
Palo Alto, CA 94304 USA
Telephone: +1-650-813-7591
Facsimile: +1-650-845-2341
E-mail: vivian.cancio@pahv.xerox.com
Mike Moldovan
G3 Nova Technology, Inc.
2794 Queens Way
Thousand Oaks, CA 91362 USA
Telephone: +1-805-245-4625
Facsimile: +1-805-245-4214
E-mail: mmoldovan@g3nova.com
Cancio, Moldovan, Tamura Work-in-progress [Page 15]
Internet draft Implementers Guide 9 March 2000
Hiroshi Tamura
Ricoh Company, LTD.
2446 Toda, Atsugi City,
Kanagawa-Pref., 243-0023 Japan
Phone: +81-46-228-1743
Fax: +81-46-228-7500
Email: tamura@toda.ricoh.co.jp
Full copyright statement
Copyright (C) The Internet Society 1999. 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 implementation 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.
Revision history
[[[RFC editor: Please remove this section on publication]]]
Cancio, Moldovan, Tamura Work-in-progress [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 21:02:19 |