One document matched: draft-ietf-vpim-cc-03.txt
Differences from draft-ietf-vpim-cc-02.txt
Network Working Group E. Burger
Internet Draft SnowShore Networks
Document: draft-ietf-vpim-cc-03.txt E. Candell
Category: Standards Track Comverse Network Systems
Expires September 2001 March 2, 2001
Critical Content of Internet Mail
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [1].
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."
One can access the list of current Internet-Drafts at
http://www.ietf.org/ietf/1id-abstracts.txt
One can access the list of Internet-Draft Shadow Directories at
http://www.ietf.org/shadow.html.
This document is a work product of the IETF Voice Profile for
Internet Mail (VPIM) Work Group. The URL for the VPIM website is
<http://www.vpim.org>.
1. Abstract
This document describes a mechanism for identifying the body parts
that the sender deems critical in a multi-part Internet mail
message.
By knowing what parts of a message the sender deems critical, a
content gateway can intelligently handle multi-part messages when
gatewaying to systems of lesser capability. Critical content can
help a content gateway to decide what parts to forward. It can
indicate how hard a gateway should try to deliver a body part. It
can help the gateway to pick body parts that are safe to silently
delete when a system of lesser capability receives a message. In
addition, critical content can help the gateway chose the
notification strategy of the receiving system.
Expires 9/2/01 [Page 1]
Critical Content of Internet Mail March 2001
Table of Contents
1. Abstract .........................................................1
2. Conventions used in this document ................................2
3. Introduction .....................................................3
4. Content-Criticality Entity .......................................3
4.1. CRITICAL .......................................................4
4.2. IGNORE .........................................................4
4.3. Default Values .................................................4
4.4. Other Values ...................................................5
4.5. DSN vs MDN Generation ..........................................5
4.6. Summary ........................................................5
5. Status Code ......................................................6
6. Requirements for Critical Content ................................6
6.1. Needs ..........................................................6
6.2. Current Approaches .............................................8
6.3. Critical-Content Entity ........................................8
7. The Content Gateway ..............................................9
7.1. Integrated Content Gateway .....................................9
7.2. Disaggregated Delivery Network .................................9
8. Backward Compatibility Considerations ...........................10
9. MIME Interactions ...............................................10
9.1. multipart/alternative .........................................10
9.2. multipart/related .............................................10
9.3. message/rfc822 ................................................11
10. Implementation Examples .........................................11
10.1. Content Gateways ..............................................11
10.2. Disaggregated Content Gateway .................................12
11. Security Considerations .........................................12
12. Collected Syntax ................................................13
13. References ......................................................13
14. Acknowledgments .................................................14
15. Author's Addresses ..............................................15
2. Conventions used in this document
This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the
feminine (she/her/hers). This convention is purely for convenience
and makes no assumption about the gender of a message sender or
recipient.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [2].
Burger and Candell Expires 9/2/01 [Page 2]
Critical Content of Internet Mail March 2001
NOTE: Notes, such at this one, provide additional nonessential
information that the reader may skip without missing anything
essential. The primary purpose of these non-essential notes is to
convey information about the rationale of this document, or to place
this document in the proper historical or evolutionary context.
Readers whose sole purpose is to construct a conformant
implementation may skip such information. However, it may be of use
to those who wish to understand why we made certain design choices.
3. Introduction
The specification of Critical Content is small and compact. For the
benefit of developers, the specification comes first, the rationale
after.
The content gateway issues notifications to the sender if the
receiving user agent cannot deliver a critical part of the message.
Conversely, the content gateway silently deletes parts of the
message that the receiving user agent cannot receive.
One concept that an implementer must understand is the content
gateway. Section 7 describes the content gateway. In brief, a
content gateway has knowledge of the receiving system's
capabilities. The content gateway passes messages the receiving
system can render or store. The content gateway can modify a
message, for example by deleting unrenderable or storable body
parts, for delivery to the receiving system. Finally, the content
gateway can reject a message that the receiving system cannot
handle.
4. Content-Criticality Entity
The Content-Criticality field is a MIME body part header inserted by
the sending UA to indicate to the content gateway whether to
consider the marked body part critical.
A CRITICAL body part is one the sender requires the receiving system
to deliver for him to consider the message delivered.
An IGNORE body part is one the sender doesn't care whether the
receiving system delivers it or not. A content gateway can silently
delete such body parts if the receiving system cannot deliver the
part.
The terms "entity" and "body part" have the meanings defined in [7].
One obvious application of critical content is generating a
(non-)delivery message. If the value of the field is IGNORE, the
content gateway MUST NOT generate a notification. If the value of
the field is CRTITICAL, the content gateway MAY generate a
notification, based on the normal notification request mechanisms.
Burger and Candell Expires 9/2/01 [Page 3]
Critical Content of Internet Mail March 2001
Normal notification request mechanisms include the SMTP RCPT NOTIFY
command [3] and the Disposition-Notification-To header [5].
For example, if the sending system requests a notification, and a
CRITICAL part fails, the content gateway will generate a NDN for the
whole message. Conversely, if the gateway cannot pass on a body
part marked IGNORE, the gateway will not generate a NDN.
The next sections examine the actions taken by the content gateway,
given the different values of Content-Criticality.
NOTE: This implies that the content gateway must examine the entire
message to determine whether it needs to generate a notification.
However, the content gateway need not examine the message if it
knows it can store and forward all media types. Said differently,
Internet e-mail MTAs or gateways can, by default, handle any
arbitrary MIME-encapsulated type. Some voice mail systems, on the
other hand, cannot store binary attachments at all, such as
application/ms-word. The voice mail content gateway, in this
example, would be scanning for non-renderable body parts in any
event.
4.1. CRITICAL
"Content-Criticality: CRITICAL" signifies that this body part is
critical to the sender.
If the content gateway cannot pass a body part marked CRITICAL, then
the entire message has failed. In this case, the content gateway
MUST take the appropriate failure action.
NOTE: We say "appropriate action", because the sender may have
suppressed all notifications. In this case, the appropriate action
is to silently discard the message.
4.2. IGNORE
"Content-Criticality: IGNORE" signifies that the sender does not
care about notification reports for this body part.
If the content gateway cannot pass a body part marked IGNORE, the
receiving system may silently delete the body part. The receiving
system MUST NOT return a delivery failure, unless parts marked
IMPORTANT or CRITICAL have also failed.
4.3. Default Values
The default value for Content-Criticality for a given body part is
CRITICAL. This enables the existing notification mechanisms to work
for user agents that do not know about the content notification
entity. All body parts are critical, because they have the default
marking of CRITICAL.
Burger and Candell Expires 9/2/01 [Page 4]
Critical Content of Internet Mail March 2001
NOTE: Remember that critical content processing is a function of the
content gateway, and not the MTA or UA. In practice, the entity
performing content gateway processing is the receiving UA. However,
it is acting as a content gateway. Thus the default action for any
MIME-compliant user agent to ignore unrecognized MIME entities
ensures that this mechanism is compatible with the Internet
architecture.
NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from
the Internet. However, these systems are really acting in the
capacity of an Internet Voice Mail system. In this case, one would
expect the implementation to provide Internet Voice Mail semantics
to Internet Voice Mail messages.
4.4. Other Values
The content gateway MUST treat unrecognized values as CRITICAL.
This is to provide backward compatibility with future uses of the
Content-Criticality entity.
The most likely new value is IMPORTANT. An IMPORTANT body part is
something the sender wants the receiver to get, but would not want
the message rejected outright if the IMPORTANT body part fails. A
content gateway that does not understand IMPORTANT MUST take the
default value of CRITICAL. This is because the content gateway has
to take the conservative action of rejecting the message.
4.5. DSN vs MDN Generation
The content gateway generates a delivery status notification (DSN)
[4] if it operates as a gateway. The content gateway generates a
Message Disposition Notification (MDN) [5] if it operates as a user
agent. Section 7 describes the operating modes of a content
gateway. In short, if there is a MTA that "delivers" the message to
the content gateway for processing, the MTA takes responsibility for
DSN processing. In this case, the only option available to the
content gateway is to generate MDNs. If the content gateway
operates as a MTA, then it generates DSNs. DSN generation is the
preferred option.
4.6. Summary
The following table summarizes the actions expected of a conforming
content gateway.
NOTE: This section is normative: it suggests what to put into the
DSN or MDN.
Burger and Candell Expires 9/2/01 [Page 5]
Critical Content of Internet Mail March 2001
+--------------------------------------+
| Sending UA Has Marked Body Part |
|---------------------+----------------|
| CRITICAL | IGNORE |
+--------------------+---------------------+----------------+
| Body Part is | | |
| Deliverable | Appropriate Action | ignore |
+--------------------+---------------------+----------------+
| Body Part is | | |
| Undeliverable | Fail Entire Message | ignore |
+--------------------+--------------------------------------+
The "Appropriate Action" is the action the content gateway would
take given the context of execution. For example, if a sender
requests return receipt and the receiver reads a CRITICAL body part,
the receiving UA must generate the appropriate MDN (following the
rules for MDN). Likewise, if the content gateway cannot deliver the
body part and the body part is critical, the content gateway
generates the appropriate DSN or MDN.
"Ignore" means the content gateway ignores the disposition of the
body part. The content gateway treats the message as if the body
part was not present in the message.
5. Status Code
The critical content indication, in itself, does not guarantee any
notification. Notification follows the rules described in [4] and
[5].
NOTE: The content of actual DSNs or MDNs are beyond the scope of
this document. This document only specifies how to mark a critical
body part. On the other hand, we do envision sensible DSN and MDN
contents. For example, DSNs should include the appropriate failure
code as enumerated in [6]. Likewise, MDNs should include the
failure code in the MDN "Failure:" field.
If the receiving system is to generate a notification based on its
inability to render or store the media type, the notification MUST
include the status code 5.6.1, "Media not supported", from [6].
6. Requirements for Critical Content
6.1. Needs
The need for a critical content identification mechanism comes about
because of the internetworking of Internet mail systems with
messaging systems that do not fulfill all of the semantics of
Internet mail. Such legacy systems have a limited ability to render
Burger and Candell Expires 9/2/01 [Page 6]
Critical Content of Internet Mail March 2001
or store all parts of a given message. This document will use the
case of an Internet mail system exchanging electronic messages with
a legacy voice messaging system for illustrative purposes.
Electronic mail has historically been text-centric. Extensions such
as MIME [7] enable the user agents to send and receive multi-part,
multimedia messages. Popular multimedia data types include binary
word processing documents, binary business presentation graphics,
voice, and video.
Voice mail has historically been audio-centric. Many voice-
messaging systems only render voice. Extensions such as fax enable
the voice mail system to send and receive fax images as well as
create multi-part voice and fax messages. A few voice mail systems
can render text using text-to-speech or text-to-fax technology.
Although theoretically possible, none can today render video.
An important aspect of the interchange between voice messaging
services and desktop e-mail client applications is that the
rendering capability of the voice-messaging platform is often much
less than the rendering capability of a desktop e-mail client. In
the e-mail case, the sender has the expectation that the recipient
receives all components of a multimedia message. This is so even if
the recipient cannot render all body parts. In most cases, the
recipient can either find the appropriate rendering tool or tell the
sender that she cannot read the particular attachment.
This is an important issue. By definition, a MIME-enabled user
agent, conforming to [8], will present or make available all of the
body parts to the recipient. However, a voice mail system may not
be capable of storing non-voice objects. Moreover, the voice mail
system may not be capable of notifying the recipient that there were
undeliverable message parts.
The inability of the receiving system to render a body part is
usually a permanent failure. Retransmission of the message will not
improve the likelihood of a future successful delivery. Contrast
this with the case with normal data delivery. Traditional message
failures, such as a garbled message or disabled link will benefit
from retransmission.
This situation is fundamentally different from normal Internet mail.
In the Internet mail case, either the system delivered the message,
or it didn't. There is no concept of a system partially delivering
a message.
In addition, there are many situations where the sender would not
mind if the system did not deliver non-critical parts of a message.
For example, the sender's user agent may add body parts to a message
unbeknownst to the sender. If the receiving system rejected the
message because it could not render a hidden body part, the sender
would be understandably confused and upset.
Burger and Candell Expires 9/2/01 [Page 7]
Critical Content of Internet Mail March 2001
Thus, there is a need for a method of indicating to a Mail Transfer
Agent (MTA) or User Agent (UA) that the sender considers parts of a
message to be critical. From the sender's perspective, he would not
consider the message delivered if the system did not deliver the
critical parts.
6.2. Current Approaches
One method of indicating critical content of a message is to define
a profile. The profile defines rules for silently deleting mail
body parts based on knowledge of the UA capabilities. Citing the
example above, a voice profile can easily declare that MTAs or UAs
can silently delete TNEF data and yet consider the message
successfully delivered. This is, in fact, the approach taken by
VPIMv2 [9].
Since one aspect of the issue is deciding when to notify the sender
that the system cannot deliver part of a message, one could use a
partial non-delivery notification mechanism to indicate a problem
with delivering a given body part. However, this requires the user
request a MDN.
A straightforward alternative implementation method for marking a
body part critical is to use a content-disposition parameter called
"criticality". This would have the benefit of being very easy for
IMAP servers to implement. In particular, IMAP servers
automatically present the content-disposition entity when a client
requests information on a message. On the other hand, the client
must explicitly request the presence and value of different
entities, such as content-criticality. However, implementing the
critical content indicator as a parameter to content-disposition
overloads the meaning of the entity. Moreover, IMAP servers can
present, in the future, content-criticality by default. Lastly,
most clients that have interest in content-criticality will
explicitly request the header in any event.
In short, we need a way of letting the sender indicate what body-
parts he considers to be critical. The mechanism must not burden
the sender with failure notifications for non-critical body parts.
The mechanism must conform to the general notification status
request mechanism for positive or negative notification. When
requested, the mechanism must indicate to the sender when a
receiving system cannot deliver a critical body part.
6.3. Critical-Content Entity
The Critical Content marking mechanism satisfies these needs.
Following the format for Internet message bodies [7], this document
introduces the Content-Criticality body part header. Values for
this header are CRITICAL or IGNORE.
Burger and Candell Expires 9/2/01 [Page 8]
Critical Content of Internet Mail March 2001
7. The Content Gateway
In this section, we use the definition of [10] for the term
"gateway."
A content gateway is a gateway that connects a first network to a
second network. The second network often has lesser capability than
the first network. The canonical topology follows. The "[MTA]"
signifies an optional component.
+---------+
+---------+ +-----+ | | +-------+ +-----------+
| Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving |
| UA | +-----+ | Gateway | +-------+ | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
The content gateway can be the last hop before the receiving MTA.
The content gateway can be between networks, and thus not the last
hop before the receiving MTA. The content gateway can be the first
MTA the sending UA contacts. Finally, the content gateway can be an
integrated component of the receiving MTA.
7.1. Integrated Content Gateway
In this situation, the receiving user agent is integrated with the
content gateway. The integrated content gateway knows the
capabilities of the user agent. The topology is as follows.
+---------------------+
+---------+ +-----+ | : |
| Sending |=...=|[MTA]|===| Content : Receiving |
| UA | +-----+ | Gateway : UA |
+---------+ | : |
+---------------------+
First Network Second Network
7.2. Disaggregated Delivery Network
A degenerate case, although one that does occur, is where the
content gateway sits behind the final MTA. This happens when one
implements the content gateway as a post-processing step to a normal
delivery. For example, one could configure a mail handling system
to deliver the message to a queue or directory, where the content
gateway process picks up the message. If there were any directives
for DSN processing, the delivering MTA would execute them. For
example, the message could have requested notification on successful
Burger and Candell Expires 9/2/01 [Page 9]
Critical Content of Internet Mail March 2001
delivery. The delivering MTA, having delivered the message to the
queue, would consider the message delivered and thus notify the
sender of such. However, the content gateway process could then
discover that the receiving UA cannot render the message. In this
case, the content gateway generates a NDN, as it is the only option
available.
Delivered
| +---------+
+---------+ +-----+ v | | +-----------+
| Sending |=...=| MTA |--> File -->| Content |=...=| Receiving |
| UA | +-----+ | Gateway | | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
8. Backward Compatibility Considerations
DSN requires ESMTP. If MTAs in the path from the sending UA to the
receiving UA do not support ESMTP, then that MTA will reject the DSN
request. In addition, the message will default to notification on
delay or failure. While not ideal, the sender will know that DSN is
not available, and that critical content that fails will get
notification.
9. MIME Interactions
9.1. multipart/alternative
Content-Criticality is only in effect for the selected alternative.
If the selected alternative has the critical content indicator, then
the entire alternative takes on the criticality indicated. That is,
if the alternative selected has Content-Criticality: IGNORE, then
the content gateway MUST NOT generate any delivery notifications.
It is unlikely for a selected alternative to fail, as the content
gateway presumably picks the alternative specifically because it can
render it.
If the selected alternative is a message/rfc822 that encloses a
multipart MIME message or the selected alternative is itself a
multipart MIME type, the individual top-level body parts follow the
Content-Criticality mechanism described in this document.
9.2. multipart/related
Content-Criticality fits in rather well with the multipart/related
construction. For example, consider a multipart/related message
consisting of a Macintosh data fork and a Macintosh resource fork.
Burger and Candell Expires 9/2/01 [Page 10]
Critical Content of Internet Mail March 2001
For a Microsoft Word document, the data fork is likely to be
critical. The receiving system can safely ignore the resource fork.
9.3. message/rfc822
Content-Criticality only affects the outermost level of the message
or, in the case of multipart/alternative, the outermost level of the
selected alternative. Specifically, the receiving system ignores
Content-Criticality indicators in embedded body parts. This avoids
the situation of a forwarded message triggering or suppressing
undesired reporting.
10. Implementation Examples
This section is not a normative part of the definition of Content-
Criticality. However, we hope it helps implementers to understand
the mechanics of the Content-Criticality mechanism.
We will examine two cases. They are how a content gateway processes
a message and how a disaggregated content gateway processes a
message.
10.1. Content Gateways
Content gateways examine the contents of a message from a first
network before the gateway forwards the message to a second network.
For the purposes of this example, we assume the second network has
less capability than the first network. In particular, we expect
there will be certain message body types that the gateway cannot
pass onto the second network.
Consider a gateway between the Internet and a text-only short
message service. A message comes through the gateway containing a
text part and a tnef part. The sender marks the text part CRITICAL.
The gateway, knowing the capability of the short message service,
silently deletes the non-critical, tnef part, passing the critical
content to the short message service network. Any subsequent
notifications, such as failure notices or delivery notices, follow
the normal rules for notification.
Note the gateway, by silently deleting non-critical content, may
affect proprietary message correlation schemes. One can envision
the sending UA inserting a body part for tracking purposes. By
deleting non-critical content, the content gateway will break such a
scheme. If a sending UA understands how to mark critical content,
it should use Internet standard mechanisms for tracking messages,
such as Message-ID [11].
What if no body parts have critical content indicators? In this
case, the entire message is critical. Thus, when the gateway sees
Burger and Candell Expires 9/2/01 [Page 11]
Critical Content of Internet Mail March 2001
the tnef part, it will reject the entire message, generating a DSN
with a status code 5.6.1, "Media not supported".
Likewise, consider a three part message with a text annotation (part
1) to a voice message (part 2) with a vCard [12] (part 3). The
sender marks the first two parts CRITICAL. Now, let us assume the
receiving MTA (gateway) is a voice mail only system, without even
the capability to store text. In this case, the gateway, acting as
the receiving MTA, will reject the message, generating a DSN with
the status code 5.6.1, "Media not supported".
10.2. Disaggregated Content Gateway
For this example, we will examine the processing of a three-part
message. The first part is a text annotation of the second part, an
audio message. The third part is the sender's vCard. The sender
marks the first and second parts CRITICAL. In addition, the sender
marks the message for read receipt.
For the purposes of example, the telephone user interface (TUI) does
not perform text-to-speech conversion. A TUI is a mail user agent
(UA) that uses DTMF touch-tone digits for input and audio for output
(display).
The TUI is unable to render the first part of the message, the text
part. In addition, it is unable to render the third part of the
message, the vCard part. Since the sender did not mark the third
part of the message CRITICAL, the system ignores the failure of the
TUI to render the third part of the message. However, since the
sender did mark the first part CRITICAL, and the TUI is unable to
render text, the message fails.
What happens next is implementation dependent. If the TUI is part
of a unified messaging system, a reasonable action is to hold the
message for the user. The user can access the message at a later
time from a terminal that can render all of the critical body parts.
It would be reasonable for the TUI to notify the user about the
message.
If the TUI is part of a voice messaging system, or if the user does
not subscribe to a text-to-speech service, a reasonable action is
for the TUI to return a MDN with the disposition "failed" and the
failure modifier "5.6.1 (Media not supported)".
11. Security Considerations
Receiving systems and users should not place any authentication
value on the Content-Criticality entity. Just because a message has
a particular Content-Criticality value doesn't mean that the message
really originated at a given type of system.
Burger and Candell Expires 9/2/01 [Page 12]
Critical Content of Internet Mail March 2001
12. IANA Considerations
None.
13. Collected Syntax
The format of the collected syntax is in accordance with the ABNF of
[13]. Note that per RFC 2045, none of the strings are case
sensitive.
"Content-Criticality" ":" notification-type CRLF
notification-type = "CRITICAL" / "IGNORE"
14. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
3 Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1981, University of Tennessee, January 1996.
4 Moore, K. and Vaudreuil, G., "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, University of Tennessee
and Octel Network Services, January 1996.
5 Fajman, R., "An Extensible Message Format for Message Disposition
Notifications", RFC 2298, National Institutes of Health, March
1998.
6 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
Octel Network Services, January 1996.
7 Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, Innosoft and First Virtual, November 1996.
8 Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
First Virtual, November 1996.
Burger and Candell Expires 9/2/01 [Page 13]
Critical Content of Internet Mail March 2001
9 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
version 2", RFC 2421, Lucent Technologies and Nortel Networks,
September 1998.
10 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, Isode, January 1998.
11 Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, University of Delaware, August 1982.
12 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC
2426, Lotus Development Corporation and Netscape Communications,
September 1998.
13 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
15. Acknowledgments
We'd like to thank Ned Freed for pointing out that this mechanism
was about criticality, not notification per se. That insight made
the concept and descriptions infinitely more straightforward. If
it's still confusing, it's our fault!
We'd also like to thank Keith Moore for helping us tighten-up our
explanations.
Dropping the IMPORTANT critical content type took away one of the
reasons for partial non-delivery notification. That makes Jutta
Degener very happy!
Harald Alvestrand and Chris Newman suggested we add implementation
examples, which we did.
Greg asked the key question that let us realize that critical
content processing was a gateway, and not a MTA or UA function.
Burger and Candell Expires 9/2/01 [Page 14]
Critical Content of Internet Mail March 2001
16. Author's Addresses
Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
Phone: +1 978 367 8403
Fax: +1 603 457 5944
Email: e.burger@ieee.org
Emily Candell
Comverse Network Systems
200 Quannapowitt Pkwy.
Wakefield, MA 01880
USA
Phone: +1 781 213 2324
Email: emily@comversens.com
Burger and Candell Expires 9/2/01 [Page 15]
Critical Content of Internet Mail March 2001
Full Copyright Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Copyright (C) 2000, 2001 The Internet Society. 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.
Burger and Candell Expires 9/2/01 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 01:58:18 |