INTERNET-DRAFT Henrik Holst i-data international a/s Tom Hastings Xerox Corp. March 9, 2000 Internet Printing Protocol (IPP): The 'mailto:' Notification Delivery Method Copyright (C) The Internet Society (2000). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [rfc2026]. 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 as http://www.ietf.org/shadow.html. Abstract The IPP notification specification [ipp-ntfy] is an OPTIONAL extension to IPP/1.0 and IPP/1.1 that requires the definition of one or more delivery methods for dispatching event notification reports to Notification Recipients. This document describes the semantics and syntax of the 'mailto:' event notification delivery method. For this delivery method, the IPP Printer uses the SMTP mail protocol to send (push) Human Consumable and/or Machine Consumable Notifications to Notification Recipients. The Subscriber specifies the mail address using the mailto: URL. This mail address can be any user or can be any of the mail services defined to perform such notification using parameters in the URL, such as paging. The Subscriber can specify the MIME media type of both the Human Consumable and Machine Consumable Notifications. The Subscriber can also specify a mail address in the "subscriber-user-data" Subscription attribute to which the Notification Recipient can reply and to which the mail system delivers undeliverable mail messages. That mail address is usually the Subscribers mail address, but can be any mail address. The mail messages appear to come from the Printer, so that mail agents can sort and filter on the From: field. Also the beginning of the Holst, Hastings [page 1] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 Subject line starts with the localized "Printer message: " prefix, so that mail agents can filter from any Printer. There are 7 ISSUES called out in the text. Holst, Hastings [page 2] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 The full set of IPP documents includes: Design Goals for an Internet Printing Protocol [RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568] Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569] Internet Printing Protocol (IPP): Event Notification Specification [ipp-ntfy] The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1. The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions. The "Internet Printing Protocol/1.1: Model and Semantics" document describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport. It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues. The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs. The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included. The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations. Holst, Hastings [page 3] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 The "Event Notification Specification" document extends the Job Creation operations and defines additional operations that allow a client to subscribe to printing related events. Subscriptions are modeled as Subscription objects which can be Per-Job or Per-Printer Subscriptions. Additional operations are defined to query, renew, and cancel Subscription objects. Holst, Hastings [page 4] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 Table of Contents 1 Introduction......................................................6 2 Terminology.......................................................6 2.1Conformance Terminology..........................................6 2.2Other terminology................................................7 3 Model and Operation...............................................7 4 Sending Notifications.............................................8 4.1notify-recipient (uri)...........................................8 4.2notify-events (1setOf type2 keyword).............................8 4.3notify-format (mimeMediaType)....................................9 4.4subscriber-user-data (octetString(63))...........................9 4.5notify-charset (charset)........................................10 4.6notify-natural-language (naturalLanguage).......................10 4.7request-id......................................................10 4.8subscription-id (integer (1:MAX))...............................10 4.9notify-lease-expiration-time (integer(0:MAX))...................10 4.10 printer-uri (uri).............................................10 4.11 subscriber-user-name (name(MAX))..............................11 4.12 notify-printer-up-time (integer(1:MAX)).......................11 4.13 notify-persistence-granted (boolean)..........................11 5 Mail Notification Content........................................11 5.1Human Consumable Form...........................................13 5.2Machine Consumable Form.........................................13 6 Printer Description attributes specific to the 'mailto:' delivery method...............................................................13 6.1"printer-smtp-mail-service-address" (1setOf text(MAX))..........13 7 Conformance Requirements.........................................13 8 IANA Considerations..............................................14 9 Internationalization Considerations..............................14 10 Security Considerations..........................................14 11 References.......................................................15 12 Author's Addresses...............................................16 13 Full Copyright Statement.........................................16 Table of Tables Table 1 - SMTP Fields to be filled in................................12 Holst, Hastings [page 5] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 1 Introduction An IPP Printer that supports the OPTIONAL IPP notification extension [ipp-ntfy] is called a Notification Source which sends event Notifications to Notification Recipients. As such, a Printer either a) accepts, stores, and uses notification Subscription objects to generate event Notification reports and implement one or more delivery methods for notifying interested parties, or b) supports a subset of these tasks and farms out the remaining tasks to a Notification Delivery Service. This document describes the semantics and syntax of the 'mailto:' event notification delivery method. Such a Notification Delivery Service then delivers the event Notification to the Ultimate Notification Recipient. For this delivery method, the IPP Printer uses the SMTP mail protocol to send (push) Human Consumable and/or Machine Consumable Notifications to Notification Recipients. The Subscriber specifies the mail address using the mailto: URL. This mail address can be any user or can be any of the mail services defined to perform such notification using parameters in the URL, such as paging. The Subscriber can specify the MIME media type of both the Human Consumable and Machine Consumable Notifications. The Subscriber can also specify a mail address in the "subscriber-user-data" Subscription attribute to which the Notification Recipient can reply and to which the mail system delivers undeliverable mail messages. That mail address is usually the Subscribers mail address, but can be any mail address. The mail messages appear to come from the Printer, so that mail agents can sort and filter on the From: field. Also the beginning of the Subject line starts with the localized "Printer message: " prefix, so that mail agents can filter from any Printer. 2 Terminology This section defines terminology used throughout this document: 2.1 Conformance Terminology Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance to this specification. These terms are defined in [ipp-mod section 13.1 on conformance terminology, most of which is taken from RFC 2119 [RFC2119]. REQUIRED - an adjective used to indicate that a conforming IPP Printer implementation MUST support the indicated operation, object, attribute, attribute value, status code, or out-of-band value in requests and responses. See [ipp-mod] "Appendix A - Terminology for a definition of "support". Since support of this entire notification specification is OPTIONAL for conformance to IPP/1.0 or IPP/1.1, the use of the term REQUIRED in this document Holst, Hastings [page 6] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 means "REQUIRED if this OPTIONAL notification specification is implemented". OPTIONAL - an adjective used to indicate that a conforming IPP Printer implementation MAY, but is NOT REQUIRED to, support the indicated operation, object, attribute, attribute value, status code, or out-of-band value in requests and responses. 2.2 Other terminology Event Notification (Notification for short) - See [ipp-ntfy] Notification Source - See [ipp-ntfy] Notification Recipient - See [ipp-ntfy] Subscription object - See [ipp-ntfy] Ultimate Notification Recipient - See [ipp-ntfy] 3 Model and Operation In the IPP Notification Model [ipp-ntfy], a client is able to: 1. supply one or more Per-Job Subscriptions in the Job Creation operation 2. OPTIONALLY supply Per-Job Subscriptions as subsequent Create-Job- Subscription operations 3. supply one Per-Printer Subscription in the Create-Printer- Subscription operation. The client that creates these Subscription objects becomes the owner of the Subscription object. The client that creates these Subscription objects becomes the owner of the Subscription object. When creating each Subscription object, the client supplies the "notify- recipient" (uri) attribute. The "notify-recipient" attribute specifies both a single Notification Recipient that is to receive the Notifications when subsequent events occur and the method for Notification delivery that the IPP Printer is to use. For the 'mailto:' Notification delivery method defined in this document, the "notify- recipient" consists of the 'mailto:' scheme followed by an SMPT mail address [RFC822]. Notification Sources that implement the 'mailto:' event notification delivery method will need to include an SMTP mail agent while Notification Recipients that implement this delivery method will need to support an SMTP server. ISSUE 01: Is this SMTP terminology correct? The IPP Printer can be the Notification Source or could use some other Notification Delivery Service that actually delivers the mail message. In this latter case, the protocol between the IPP Printer and the Notification Delivery Service is implementation defined and could be the INDP protocol (see [indp]). Holst, Hastings [page 7] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 Also the Notification Recipient specified by the "notify-recipient" Subscription attribute can be either (1) the Ultimate Notification Recipient or can be a Notification Delivery Service, such as a paging system that accept 'mailto:' parameters to indicate the Ultimate Notification Recipient, such as a phone number or paging subscriber's id. 4 Sending Notifications This section defines the processing that the IPP Printer MUST perform when sending an event Notification using the 'mailto:' delivery method. The usage of each of the Subscription object attributes defined in [ipp- ntfy] is described here as it applies to the 'mailto:' delivery method. The description of each Subscription attribute in this document is not the complete description, but is just the application of the attribute to this 'mailto:' delivery method. See the complete definition of each Subscription object attribute in [ipp-ntfy]. ISSUE 02: Is it a good idea to list each Subscription object attribute in this spec with the applicability to this delivery method? If yes, should all delivery method specs also do it this way? Section 5 defines how the IPP Printer populates the SMTP fields in the mail message. 4.1 notify-recipient (uri) This REQUIRED READ-ONLY Subscription object attribute contain the 'mailto:' URI delivery method followed by the SMTP mail address [RFC821] of the Notification Recipient. As required by the [ipp-ntfy] document, the following information is given for this notification delivery method: ISSUE 03 - What should we say about any mailto parameters, if any? For example, if you want to send over secure mail, etc. ISSUE 04 - Do we want to define any IPP-specific mailto parameters to this document? 4.2 notify-events (1setOf type2 keyword) This REQUIRED READ-ONLY Subscription object attribute identifies the job and/or printer events that are to be delivered to the Notification Recipient as Notifications as defined in [ipp-ntfy] section 7. Note: Some rapidly recurring events, such as page events, are not appropriate to use with this delivery method, especially if the recipient mail address is a mailing list. Implementations MAY choose either not to support page events with the 'mailto:' delivery method and/or not permit a mailing list to be supplied, if they can detect that a mail address is a mailing list. Holst, Hastings [page 8] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 4.3 notify-format (mimeMediaType) This REQUIRED READ-ONLY Subscription object attribute indicates the type of Human Consumable and/or Machine Consumable format content that is to be sent in the Notifications as a mail message attachment. For the 'mailto:' delivery method, any registered 'mimeMediaType' value is allowed, including types that allow pictures to be represented, e.g., 'application/postscript' or 'image/tiff', and/or sounds to be represented, e.g., 'audio/32kadpcm'. The body of the mail message MUST always be 'text/plain; charset=us-ascii, since that is the default for 'mailto:'. There is no "notify-default" Printer attribute to configure. If the client did not supply the "notify-format" attribute in the Subscription Creation operation, the Printer MUST populate this attribute with an implementation-defined default value. Such a default value MAY include multi-part mixed media, so that the Printer can send multi-part mixed MIME type attachments by default (though there is no way for the client to explicitly request such). If the out-of-band 'none' value [ipp-col] was supplied in the Subscription Creation operation, the Printer MUST NOT send any attachment in the Notification. If the MIME media type registration definition permits a charset parameter, than the client MUST use such a specification (instead of the "notify-charset" attribute) in order to indicate the charset to be used in the Notification content. 4.4 subscriber-user-data (octetString(63)) This REQUIRED READ-ONLY Subscription object attribute holds an SMTP mail address value that the Printer copies to the "From:" inside <> (see RFC 822 [rfc822] section 4.4.1) and the "Sender:" SMTP fields (see section 5). For the 'mailto:' notification delivery method, the client MUST supply the "subscriber-user-data" attribute. If the client omits this attribute, the Printer MUST either (1) reject the operation with the 'client-error-bad-request' or (2) ignore this Subscription, since the Printer will not have a mail address to put in the "From:" and in the "Sender:" SMTP fields, depending on implementation. When the subscribing user selects the 'mailto:' delivery scheme, the client SHOULD obtain the user's mail address automatically from the client system (in an implementation-dependent manner) and supply it as the value of the "subscriber-user-data" attribute by default, rather than require the user to explicitly supply it. Allowing users to supply the mail address explicitly would allow the malicious user to hide his/her identity when sending notifications by email. Holst, Hastings [page 9] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 4.5 notify-charset (charset) This OPTIONAL READ-ONLY Subscription object attribute specifies the charset to be used in the Notification content sent to the Notification Recipient, whether the notification content is Machine Consumable or Human Consumable. The client MUST NOT supply and the Printer MUST NOT use this attribute when the MIME media type registration definition supplied in the "notify-format" attribute value allows the charset parameter in its MIME media type value, e.g., 'text/plain; charset=utf- 8'. 4.6 notify-natural-language (naturalLanguage) This OPTIONAL READ-ONLY Subscription object attribute specifies the natural language for the IPP object to use in the localized Notification content that is sent to the Notification Recipient, whether the notification content is Machine Consumable or Human Consumable. 4.7 request-id This REQUIRED READ-ONLY Subscription object attribute holds the most recent request-id sequence number delivered in a Notification content to the Notification Recipient. A value of 0 indicates that no Notifications have been sent for this subscription. The first request- id sent for a subscription MUST be 1. Each Notification Recipient has its own monotonically increasing series of request-ids, i.e., no gaps, in order to be able to detect a missing notification. 4.8 subscription-id (integer (1:MAX)) This REQUIRED READ-ONLY Subscription object attribute uniquely identifies this Subscription object instance on this Printer object or this Job object.. 4.9 notify-lease-expiration-time (integer(0:MAX)) This REQUIRED READ-ONLY Subscription object attribute specifies the time in the future when the subscription lease will expire, i.e., the "printer-up-time" value at which the lease will expire. 4.10printer-uri (uri) This REQUIRED READ-ONLY Subscription object attribute identifies the Printer object that created this Subscription object. Holst, Hastings [page 10] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 4.11subscriber-user-name (name(MAX)) This REQUIRED READ-ONLY Subscription object attribute contains the name of the user that created the Subscription object. The Printer includes the value of this attribute as the value of the SMTP "FROM" field outside the <> (see RFC 822 [rfc822] section 4.4.1). For the 'mailto:' notification delivery method, the client MUST supply the "requesting- user-name" operation attribute so that the Printer can populate the "subscriber-user-name" Subscription attribute, in case the Printer does not have a more authenticated printable name (see [ipp-ntfy]). If the client omits "requesting-user-name" attribute and the Printer doesn't have a more authenticated printable name, the Printer MUST either (1) reject the operation with the 'client-error-bad-request' or (2) ignore this Subscription, since the Printer will not have a User Display Name to put in the "From:" field outside the <>, depending on implementation. ISSUE 05: Ok that we made "subscriber-user-name" be REQUIRED for the Printer to support and indicate that the client MUST supply the "requester-user-name" operation attribute when the delivery method is 'mailto:', in case the Printer does not have a more authenticated printable name? 4.12notify-printer-up-time (integer(1:MAX)) This REQUIRED READ-ONLY Subscription object attribute indicates the amount of time (in seconds) that the Printer implementation has been up and running. The Printer includes the value of this attribute in both the Human Consumable and Machine Consumable forms. 4.13notify-persistence-granted (boolean) This REQUIRED Subscription object attribute whether or not the Per-Job or Per-Printer Subscription is persistent, i.e., saved across power cycles in an implementation-define manner. 5 Mail Notification Content The intent of the mail message is that the Notification Recipient is receiving a Human Consumable and/or Machine Consumable mail message from the Printer with the subject line indicating that it is a printer notification message and some implementation-defined salient information, such as the Job name and submitting user name. The body of the message duplicates this information and includes other information as REQUIRED by [ipp-ntfy]. Table 1 shows the SMPT fields that the IPP Printer MUST fill in from the indicated sources of the data. Holst, Hastings [page 11] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 Table 1 - SMTP Fields to be filled in SMTP RFC SMTP Subscription object attribute source for SNMP field 822 Field section Name 4.4.1 From: "printer-name" <"subscriber-user-data"> For example, if Bob Jones submits a print job to the Printer "George Washington" and his email address is jones@acme.com, the From: line will be displayed as: From: George Washington Mail messages appear to the Notification Recipient to come from the Printer, so that mail agents can sort and filter on the From: field. Note: The "printer-name" is the Mail Display name. And the "subscriber-user-data" inside <> is assumed to be an SMTP mail address so that the Notification Recipient can reply to the subscriber. For example, to say "I picked up your document, thanks." 4.4.2 Sender: "subscriber-user-name" <"subscriber-user-data"> For example, if Bob Jones submits a print job to the Printer "George Washington" and his email address is jones@acme.com, the Sender: line will be displayed as: Sender: Bob Jones Note: The "subscriber-user-name" is the Mail Display name (Bob Jones). And the "subscriber-user- data" inside <> is assumed to be an SMTP mail address so that the mail system will send failure to deliver mail messages to the mail address specified by the "subscriber-user-data", not the Printer. 4.5.1 To: The rest of the URI following the 'mailto:' scheme in the value of the "notify-recipient" attribute. 4.7.1 Subject: Implementation-dependent, but SHOULD start with "Printer message: " (localized) followed by the job or printer event name, job name, etc. The beginning of the Subject line is a standardized prefix, so that mail agents can filter from any Printer. The Printer MUST repeat any of this information in these fields in the body of the message, plus additional information REQUIRED by the Notification Specification [ipp-ntfy]. Holst, Hastings [page 12] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 5.1 Human Consumable Form If the format specified by the "notify-format" (mimeMediaType) is a Human Consumable form, then it MUST be sent as a MIME according to [rfc1341] and [rfc2046] if the MIME type is anything but 'text/plain'. Even 'text/plain; charset=utf-8' MUST be represented as a MIME type in the body of the message. ISSUE 06: What if "notify-format" is 'text/plain; charset=utf-8', does that have to be sent as a mail attachment, since it isn't 'text/plain' which assumes charset=us-ascii, or can it be sent as the body of the mail message properly identified as 'text/plain; charset=us-ascii'? 5.2 Machine Consumable Form If the format specified by the "notify-format" (mimeMediaType) is a Machine Consumable form, then it MUST be sent as a MIME attachment according to [rfc1341] and [rfc2046], including the 'application/ipp'. 6 Printer Description attributes specific to the 'mailto:' delivery method This section defines Printer Description attributes that are REQUIRED when supporting the 'mailto:' delivery method. 6.1 "printer-smtp-mail-service-address" (1setOf text(MAX)) This REQUIRED Printer Description attribute contains the DNS or IP address of the SMTP relaying mail server (see [rfc822]) that the Printer is to use to send mail messages when supporting the 'mailto:' delivery method. The System Administrator is expected to configure this attribute with one or more values. 7 Conformance Requirements If the IPP Printer supports the 'mailto:' notification delivery scheme, the Printer MUST meet these conformance requirements: 1.MUST meet the conformance requirements defined in [ipp-ntfy]. 2.MUST support at least the 'text/plain' Notification Content format. Being able to support any other MIME media types (MUST be sent as mail attachments) is OPTIONAL.. 3.MUST support the Subscription attribute semantics specified in section 4 when sending Notifications. 4.MUST fill in the SMTP fields in the mail message as specified in section 5. Holst, Hastings [page 13] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 5.MUST support the "printer-smtp-mail-service-address" (1setOf text(MAX)) Printer Description attribute defined in section 6. 8 IANA Considerations Since the 'mailto:' URL scheme is already defined in a standards track document and registered with IANA, this document does not require anything further of IANA. 9 Internationalization Considerations This notification delivery method presents no additional internationalization considerations already covered in the [ipp-ntfy] document. The IPP Printer MUST localize the Human Consumable format and the 'text' attributes in the Machine Consumable form. The Notification Recipient is expected to localize the attributes in the Machine Consumable that have the 'keyword' attribute syntax according to the charset and natural language supplied in the Notification Content which is derived from the Subscription object as supplied by the Subscriber. 10 Security Considerations By far the biggest security concern is the abuse of notification: sending unwanted notifications to third parties (i.e., spam). The problem is made worse by notification addresses that may be redistributed to multiple parties (e.g. mailing lists). There exist scenarios where third party notification is required (see Scenario #2 and #3 in [ipp-not-req]). The fully secure solution would require active agreement of all recipients before sending out anything. However, requirement #9 in [ipp-req] ("There is no requirement for IPP Printer receiving the print request to validate the identity of an event recipient") argues against this. Certain systems may decide to disallow third party notifications (a traditional facsimile model). Sometimes the Notification Recipient is not the same person as the person who created the Subscription. It is possible for the Notification Recipient to find out who created the Subscription, since the subscriber MUST supply the "subscriber-user-name" Subscription attribute in the Subscription Creation operation. The [ipp-ntfy] document discusses general security considerations for notifications. Some delivery methods, such as the 'ipp:' delivery method, avoid the spam problem because the Notification Recipient pulls the Notifications when desired. The 'indp:' [indp-method] delivery method allows the Notification Recipient to return a special status code reply to the IPP Printer Send-Notifications operation to cancel the subscription. The 'mailto:' delivery method does not permit either of these remedies. ISSUE 07 - Is there any way that a Notification Recipient could reply to the message in such a way as to cancel the subscription and thereby solve the spam problem? Holst, Hastings [page 14] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 Some firewall administrators are preventing mail attachments from being accepted into their organizations because of the problem of the attachments containing computer viruses. The 'mailto:' delivery method allows the subscriber to suppress sending any attachments, by specifying only the 'text/plain' MIME media type. 11 References [ipp-coll] deBry, R., , Hastings, T., Herriot, R., "Internet Printing Protocol/1.0 & 1.1: collection attribute syntax", , work in progress, September 9, 1999. [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", , June, 1999. [ipp-ntfy] Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP Event Notification Specification", , October 14, 1999. [ipp-pro] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 03.txt, June, 1999. [rfc821] Jonathan B. Postel, "Simple Mail Transfer Protocol", August, 1982. [rfc822] David H. Crocker, "Standard For The Format Of ARPA Internet Text Messages", August 13, 1982. [rfc1341] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", June, 1992. [rfc2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [rfc2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed & N. Borenstein. November 1996. (Obsoletes RFC1521, RFC1522, RFC1590), RFC 2046. Holst, Hastings [page 15] Expires: September 9, 2000 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 [rfc2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999. 12 Author's Addresses Henrik Holst i-data international a/s Vadstrupvej 35-43 2880 Bagsvaerd, Denmark Phone: +45 4436-6000 Fax: +45 4436-6111 e-mail: hh@i-data.com Tom Hastings Xerox Corporation 737 Hawaii St. ESAE 231 El Segundo, CA 90245 Phone: 310-333-6413 Fax: 310-333-5514 e-mail: hastings@cp10.es.xerox.com 13 Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Holst, Hastings [page 16] Expires: September 9, 2000