idnits 2.17.1 draft-ietf-ipp-notify-mailto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 10) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 35: '...on [ipp-ntfy] is an OPTIONAL extension...' RFC 2119 keyword, line 86: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 191: '...hat supports the OPTIONAL IPP notifica...' RFC 2119 keyword, line 226: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 227: '... NOT, MAY, NEED NOT, and OPTIONAL,...' (50 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 756 has weird spacing: '...for the purpo...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2000) is 8812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2567' on line 70 looks like a reference -- Missing reference section? 'RFC2568' on line 72 looks like a reference -- Missing reference section? 'RFC2569' on line 76 looks like a reference -- Missing reference section? 'RFC2616' on line 104 looks like a reference -- Missing reference section? 'RFC2119' on line 230 looks like a reference -- Missing reference section? 'RFC822' on line 282 looks like a reference -- Missing reference section? 'RFC821' on line 323 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 Henrik Holst 4 i-data international a/s 5 Tom Hastings 6 Xerox Corp. 7 March 9, 2000 9 Internet Printing Protocol (IPP): 10 The 'mailto:' Notification Delivery Method 12 Copyright (C) The Internet Society (2000). All Rights Reserved. 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of [rfc2026]. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed as 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The IPP notification specification [ipp-ntfy] is an OPTIONAL extension 36 to IPP/1.0 and IPP/1.1 that requires the definition of one or more 37 delivery methods for dispatching event notification reports to 38 Notification Recipients. This document describes the semantics and 39 syntax of the 'mailto:' event notification delivery method. For this 40 delivery method, the IPP Printer uses the SMTP mail protocol to send 41 (push) Human Consumable and/or Machine Consumable Notifications to 42 Notification Recipients. The Subscriber specifies the mail address 43 using the mailto: URL. This mail address can be any user or can be any 44 of the mail services defined to perform such notification using 45 parameters in the URL, such as paging. The Subscriber can specify the 46 MIME media type of both the Human Consumable and Machine Consumable 47 Notifications. The Subscriber can also specify a mail address in the 48 "subscriber-user-data" Subscription attribute to which the Notification 49 Recipient can reply and to which the mail system delivers undeliverable 50 mail messages. That mail address is usually the Subscribers mail 51 address, but can be any mail address. 53 The mail messages appear to come from the Printer, so that mail agents 54 can sort and filter on the From: field. Also the beginning of the 56 Expires: September 9, 2000 57 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 59 Subject line starts with the localized "Printer message: " prefix, so 60 that mail agents can filter from any Printer. 62 There are 7 ISSUES called out in the text. 64 Expires: September 9, 2000 66 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 68 The full set of IPP documents includes: 70 Design Goals for an Internet Printing Protocol [RFC2567] 71 Rationale for the Structure and Model and Protocol for the Internet 72 Printing Protocol [RFC2568] 73 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 74 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 75 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 76 Mapping between LPD and IPP Protocols [RFC2569] 77 Internet Printing Protocol (IPP): Event Notification Specification 78 [ipp-ntfy] 80 The "Design Goals for an Internet Printing Protocol" document takes a 81 broad look at distributed printing functionality, and it enumerates 82 real-life scenarios that help to clarify the features that need to be 83 included in a printing protocol for the Internet. It identifies 84 requirements for three types of users: end users, operators, and 85 administrators. It calls out a subset of end user requirements that are 86 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 87 added to IPP/1.1. 89 The "Rationale for the Structure and Model and Protocol for the Internet 90 Printing Protocol" document describes IPP from a high level view, 91 defines a roadmap for the various documents that form the suite of IPP 92 specification documents, and gives background and rationale for the IETF 93 working group's major decisions. 95 The "Internet Printing Protocol/1.1: Model and Semantics" document 96 describes a simplified model with abstract objects, their attributes, 97 and their operations that are independent of encoding and transport. It 98 introduces a Printer and a Job object. The Job object optionally 99 supports multiple documents per Job. It also addresses security, 100 internationalization, and directory issues. 102 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 103 a formal mapping of the abstract operations and attributes defined in 104 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 105 rules for a new Internet MIME media type called "application/ipp". This 106 document also defines the rules for transporting over HTTP a message 107 body whose Content-Type is "application/ipp". This document defines a 108 new scheme named 'ipp' for identifying IPP printers and jobs. 110 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 111 insight and advice to implementers of IPP clients and IPP objects. It 112 is intended to help them understand IPP/1.1 and some of the 113 considerations that may assist them in the design of their client and/or 114 IPP object implementations. For example, a typical order of processing 115 requests is given, including error checking. Motivation for some of the 116 specification decisions is also included. 118 The "Mapping between LPD and IPP Protocols" document gives some advice 119 to implementers of gateways between IPP and LPD (Line Printer Daemon) 120 implementations. 122 Expires: September 9, 2000 123 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 125 The "Event Notification Specification" document extends the Job Creation 126 operations and defines additional operations that allow a client to 127 subscribe to printing related events. Subscriptions are modeled as 128 Subscription objects which can be Per-Job or Per-Printer Subscriptions. 129 Additional operations are defined to query, renew, and cancel 130 Subscription objects. 132 Expires: September 9, 2000 133 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 135 Table of Contents 137 1 Introduction......................................................6 139 2 Terminology.......................................................6 140 2.1Conformance Terminology..........................................6 141 2.2Other terminology................................................7 143 3 Model and Operation...............................................7 145 4 Sending Notifications.............................................8 146 4.1notify-recipient (uri)...........................................8 147 4.2notify-events (1setOf type2 keyword).............................8 148 4.3notify-format (mimeMediaType)....................................9 149 4.4subscriber-user-data (octetString(63))...........................9 150 4.5notify-charset (charset)........................................10 151 4.6notify-natural-language (naturalLanguage).......................10 152 4.7request-id......................................................10 153 4.8subscription-id (integer (1:MAX))...............................10 154 4.9notify-lease-expiration-time (integer(0:MAX))...................10 155 4.10 printer-uri (uri).............................................10 156 4.11 subscriber-user-name (name(MAX))..............................11 157 4.12 notify-printer-up-time (integer(1:MAX)).......................11 158 4.13 notify-persistence-granted (boolean)..........................11 160 5 Mail Notification Content........................................11 161 5.1Human Consumable Form...........................................13 162 5.2Machine Consumable Form.........................................13 164 6 Printer Description attributes specific to the 'mailto:' delivery 165 method...............................................................13 166 6.1"printer-smtp-mail-service-address" (1setOf text(MAX))..........13 168 7 Conformance Requirements.........................................13 170 8 IANA Considerations..............................................14 172 9 Internationalization Considerations..............................14 174 10 Security Considerations..........................................14 176 11 References.......................................................15 178 12 Author's Addresses...............................................16 180 13 Full Copyright Statement.........................................16 182 Table of Tables 184 Table 1 - SMTP Fields to be filled in................................12 186 Expires: September 9, 2000 187 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 189 1 Introduction 191 An IPP Printer that supports the OPTIONAL IPP notification extension 192 [ipp-ntfy] is called a Notification Source which sends event 193 Notifications to Notification Recipients. As such, a Printer either a) 194 accepts, stores, and uses notification Subscription objects to generate 195 event Notification reports and implement one or more delivery methods 196 for notifying interested parties, or b) supports a subset of these tasks 197 and farms out the remaining tasks to a Notification Delivery Service. 198 This document describes the semantics and syntax of the 'mailto:' event 199 notification delivery method. Such a Notification Delivery Service then 200 delivers the event Notification to the Ultimate Notification Recipient. 202 For this delivery method, the IPP Printer uses the SMTP mail protocol to 203 send (push) Human Consumable and/or Machine Consumable Notifications to 204 Notification Recipients. The Subscriber specifies the mail address 205 using the mailto: URL. This mail address can be any user or can be any 206 of the mail services defined to perform such notification using 207 parameters in the URL, such as paging. The Subscriber can specify the 208 MIME media type of both the Human Consumable and Machine Consumable 209 Notifications. The Subscriber can also specify a mail address in the 210 "subscriber-user-data" Subscription attribute to which the Notification 211 Recipient can reply and to which the mail system delivers undeliverable 212 mail messages. That mail address is usually the Subscribers mail 213 address, but can be any mail address. 215 The mail messages appear to come from the Printer, so that mail agents 216 can sort and filter on the From: field. Also the beginning of the 217 Subject line starts with the localized "Printer message: " prefix, so 218 that mail agents can filter from any Printer. 220 2 Terminology 222 This section defines terminology used throughout this document: 224 2.1 Conformance Terminology 226 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 227 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 228 conformance to this specification. These terms are defined in 229 [ipp-mod section 13.1 on conformance terminology, most of which is 230 taken from RFC 2119 [RFC2119]. 231 REQUIRED - an adjective used to indicate that a conforming IPP 232 Printer implementation MUST support the indicated operation, 233 object, attribute, attribute value, status code, or out-of-band 234 value in requests and responses. See [ipp-mod] "Appendix A - 235 Terminology for a definition of "support". Since support of this 236 entire notification specification is OPTIONAL for conformance to 237 IPP/1.0 or IPP/1.1, the use of the term REQUIRED in this document 239 Expires: September 9, 2000 241 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 243 means "REQUIRED if this OPTIONAL notification specification is 244 implemented". 245 OPTIONAL - an adjective used to indicate that a conforming IPP 246 Printer implementation MAY, but is NOT REQUIRED to, support the 247 indicated operation, object, attribute, attribute value, status 248 code, or out-of-band value in requests and responses. 250 2.2 Other terminology 252 Event Notification (Notification for short) - See [ipp-ntfy] 253 Notification Source - See [ipp-ntfy] 254 Notification Recipient - See [ipp-ntfy] 255 Subscription object - See [ipp-ntfy] 256 Ultimate Notification Recipient - See [ipp-ntfy] 258 3 Model and Operation 260 In the IPP Notification Model [ipp-ntfy], a client is able to: 262 1. supply one or more Per-Job Subscriptions in the Job Creation 263 operation 265 2. OPTIONALLY supply Per-Job Subscriptions as subsequent Create-Job- 266 Subscription operations 268 3. supply one Per-Printer Subscription in the Create-Printer- 269 Subscription operation. The client that creates these Subscription 270 objects becomes the owner of the Subscription object. 272 The client that creates these Subscription objects becomes the owner of 273 the Subscription object. 275 When creating each Subscription object, the client supplies the "notify- 276 recipient" (uri) attribute. The "notify-recipient" attribute specifies 277 both a single Notification Recipient that is to receive the 278 Notifications when subsequent events occur and the method for 279 Notification delivery that the IPP Printer is to use. For the 'mailto:' 280 Notification delivery method defined in this document, the "notify- 281 recipient" consists of the 'mailto:' scheme followed by an SMPT mail 282 address [RFC822]. 284 Notification Sources that implement the 'mailto:' event notification 285 delivery method will need to include an SMTP mail agent while 286 Notification Recipients that implement this delivery method will need to 287 support an SMTP server. ISSUE 01: Is this SMTP terminology correct? 289 The IPP Printer can be the Notification Source or could use some other 290 Notification Delivery Service that actually delivers the mail message. 291 In this latter case, the protocol between the IPP Printer and the 292 Notification Delivery Service is implementation defined and could be the 293 INDP protocol (see [indp]). 295 Expires: September 9, 2000 296 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 298 Also the Notification Recipient specified by the "notify-recipient" 299 Subscription attribute can be either (1) the Ultimate Notification 300 Recipient or can be a Notification Delivery Service, such as a paging 301 system that accept 'mailto:' parameters to indicate the Ultimate 302 Notification Recipient, such as a phone number or paging subscriber's 303 id. 305 4 Sending Notifications 307 This section defines the processing that the IPP Printer MUST perform 308 when sending an event Notification using the 'mailto:' delivery method. 309 The usage of each of the Subscription object attributes defined in [ipp- 310 ntfy] is described here as it applies to the 'mailto:' delivery method. 311 The description of each Subscription attribute in this document is not 312 the complete description, but is just the application of the attribute 313 to this 'mailto:' delivery method. See the complete definition of each 314 Subscription object attribute in [ipp-ntfy]. ISSUE 02: Is it a good 315 idea to list each Subscription object attribute in this spec with the 316 applicability to this delivery method? If yes, should all delivery 317 method specs also do it this way? Section 5 defines how the IPP Printer 318 populates the SMTP fields in the mail message. 320 4.1 notify-recipient (uri) 322 This REQUIRED READ-ONLY Subscription object attribute contain the 323 'mailto:' URI delivery method followed by the SMTP mail address [RFC821] 324 of the Notification Recipient. As required by the [ipp-ntfy] document, 325 the following information is given for this notification delivery 326 method: 328 ISSUE 03 - What should we say about any mailto parameters, if any? For 329 example, if you want to send over secure mail, etc. 331 ISSUE 04 - Do we want to define any IPP-specific mailto parameters to 332 this document? 334 4.2 notify-events (1setOf type2 keyword) 336 This REQUIRED READ-ONLY Subscription object attribute identifies the job 337 and/or printer events that are to be delivered to the Notification 338 Recipient as Notifications as defined in [ipp-ntfy] section 7. 340 Note: Some rapidly recurring events, such as page events, are not 341 appropriate to use with this delivery method, especially if the 342 recipient mail address is a mailing list. Implementations MAY choose 343 either not to support page events with the 'mailto:' delivery method 344 and/or not permit a mailing list to be supplied, if they can detect that 345 a mail address is a mailing list. 347 Expires: September 9, 2000 348 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 350 4.3 notify-format (mimeMediaType) 352 This REQUIRED READ-ONLY Subscription object attribute indicates the type 353 of Human Consumable and/or Machine Consumable format content that is to 354 be sent in the Notifications as a mail message attachment. For the 355 'mailto:' delivery method, any registered 'mimeMediaType' value is 356 allowed, including types that allow pictures to be represented, e.g., 357 'application/postscript' or 'image/tiff', and/or sounds to be 358 represented, e.g., 'audio/32kadpcm'. The body of the mail message MUST 359 always be 'text/plain; charset=us-ascii, since that is the default for 360 'mailto:'. 362 There is no "notify-default" Printer attribute to configure. If the 363 client did not supply the "notify-format" attribute in the Subscription 364 Creation operation, the Printer MUST populate this attribute with an 365 implementation-defined default value. Such a default value MAY include 366 multi-part mixed media, so that the Printer can send multi-part mixed 367 MIME type attachments by default (though there is no way for the client 368 to explicitly request such). If the out-of-band 'none' value [ipp-col] 369 was supplied in the Subscription Creation operation, the Printer MUST 370 NOT send any attachment in the Notification. 372 If the MIME media type registration definition permits a charset 373 parameter, than the client MUST use such a specification (instead of the 374 "notify-charset" attribute) in order to indicate the charset to be used 375 in the Notification content. 377 4.4 subscriber-user-data (octetString(63)) 379 This REQUIRED READ-ONLY Subscription object attribute holds an SMTP mail 380 address value that the Printer copies to the "From:" inside <> (see RFC 381 822 [rfc822] section 4.4.1) and the "Sender:" SMTP fields (see section 382 5). For the 'mailto:' notification delivery method, the client MUST 383 supply the "subscriber-user-data" attribute. If the client omits this 384 attribute, the Printer MUST either (1) reject the operation with the 385 'client-error-bad-request' or (2) ignore this Subscription, since the 386 Printer will not have a mail address to put in the "From:" and in the 387 "Sender:" SMTP fields, depending on implementation. 389 When the subscribing user selects the 'mailto:' delivery scheme, the 390 client SHOULD obtain the user's mail address automatically from the 391 client system (in an implementation-dependent manner) and supply it as 392 the value of the "subscriber-user-data" attribute by default, rather 393 than require the user to explicitly supply it. Allowing users to supply 394 the mail address explicitly would allow the malicious user to hide 395 his/her identity when sending notifications by email. 397 Expires: September 9, 2000 398 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 400 4.5 notify-charset (charset) 402 This OPTIONAL READ-ONLY Subscription object attribute specifies the 403 charset to be used in the Notification content sent to the Notification 404 Recipient, whether the notification content is Machine Consumable or 405 Human Consumable. The client MUST NOT supply and the Printer MUST NOT 406 use this attribute when the MIME media type registration definition 407 supplied in the "notify-format" attribute value allows the charset 408 parameter in its MIME media type value, e.g., 'text/plain; charset=utf- 409 8'. 411 4.6 notify-natural-language (naturalLanguage) 413 This OPTIONAL READ-ONLY Subscription object attribute specifies the 414 natural language for the IPP object to use in the localized Notification 415 content that is sent to the Notification Recipient, whether the 416 notification content is Machine Consumable or Human Consumable. 418 4.7 request-id 420 This REQUIRED READ-ONLY Subscription object attribute holds the most 421 recent request-id sequence number delivered in a Notification content to 422 the Notification Recipient. A value of 0 indicates that no 423 Notifications have been sent for this subscription. The first request- 424 id sent for a subscription MUST be 1. Each Notification Recipient has 425 its own monotonically increasing series of request-ids, i.e., no gaps, 426 in order to be able to detect a missing notification. 428 4.8 subscription-id (integer (1:MAX)) 430 This REQUIRED READ-ONLY Subscription object attribute uniquely 431 identifies this Subscription object instance on this Printer object or 432 this Job object.. 434 4.9 notify-lease-expiration-time (integer(0:MAX)) 436 This REQUIRED READ-ONLY Subscription object attribute specifies the time 437 in the future when the subscription lease will expire, i.e., the 438 "printer-up-time" value at which the lease will expire. 440 4.10printer-uri (uri) 442 This REQUIRED READ-ONLY Subscription object attribute identifies the 443 Printer object that created this Subscription object. 445 Expires: September 9, 2000 446 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 448 4.11subscriber-user-name (name(MAX)) 450 This REQUIRED READ-ONLY Subscription object attribute contains the name 451 of the user that created the Subscription object. The Printer includes 452 the value of this attribute as the value of the SMTP "FROM" field 453 outside the <> (see RFC 822 [rfc822] section 4.4.1). For the 'mailto:' 454 notification delivery method, the client MUST supply the "requesting- 455 user-name" operation attribute so that the Printer can populate the 456 "subscriber-user-name" Subscription attribute, in case the Printer does 457 not have a more authenticated printable name (see [ipp-ntfy]). If the 458 client omits "requesting-user-name" attribute and the Printer doesn't 459 have a more authenticated printable name, the Printer MUST either (1) 460 reject the operation with the 'client-error-bad-request' or (2) ignore 461 this Subscription, since the Printer will not have a User Display Name 462 to put in the "From:" field outside the <>, depending on implementation. 464 ISSUE 05: Ok that we made "subscriber-user-name" be REQUIRED for the 465 Printer to support and indicate that the client MUST supply the 466 "requester-user-name" operation attribute when the delivery method is 467 'mailto:', in case the Printer does not have a more authenticated 468 printable name? 470 4.12notify-printer-up-time (integer(1:MAX)) 472 This REQUIRED READ-ONLY Subscription object attribute indicates the 473 amount of time (in seconds) that the Printer implementation has been up 474 and running. The Printer includes the value of this attribute in both 475 the Human Consumable and Machine Consumable forms. 477 4.13notify-persistence-granted (boolean) 479 This REQUIRED Subscription object attribute whether or not the Per-Job 480 or Per-Printer Subscription is persistent, i.e., saved across power 481 cycles in an implementation-define manner. 483 5 Mail Notification Content 485 The intent of the mail message is that the Notification Recipient is 486 receiving a Human Consumable and/or Machine Consumable mail message from 487 the Printer with the subject line indicating that it is a printer 488 notification message and some implementation-defined salient 489 information, such as the Job name and submitting user name. The body of 490 the message duplicates this information and includes other information 491 as REQUIRED by [ipp-ntfy]. 493 Table 1 shows the SMPT fields that the IPP Printer MUST fill in from the 494 indicated sources of the data. 496 Expires: September 9, 2000 497 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 499 Table 1 - SMTP Fields to be filled in 501 SMTP RFC SMTP Subscription object attribute source for SNMP field 502 822 Field 503 section Name 505 4.4.1 From: "printer-name" <"subscriber-user-data"> 507 For example, if Bob Jones submits a print job to the 508 Printer "George Washington" and his email address is 509 jones@acme.com, the From: line will be displayed as: 511 From: George Washington 513 Mail messages appear to the Notification Recipient 514 to come from the Printer, so that mail agents can 515 sort and filter on the From: field. 517 Note: The "printer-name" is the Mail Display name. 518 And the "subscriber-user-data" inside <> is assumed 519 to be an SMTP mail address so that the Notification 520 Recipient can reply to the subscriber. For example, 521 to say "I picked up your document, thanks." 523 4.4.2 Sender: "subscriber-user-name" <"subscriber-user-data"> 525 For example, if Bob Jones submits a print job to the 526 Printer "George Washington" and his email address is 527 jones@acme.com, the Sender: line will be displayed 528 as: 530 Sender: Bob Jones 532 Note: The "subscriber-user-name" is the Mail 533 Display name (Bob Jones). And the "subscriber-user- 534 data" inside <> is assumed to be an SMTP mail 535 address so that the mail system will send failure to 536 deliver mail messages to the mail address specified 537 by the "subscriber-user-data", not the Printer. 539 4.5.1 To: The rest of the URI following the 'mailto:' scheme 540 in the value of the "notify-recipient" attribute. 542 4.7.1 Subject: Implementation-dependent, but SHOULD start with 543 "Printer message: " (localized) followed by the job 544 or printer event name, job name, etc. The beginning 545 of the Subject line is a standardized prefix, so 546 that mail agents can filter from any Printer. 548 The Printer MUST repeat any of this information in these fields in the 549 body of the message, plus additional information REQUIRED by the 550 Notification Specification [ipp-ntfy]. 552 Expires: September 9, 2000 553 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 555 5.1 Human Consumable Form 557 If the format specified by the "notify-format" (mimeMediaType) is a 558 Human Consumable form, then it MUST be sent as a MIME according to 559 [rfc1341] and [rfc2046] if the MIME type is anything but 'text/plain'. 560 Even 'text/plain; charset=utf-8' MUST be represented as a MIME type in 561 the body of the message. 563 ISSUE 06: What if "notify-format" is 'text/plain; charset=utf-8', does 564 that have to be sent as a mail attachment, since it isn't 'text/plain' 565 which assumes charset=us-ascii, or can it be sent as the body of the 566 mail message properly identified as 'text/plain; charset=us-ascii'? 568 5.2 Machine Consumable Form 570 If the format specified by the "notify-format" (mimeMediaType) is a 571 Machine Consumable form, then it MUST be sent as a MIME attachment 572 according to [rfc1341] and [rfc2046], including the 'application/ipp'. 574 6 Printer Description attributes specific to the 'mailto:' delivery 575 method 577 This section defines Printer Description attributes that are REQUIRED 578 when supporting the 'mailto:' delivery method. 580 6.1 "printer-smtp-mail-service-address" (1setOf text(MAX)) 582 This REQUIRED Printer Description attribute contains the DNS or IP 583 address of the SMTP relaying mail server (see [rfc822]) that the Printer 584 is to use to send mail messages when supporting the 'mailto:' delivery 585 method. The System Administrator is expected to configure this 586 attribute with one or more values. 588 7 Conformance Requirements 590 If the IPP Printer supports the 'mailto:' notification delivery scheme, 591 the Printer MUST meet these conformance requirements: 593 1.MUST meet the conformance requirements defined in [ipp-ntfy]. 595 2.MUST support at least the 'text/plain' Notification Content format. 596 Being able to support any other MIME media types (MUST be sent as 597 mail attachments) is OPTIONAL.. 599 3.MUST support the Subscription attribute semantics specified in 600 section 4 when sending Notifications. 602 4.MUST fill in the SMTP fields in the mail message as specified in 603 section 5. 605 Expires: September 9, 2000 607 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 609 5.MUST support the "printer-smtp-mail-service-address" (1setOf 610 text(MAX)) Printer Description attribute defined in section 6. 612 8 IANA Considerations 614 Since the 'mailto:' URL scheme is already defined in a standards track 615 document and registered with IANA, this document does not require 616 anything further of IANA. 618 9 Internationalization Considerations 620 This notification delivery method presents no additional 621 internationalization considerations already covered in the [ipp-ntfy] 622 document. The IPP Printer MUST localize the Human Consumable format and 623 the 'text' attributes in the Machine Consumable form. The Notification 624 Recipient is expected to localize the attributes in the Machine 625 Consumable that have the 'keyword' attribute syntax according to the 626 charset and natural language supplied in the Notification Content which 627 is derived from the Subscription object as supplied by the Subscriber. 629 10 Security Considerations 631 By far the biggest security concern is the abuse of notification: 632 sending unwanted notifications to third parties (i.e., spam). The 633 problem is made worse by notification addresses that may be 634 redistributed to multiple parties (e.g. mailing lists). There exist 635 scenarios where third party notification is required (see Scenario #2 636 and #3 in [ipp-not-req]). The fully secure solution would require 637 active agreement of all recipients before sending out anything. 638 However, requirement #9 in [ipp-req] ("There is no requirement for IPP 639 Printer receiving the print request to validate the identity of an event 640 recipient") argues against this. Certain systems may decide to disallow 641 third party notifications (a traditional facsimile model). 643 Sometimes the Notification Recipient is not the same person as the 644 person who created the Subscription. It is possible for the 645 Notification Recipient to find out who created the Subscription, since 646 the subscriber MUST supply the "subscriber-user-name" Subscription 647 attribute in the Subscription Creation operation. 649 The [ipp-ntfy] document discusses general security considerations for 650 notifications. Some delivery methods, such as the 'ipp:' delivery 651 method, avoid the spam problem because the Notification Recipient pulls 652 the Notifications when desired. The 'indp:' [indp-method] delivery 653 method allows the Notification Recipient to return a special status code 654 reply to the IPP Printer Send-Notifications operation to cancel the 655 subscription. The 'mailto:' delivery method does not permit either of 656 these remedies. 658 ISSUE 07 - Is there any way that a Notification Recipient could reply to 659 the message in such a way as to cancel the subscription and thereby 660 solve the spam problem? 662 Expires: September 9, 2000 663 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 665 Some firewall administrators are preventing mail attachments from being 666 accepted into their organizations because of the problem of the 667 attachments containing computer viruses. The 'mailto:' delivery method 668 allows the subscriber to suppress sending any attachments, by specifying 669 only the 'text/plain' MIME media type. 671 11 References 673 [ipp-coll] 674 deBry, R., , Hastings, T., Herriot, R., "Internet Printing 675 Protocol/1.0 & 1.1: collection attribute syntax", , work in progress, September 9, 1999. 678 [ipp-mod] 679 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 680 "Internet Printing Protocol/1.0: Model and Semantics", , June, 1999. 683 [ipp-ntfy] 684 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 685 Bergman, R., "Internet Printing Protocol/1.1: IPP Event 686 Notification Specification", , 687 October 14, 1999. 689 [ipp-pro] 690 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 691 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 692 03.txt, June, 1999. 694 [rfc821] 695 Jonathan B. Postel, "Simple Mail Transfer Protocol", August, 1982. 697 [rfc822] 698 David H. Crocker, "Standard For The Format Of ARPA Internet Text 699 Messages", August 13, 1982. 701 [rfc1341] 702 N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 703 Extensions): Mechanisms for Specifying and Describing the Format of 704 Internet Message Bodies", June, 1992. 706 [rfc2026] 707 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 708 2026, October 1996. 710 [rfc2046] 711 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. 712 N. Freed & N. Borenstein. November 1996. (Obsoletes RFC1521, 713 RFC1522, RFC1590), RFC 2046. 715 Expires: September 9, 2000 717 INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00 719 [rfc2616] 720 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 721 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 722 RFC 2616, June 1999. 724 12 Author's Addresses 726 Henrik Holst 727 i-data international a/s 728 Vadstrupvej 35-43 729 2880 Bagsvaerd, Denmark 731 Phone: +45 4436-6000 732 Fax: +45 4436-6111 733 e-mail: hh@i-data.com 735 Tom Hastings 736 Xerox Corporation 737 737 Hawaii St. ESAE 231 738 El Segundo, CA 90245 740 Phone: 310-333-6413 741 Fax: 310-333-5514 742 e-mail: hastings@cp10.es.xerox.com 744 13 Full Copyright Statement 746 Copyright (C) The Internet Society (2000). All Rights Reserved. 748 This document and translations of it may be copied and furnished to 749 others, and derivative works that comment on or otherwise explain it or 750 assist in its implementation may be prepared, copied, published and 751 distributed, in whole or in part, without restriction of any kind, 752 provided that the above copyright notice and this paragraph are included 753 on all such copies and derivative works. However, this document itself 754 may not be modified in any way, such as by removing the copyright notice 755 or references to the Internet Society or other Internet organizations, 756 except as needed for the purpose of developing Internet standards in 757 which case the procedures for copyrights defined in the Internet 758 Standards process must be followed, or as required to translate it into 759 languages other than English. 761 The limited permissions granted above are perpetual and will not be 762 revoked by the Internet Society or its successors or assigns. 764 This document and the information contained herein is provided on an "AS 765 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 766 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 767 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 768 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 769 FITNESS FOR A PARTICULAR PURPOSE. 771 Expires: September 9, 2000