idnits 2.17.1 draft-ietf-ipp-notify-mailto-01.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 23 longer pages, the longest (page 12) being 69 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 82: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 238: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 239: '...Y, NEED NOT, and OPTIONAL, have specia...' RFC 2119 keyword, line 259: '...A Printer MUST support SMTP [RFC821], and it MAY support other email...' RFC 2119 keyword, line 260: '...ocols. A Printer MAY use additional se...' (72 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 785 has weird spacing: '...xt-only tru...' == Line 789 has weird spacing: '...anguage en-...' == Line 842 has weird spacing: '...xt-only tru...' == Line 846 has weird spacing: '...anguage en-...' == Line 898 has weird spacing: '...xt-only tru...' == (2 more instances...) -- 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 (July 7, 2000) is 8666 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: 'RFC2567' is mentioned on line 66, but not defined == Missing Reference: 'RFC2568' is mentioned on line 68, but not defined == Missing Reference: 'RFC2569' is mentioned on line 72, but not defined == Missing Reference: 'RFC2119' is mentioned on line 242, but not defined == Missing Reference: 'RFC 822' is mentioned on line 455, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RFC 1521' is mentioned on line 581, but not defined ** Obsolete undefined reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Missing Reference: 'RFC 2368' is mentioned on line 968, but not defined ** Obsolete undefined reference: RFC 2368 (Obsoleted by RFC 6068) == Unused Reference: 'RFC822' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC1341' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC1521' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'RFC2368' is defined on line 1078, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2616 (ref. 'RFC2046') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Duplicate reference: RFC2616, mentioned in 'RFC2368', was also mentioned in 'RFC2046'. ** Obsolete normative reference: RFC 2616 (ref. 'RFC2368') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Duplicate reference: RFC2616, mentioned in 'RFC2616', was also mentioned in 'RFC2368'. ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2633 (Obsoleted by RFC 3851) Summary: 19 errors (**), 0 flaws (~~), 21 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 Robert Herriot 3 Xerox Corp. 4 Henrik Holst 5 i-data international a/s 6 Tom Hastings 7 Xerox Corp. 8 Carl-Uno Manros 9 Xerox Corp. 10 July 7, 2000 12 Internet Printing Protocol (IPP): 13 The 'mailto:' Notification Delivery Method 15 Copyright (C) The Internet Society (2000). All Rights Reserved. 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, and 22 its working groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed as 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The notification extension document [ipp-ntfy] defines operations that a 39 client can perform in order to create Subscription Objects in a Printer 40 and carry out other operations on them. The Subscription Object 41 specifies that when one of the specified Events occurs, the Printer 42 sends an asynchronous Event Notification to the specified Notification 43 Recipient via the specified Delivery Method (i.e., protocol). 45 The notification extension document [ipp-ntfy] specifies that each 46 Delivery Method is defined in another document. This document is one 47 such document, and it specifies the 'mailto' delivery method. 49 For this Delivery Method, when an Event occurs, the Printer immediately 50 sends an Event Notification via an email message to the Notification 51 Recipient specified in the Subscription Object. The message body of the 52 email consists of Human Consumable text and is not intended to be parsed 53 by a machine. 55 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 56 2000 58 The Notification Recipient receives the Event Notification in the same 59 way as it receives any other email message. 61 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 62 2000 64 The full set of IPP documents includes: 66 Design Goals for an Internet Printing Protocol [RFC2567] 67 Rationale for the Structure and Model and Protocol for the Internet 68 Printing Protocol [RFC2568] 69 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 70 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 71 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 72 Mapping between LPD and IPP Protocols [RFC2569] 73 Internet Printing Protocol (IPP): IPP Event Notification 74 Specification [ipp-ntfy] 76 The "Design Goals for an Internet Printing Protocol" document takes a 77 broad look at distributed printing functionality, and it enumerates 78 real-life scenarios that help to clarify the features that need to be 79 included in a printing protocol for the Internet. It identifies 80 requirements for three types of users: end users, operators, and 81 administrators. It calls out a subset of end user requirements that are 82 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 83 added to IPP/1.1. 85 The "Rationale for the Structure and Model and Protocol for the Internet 86 Printing Protocol" document describes IPP from a high level view, 87 defines a roadmap for the various documents that form the suite of IPP 88 specification documents, and gives background and rationale for the IETF 89 working group's major decisions. 91 The "Internet Printing Protocol/1.1: Model and Semantics" document 92 describes a simplified model with abstract objects, their attributes, 93 and their operations that are independent of encoding and transport. It 94 introduces a Printer and a Job object. The Job object optionally 95 supports multiple documents per Job. It also addresses security, 96 internationalization, and directory issues. 98 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 99 a formal mapping of the abstract operations and attributes defined in 100 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 101 rules for a new Internet MIME media type called "application/ipp". This 102 document also defines the rules for transporting over HTTP a message 103 body whose Content-Type is "application/ipp". This document also 104 defines a new scheme named 'ipp' for identifying IPP printers and jobs. 106 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 107 insight and advice to implementers of IPP clients and IPP objects. It 108 is intended to help them understand IPP/1.1 and some of the 109 considerations that may assist them in the design of their client and/or 110 IPP object implementations. For example, a typical order of processing 111 requests is given, including error checking. Motivation for some of the 112 specification decisions is also included. 114 The "Mapping between LPD and IPP Protocols" document gives some advice 115 to implementers of gateways between IPP and LPD (Line Printer Daemon) 116 implementations. 118 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 119 2000 121 The "Event Notification Specification" document describes an extension 122 to the IPP/1.0, IPP/1.1, and future versions. This extension allows a 123 client to subscribe to printing related Events. The Subscription Object 124 specifies that when one of the specified Event occurs, the Printer sends 125 an asynchronous Event Notification to the specified Notification 126 Recipient via the specified Delivery Method (i.e., protocol). A client 127 associates Subscription Objects with a particular Job by performing the 128 Create-Job-Subscriptions operation or by submitting a Job with 129 subscription information. A client associates Subscription Objects with 130 the Printer by performing a Create-Printer-Subscriptions operation. 131 Four other operations are defined for Subscription Objects: Get- 132 Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and 133 Cancel-Subscription. 135 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 136 2000 138 Table of Contents 140 1 Introduction......................................................7 142 2 Terminology.......................................................7 144 3 Model and Operation...............................................7 146 4 General Information...............................................8 148 5 Subscription Template Attributes..................................9 149 5.1 Additional Subscription Template Attributes.....................9 150 5.1.1 notify-mailto-text-only (boolean)9 151 5.2 Additional Information about Subscription Template Attributes..10 152 5.2.1 notify-recipient-uri (uri).................................10 153 5.2.2 notify-user-data (octetString(63)).........................10 155 6 Event Notification Content.......................................11 156 6.1 Headers........................................................11 157 6.1.1 'Date' header..............................................11 158 6.1.2 'From' header..............................................11 159 6.1.3 'Subject' header...........................................12 160 6.1.4 'Sender' header............................................12 161 6.1.5 'Reply-to' header..........................................12 162 6.1.6 'To' header................................................13 163 6.1.7 'Content-type' header......................................13 164 6.2 Message Body...................................................13 165 6.2.1 Information in Event Notification Content Common to All Events 166 .............................................................14 167 6.2.2 Additional Information in Event Notification Content for Job 168 Events...........................................................15 169 6.2.3 Additional Information in Event Notification Content for 170 Printer Events...................................................16 171 6.3 Examples.......................................................16 172 6.3.1 Job Event Example..........................................16 173 6.3.2 Printer Event Example......................................18 174 6.3.3 Printer Event Example (localized to French)...............19 176 7 Conformance Requirements.........................................20 178 8 IANA Considerations..............................................20 180 9 Internationalization Considerations..............................20 182 10 Security Considerations..........................................20 184 11 References.......................................................21 186 12 Author's Addresses...............................................22 188 13 Full Copyright Statement.........................................23 190 Table of Tables 192 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 193 2000 195 Table 1 . Printer Name in Event Notification Content.................15 197 Table 2 . Event Name in Event Notification Content 15 199 Table 4 . Job Name in Event Notification Content for Job Events......15 201 Table 5 . Job State in Event Notification Content for Job Events.....16 203 Table 6 . Printer State in Event Notification Content for Printer Events 204 .................................................................16 206 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 207 2000 209 1 Introduction 211 The notification extension document [ipp-ntfy] defines operations that a 212 client can perform in order to create Subscription Objects in a Printer 213 and carry out other operations on them. A Subscription Object represents 214 a Subscription abstraction. The Subscription Object specifies that when 215 one of the specified Events occurs, the Printer sends an asynchronous 216 Event Notification to the specified Notification Recipient via the 217 specified Delivery Method (i.e., protocol). 219 The notification extension document [ipp-ntfy] specifies that each 220 Delivery Method is defined in another document. This document is one 221 such document, and it specifies the 'mailto' delivery method. 223 For this Delivery Method, when an Event occurs, the Printer immediately 224 sends an Event Notification via an email message to the Notification 225 Recipient specified in the Subscription Object. The message body of the 226 email consists of Human Consumable text and is not intended to be parsed 227 by a machine. The 'mailto' Delivery Method is a 'push' Delivery Method 228 as defined in [ipp-ntfy]. 230 The Notification Recipient receives the Event Notification in the same 231 way as it receives any other email message. 233 2 Terminology 235 This section defines the following terms that are used throughout this 236 document: 238 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 239 MAY, NEED NOT, and OPTIONAL, have special meaning relating to 240 conformance to this specification. These terms are defined in [ipp-mod 241 section 13.1 on conformance terminology, most of which is taken from RFC 242 2119 [RFC2119]. 244 For capitalized terms that appear in this document, see [ipp-ntfy]. 246 3 Model and Operation 248 In a Subscription Creation Operation, when the value of the "notify- 249 recipient-uri" attribute contains the scheme "mailto", the client is 250 requesting that the Printer use the 'mailto' Delivery Method for Event 251 Notifications generated from the new Subscription Object. 253 For this Delivery Method, the "notify-recipient-uri" attribute value 254 MUST consist of a "mailto" scheme followed by a colon, and then followed 255 by an address part (e.g. 'mailto:smith@abc.com'). See section 5.2.1 for 256 the syntax of the "notify-recipient-uri" attribute value for this 257 Delivery Method. 259 A Printer MUST support SMTP [RFC821], and it MAY support other email 260 protocols. A Printer MAY use additional services, such as SMTP delivery 261 status notification [RFC1891] or S/MIME encryption [RFC2633]. 263 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 264 2000 266 If the client wants the Printer to send Event Notifications via the 267 'mailto' Delivery Method, the client MUST choose a value for "notify- 268 recipient-uri" attribute which conforms to the rules of section 5.2.1. 269 To avoid denial-of-service attacks, a client SHOULD NOT use distribution 270 lists as the Notification Recipient. 272 When an Event occurs, the Printer MUST immediately: 274 1. Find all pertinent Subscription Objects P according to the rules of 275 section 9 of [ipp-ntfy], AND 277 2. Find the subset M of these Subscription Objects P whose "notify- 278 recipient-uri" attribute has a scheme value of 'mailto', AND 280 3. For each Subscription Object in M, the Printer MUST 282 a)generate an email message as specified in section 5.2.2 AND 284 b)send the email message to the Notification Recipient specified 285 by the address part of the "notify-recipient-uri" attribute 286 value (see section 5.2.1). 288 If the Printer supports only SMTP, it MUST send the email message via 289 SMTP. If the Printer supports additional email protocols, it MUST 290 determine the protocol from the address part of the "notify-recipient- 291 uri" attribute value and then send the email message via the appropriate 292 email protocol. 294 When a Subscription Object is listening to a frequently occurring Event, 295 such as 'job-progress', the Printer MUST moderate the sending of Event 296 Notifications caused by such an Event. It is implementation dependent as 297 to how a Printer moderates Events and how a human controls the 298 moderation. 300 4 General Information 302 According to the notification extension document [ipp-ntfy], this 303 document MUST contain the following information: 305 1.The URL scheme name for the Delivery Method is: 'mailto' 307 2.Printer support for this delivery method is OPTIONAL. 309 3.For Event Notification content, a Printer MUST support SMTP. It MAY 310 support other email protocols. 312 4.Several Event Notifications MUST NOT be combined into a compound 313 Event Notification. The Printer MUST send them as separate email 314 messages. 316 5.The Printer MUST initiate the Delivery Method. 318 6.The Delivery Method sends Human Consumable Event Notifications. 320 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 321 2000 323 7.The representation and encoding for each piece of information MUST be 324 plain text (see section 5.2.2). An implementation MAY send the 325 information in other encodings. 327 8.In the Event Notification content, a Printer MUST send all pieces of 328 information specified in section 5.2.2. 330 9.Frequently occurring Events MUST be moderated to prevent Notification 331 Recipients from receiving excessive email. 333 10. This Delivery Method has the same latency and reliability as the 334 underlying SMTP (or other) transport. 336 11. This Delivery Method has the same security aspects as the 337 underlying SMTP (or other) transport. 339 12. This Delivery Method has no content length restrictions. 341 13. There are no additional values that a Printer MUST send in a 342 Notification content. 344 14. There is one additional Subscription Template attributes. See 345 section 5.1.1. 347 15. There are no additional Printer Description attributes. 349 5 Subscription Template Attributes 351 5.1 Additional Subscription Template Attributes 353 This Delivery Method introduces one additional Subscription Template 354 Attribute. 356 5.1.1 notify-mailto-text-only (boolean) 358 When the Printer generates an Event Notification from a Subscription 359 Object, this attribute specifies whether the Printer generates the Event 360 Notification with only plain text (i.e. 'text/plain') or with Content- 361 Types that the Printer chooses. 363 The Printer MUST support this attribute if it supports the 'mailto' 364 Delivery Method. 366 A client MAY supply this attribute. If a client does not supply this 367 attribute, the Printer MUST populate this attribute with the value of 368 'false' on the Subscription Object. There is no "notify-mailto-text- 369 only-default" attribute. 371 If the value of this attribute is 'true' in a Subscription Object, the 372 message body of each Event Notification that the Printer generates from 373 the Subscription Object MUST contain plain text only (i.e. 'text/plain' 374 with the charset specified by the "notify-charset' Subscription Object 375 attribute). 377 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 378 2000 380 If the value of this attribute is 'false' in a Subscription Object, the 381 message body of each Event Notification that the Printer generates from 382 the Subscription Object MAY contain any Content-Type (e.g. 'text/plain', 383 'text/html', 'multipart/mixed', 'multipart/alternative', 'image/gif', 384 'audio/basic', etc.). 386 A Printer MUST support both values ('true' and 'false') of this 387 attribute. There is no "notify-mailto-text-only-supported" attribute. 389 5.2 Additional Information about Subscription Template Attributes 391 This section describes additional values for attributes defined in [ipp- 392 ntfy]. 394 5.2.1 notify-recipient-uri (uri) 396 This section describes the syntax of the value of this attribute for the 397 'mailto' Delivery Method. The syntax for values of this attribute for 398 other Delivery Method is defined in other Delivery Method Documents. 400 In order to support the 'mailto' Delivery Method, the Printer MUST 401 support the following syntax for the 'mailto' Delivery Method when the 402 Printer uses SMTP. The line below use RFC 822 syntax rules and terms. 404 "mailto:" 1#mailbox 406 Note: the above syntax allows 1 or more occurrences of 'mailbox'. Each 407 occurrence of 'mailbox' represents an email address of a Notification 408 Recipient. 410 ISSUE: RFC 2368 allows more than one mailbox. Do we want this or just 1? 412 For SMTP, the phrase 'address part of the "notify-recipient-uri" 413 attribute value' refers to the 'mailbox' part of the value. 415 The Printer MAY support other syntax for the 'address part' if it 416 supports other email protocols. 418 5.2.2 notify-user-data (octetString(63)) 420 This attributes has a special use for the 'mailto' Delivery Method. It 421 specifies the email address of the Subscribing Client. It is primarily 422 useful when the Notification Recipient is some person other than the 423 Subscribing Client. Then the Notification Recipient has a way to reply 424 to the Subscribing Client. 426 If a client specifies this Delivery Method in a Subscription Creation 427 Operation, and the specified Notification Recipient is not associated 428 with the same person as the client, the client SHOULD supply its email 429 address as the value of the "notify-user-data" attribute. If the client 430 does not supply this attribute, the Printer MUST NOT populate the 431 Subscription Object with this attribute. 433 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 434 2000 436 6 Event Notification Content 438 This section describes the content of an Event Notification sent via the 439 'mailto' Delivery Method using the SMTP protocol. This document does 440 not describe the content for other email protocols, but an 441 implementation should use this section as a model. 443 When a Printer sends an email message via SMTP, the content MUST conform 444 to RFC 822. The following sections define the content that a Printer 445 MUST send. A Printer MAY send additional content as long as the 446 resulting content conforms to RFC 822. 448 Each subsection below specifies the syntax that pertains to the 449 subsection. The syntax rules and syntactic terms (e.g. 'date-time') in 450 each subsection come from RFC 822, except for the section on "Content- 451 Type" which comes from RFC 1521. 453 The Event Notification content has two parts, the headers and the 454 message body. The headers precede the message body and are separated by 455 a blank line (see [RFC 822]). 457 6.1 Headers 459 When a Printer sends an Event Notification via SMTP, it MUST include the 460 following headers. RFC 822 RECOMMENDS that the headers be in the order 461 that they appear below. 463 6.1.1 'Date' header 465 Syntax: "Date" ":" date-time 467 This header contains the date and time that the Event occurred. 469 The Printer MUST include a "Date" header if and only if it supports the 470 "printer-current-time" Printer attribute. 472 6.1.2 'From' header 474 Syntax: "From" ":" mailbox 476 where 478 mailbox = addr-spec / phrase route-addr 480 This header causes a typical email reader to show the email as coming 481 from the Printer that is sending the Event Notification. 483 The Printer MUST include a "From" header whose syntax is specified 484 above. 486 The Printer MUST use the second alternative of the syntax for 'mailbox' 487 defined above (i.e. 'phrase route-addr'). The 'phrase' is the 488 Printer's display name and it MUST be the value of the "printer-name" 489 Printer attribute. The 'route-addr' MUST contain an email address 490 (inside angle brackets) belonging to either an administrator or the 491 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 492 2000 494 output-device. This email address NEED NOT be capable of receiving mail. 495 There is no Printer attribute to hold this email address, so that it 496 cannot be configured using the IPP protocol without an implementation- 497 defined attribute extension. 499 6.1.3 'Subject' header 501 Syntax: "Subject" ":" *text 503 This header specifies the subject of the message and contains a short 504 summary of the Event Notification. 506 The Printer MUST include a "Subject" header whose syntax is specified 507 above. 509 The Printer MUST localize the '*text' using the values of the "notify- 510 charset" and "notify-natural-language" Subscription Object attributes. 512 For Printer Events, the '*text' SHOULD start with the localized word 513 "printer:", followed by the Printer name, and then followed by the 514 localized Event name, e.g., in English: "printer: 'tiger' stopped" or in 515 French: 'imprimeur: 'tigre' arr.t.'. 517 For Job Events, the '*text' SHOULD start with the localized phrase 518 "print job:", followed by the Job name, and then followed by the 519 localized Event name, e.g., in English: "print job: 'financials' 520 completed". 522 The wording is implementation dependent. A Notification Recipient MUST 523 NOT expect to be able to parse this text. But an email filter might look 524 for "printer" or "print job". 526 6.1.4 'Sender' header 528 Syntax: "Sender" ":" mailbox 530 This header causes a typical email reader to show the email as coming on 531 behalf of the person associated with the Subscribing Client. 533 If the Subscription Object contains the "notify-user-data" attribute, 534 and if its value satisfies the RFC 822 syntax rules for 'mailbox', the 535 Printer MUST include a "Sender" header whose syntax is specified above. 536 Otherwise, the Printer MUST NOT include a "Sender" header. 538 For the "Sender" header, the 'mailbox' MUST be the value of the "notify- 539 user-data" Subscription Object attribute. See section 5.2.2 for details 540 about the "notify-user-data" attribute. 542 6.1.5 'Reply-to' header 544 Syntax: "Reply-to" ":" mailbox 546 If the Notification Recipient replies to Event Notification email, this 547 header causes a typical email reader to send email to the person acting 548 as the Subscribing Client. The rules are identical to the "Sender" 549 header. 551 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 552 2000 554 If the Subscription Object contains the "notify-user-data" attribute, 555 and if its value satisfies the RFC 822 syntax rules for "mailbox", the 556 Printer MUST include a "Reply-to" header whose syntax is specified 557 above. Otherwise, the Printer MUST NOT include a "Reply-to" header. 559 For the "Reply-to" header, the "mailbox" MUST be the value of the 560 "notify-user-data" Subscription Object attribute. See section 5.2.2 for 561 details about the "notify-user-data" attribute. 563 6.1.6 'To' header 565 Syntax: "To" ":" 1#mailbox 567 See [RFC 1521] for the syntax. 569 This header specifies the Notification Recipient(s). 571 The Printer MUST include a "To" header whose syntax is specified above. 573 The '1#mailbox' MUST be the '1#mailbox' part of the value of the 574 "notify-recipient-uri" Subscription attribute, i.e. the part after the 575 "mailto:". 577 6.1.7 'Content-type' header 579 Syntax: "Content-Type" ":" type "/" subtype *(";"parameter) 581 See [RFC 1521] for the syntactic terms (e.g. 'type'). 583 This header specifies the format of the message body. 585 The Printer MUST include the "Content-Type" header. 587 If the value of the "notify-mailto-text-only" Subscription Object 588 attribute is 'true', the 'type' MUST be "plain", the 'subtype' MUST be 589 "text" and the 'parameter' MUST be ' "charset=" XXX' where XXX is the 590 value of the "notify-charset" Subscription Object attribute, e.g. 591 'text/plain;charset=UTF-8'. 593 If the value of the "notify-mailto-text-only" Subscription Object 594 attribute is 'false, the values of 'type', 'subtype' and 'parameter' 595 MUST be values allowed by RFC 1521 or some registered MIME type. That 596 is, a Printer MAY send any format it wishes, e.g. html, images, audio, 597 or multipart. 599 6.2 Message Body 601 This document describes a message body that is plain text. The content 602 of all other Content-Types is implementation dependent. A Printer SHOULD 603 include a plain text message even when it sends other Content-Types, 604 i.e. the 'type' of the Content-Type SHOULD be 'multipart'. 606 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 607 2000 609 When a Printer sends a plain text message, it MUST localize the text 610 using the values of the "notify-charset" and "notify-natural-language" 611 Subscription Object attributes. 613 Section 9.2 in [ipp-ntfy] specifies the information that a Delivery 614 Method MUST specify and a Printer SHOULD send. This section contains the 615 information from section 9.2 in [ipp-ntfy] and changes "Printer SHOULD 616 send" to "Printer MUST send". 618 A Printer MUST send the following localized information in the message 619 body. The specific wording of this information and its layout are 620 implementation dependent. 622 a)the Printer name (see Table 1) 623 b)omitted (see below). 624 c)for Printer Events only: 625 i) the Event (see Table 2) and/or Printer state information 626 (see Table 5) 627 d)for Job Events only: 628 i) the job identity (see Table 3) 629 ii) the Event (see Table 2) and/or Job state information (see 630 Table 4) 632 Item b) in the above list is omitted because the Printer sends the time 633 of the Event as an email header (see section 6.1.1 on the 'Date' 634 header). 636 The subsections of this section specify the attributes that a Printer 637 MUST use to obtain this information. 639 The Printer MAY send additional information, depending on 640 implementation. 642 Notification Recipients MUST NOT expect to be able to parse the message. 644 The next three sections define the attributes in Event Notification 645 Contents that are: 647 a)for all Events 649 b)for Job Events only 651 c)for Printer Events only 653 6.2.1 Information in Event Notification Content Common to All Events 655 The Printer MUST send the following information. 657 There is a separate table for each piece of information. Each row in the 658 table represents a source value for the information and the values are 659 listed in order of preference, with the first one being the preferred 660 one. An implementation SHOULD use the source value from the earliest row 661 in each table. The tables in this section and following contain the 662 following columns for each piece of information: 664 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 665 2000 667 a)Source of Value: the name of the attribute that supplies the 668 value for the Event Notification 670 b)Source Object: the object from which the source value comes. 672 Table 1 lists the source of the information for the Printer Name. The 673 "printer-name" is more user-friendly unless the Notification Recipient 674 is in a place where the Printer name is not meaningful. 676 Table 1 . Printer Name in Event Notification Content 678 Source Value Source Object 680 printer-name (name(127)) Printer 682 notify-printer-uri (uri) Subscription 684 Table 2 lists the source of the information for the Event name. A 685 Printer MAY combine this information with state information described 686 for Jobs in Table 4 or for Printers in Table 5. 688 Table 2 . Event Name in Event Notification Content 690 Source Value Source Object 692 notify-subscribed-event (type2 keyword) Subscription 694 6.2.2 Additional Information in Event Notification Content for Job 695 Events 697 This section lists the source of the additional information that a 698 Printer MUST send for Job Events. 700 Table 3 lists the source of the information for the job name. The "job- 701 name" is likely more meaningful to a user than "job-id". 703 Table 3 . Job Name in Event Notification Content for Job Events 705 Source Value Source Object 707 job-name (name(MAX)) Job 709 job-id (integer(1:MAX)) Job 711 Table 4 lists the source of the information for the job-state. If a 712 Printer supports the "job-state-message" and "job-detailed-state- 713 message" attributes, it SHOULD use those attributes for the job state 714 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 715 2000 717 information, otherwise, it should fabricate such information from the 718 "job-state" and "job-state-reasons". For some Events, a Printer MAY 719 combine this information with Event information. 721 Table 4 . Job State in Event Notification Content for Job Events 723 Source Value Source Object 725 job-state-message (text(MAX)) Job 727 job-detailed-status-messages (1setOf text(MAX)) Job 729 job-state (type1 enum) Job 731 job-state-reasons (1setOf type2 keyword) Job 733 6.2.3 Additional Information in Event Notification Content for Printer 734 Events 736 This section lists the source of the additional information that a 737 Printer MUST send for Printer Events. 739 Table 5 lists the source of the information for the printer-state. If a 740 Printer supports the "printer-state-message", it SHOULD use that 741 attribute for the job state information, otherwise it SHOULD fabricate 742 such information from the "printer-state" and "printer-state-reasons". 743 For some Events, a Printer MAY combine this information with Event 744 information. 746 Table 5 . Printer State in Event Notification Content for Printer Events 748 Source Value Source Object 750 printer-state-message (text(MAX)) Printer 752 printer-state (type1 enum) Printer 754 printer-state-reasons (1setOf type2 keyword) Printer 756 printer-is-accepting-jobs (boolean) Printer 758 6.3 Examples 760 This section contains three examples. One is a Job Event and the other 761 two are Printer Events, the latter in French. 763 6.3.1 Job Event Example 765 This section contains an example of an Event Notification of a Job 766 Event. 768 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 769 2000 771 A Subscribing Client Mike Jones (who works for xyz Corp.) performs a 772 Subscription Creation Operation as part of the Print-Job operation on 773 Printer "ipp://tiger@abc.com". Mike Jones specifies that the "job-name" 774 is "financials". Mike is printing the Job for Bill Smith at abc Corp. 775 The Subscription Object then has the following attributes: 777 Attribute Name Attribute Value 779 notify-recipient-uri mailto:bsmith@abc.com 781 notify-events job-completed 783 notify-user-data mjones@xyz.com 785 notify-mailto-text-only true 787 notify-charset us-ascii 789 notify-natural-language en-us 791 notify-persistence false 793 notify-subscription-id 35692 795 notify-sequence-number 0 797 notify-printer-up-time 34593 799 notify-printer-uri ipp://tiger@abc.com 801 notify-job-id 345 803 notify-subscriber-user- mjones 804 name 806 When the Job completes, the Printer generates and sends the following 807 email message: 809 Date: 17 Jul 00 1632 PDT 810 From: tiger 811 Subject: print job: 'financials' completed 812 Sender: mjones@xyz.com 813 Reply-to: mjones@xyz.com 814 To: bsmith@abc.com 815 Content-type: text/plain 817 printer: tiger 818 job: financials 819 job-state: completed 821 The reader should note that the phrases are not identical to IPP 822 keywords. They have been localized to English. 824 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 825 2000 827 6.3.2 Printer Event Example 829 This section contains an example of an Event Notification of a Printer 830 Event. 832 A Subscribing Client Peter Williams, a Printer admin, performs a Create- 833 Printer-Subscriptions operation on Printer "ipp://tiger@abc.com". The 834 Subscription Object then has the following attributes: 836 Attribute Name Attribute Value 838 notify-recipient-uri mailto:pwilliams@abc.com 840 notify-events printer-state-changed 842 notify-mailto-text-only true 844 notify-charset us-ascii 846 notify-natural-language en-us 848 notify-persistence false 850 notify-subscription-id 4623 852 notify-sequence-number 0 854 notify-printer-uptime 23002 856 notify-printer-uri ipp://tiger@abc.com 858 notify-lease-expiration- 0 859 time 861 notify-subscriber-user- pwilliams 862 name 864 When the Printer jams, the Printer generates and sends the following 865 email message: 867 Date: 29 Aug 00 0832 PDT 868 From: tiger 869 Subject: printer: 'tiger' stopped 870 To: pwilliams@abc.com 871 Content-type: text/plain 873 printer: tiger 874 state: stopped 875 reason: jammed paper 877 The reader should note that the phrases are not identical to IPP 878 keywords. They have been localized to English. 880 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 881 2000 883 6.3.3 Printer Event Example (localized to French) 885 This section contains an example of an Event Notification of a Printer 886 Event. 888 A Subscribing Client Pierre Veyrat, a Printer admin, performs a a 889 Create-Printer-Subscriptions operation on Printer "ipp://tigre@def.com". 890 The Subscription Object then has the following attributes: 892 Attribute Name Attribute Value 894 notify-recipient-uri mailto:pveyrat@def.com 896 notify-events printer-state-changed 898 notify-mailto-text-only true 900 notify-charset utf-8 902 notify-natural-language fr 904 notify-persistence false 906 notify-subscription-id 50225 908 notify-sequence-number 0 910 notify-printer-uptime 53217 912 notify-printer-uri ipp://tigre@def.com 914 notify-lease-expiration- 0 915 time 917 notify-subscriber-user- pveyrat 918 name 920 When the Printer jams, the Printer generates and sends the following 921 email message: 923 Note, this example shows the accented characters as an email reader 924 would show them rather than as they would be encoded in us-ascii. 926 ISSUE: this needs to changed to real ascii encoding for IETF ascii 927 document. 929 Date: 29 Jan 00 0832 CET 930 From: tigre 931 Subject: imprimeur: 'tigre' arr.t. 932 To: pveyrat@def.com 933 Content-type: text/plain;charset=utf-8 935 imprimeur: tigre@def.com 936 .tat: arr.t. 938 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 939 2000 941 raison: papier coinc. 943 7 Conformance Requirements 945 If the Printer supports the 'mailto' Delivery Method, the Printer MUST: 947 1.meet the conformance requirements defined in [ipp-ntfy]. 949 2.support the "notify-mailto-text-only " Subscription Object attribute 950 defined in section 5.1.1. 952 3.support the syntax for the "notify-recipient-uri" Subscription Object 953 attribute defined in section 5.2.1 955 4.support the use for the "notify-user-data" Subscription Object 956 attribute defined in section 5.2.2 958 5.support SMTP for sending Event Notifications. 960 6.support the 'text/plain' Content-Type for the message body. 962 7.support sending Event Notification via email with the content 963 specified in section 5.2. 965 8 IANA Considerations 967 Because the 'mailto' URL scheme is already defined in a standards track 968 document [RFC 2368] and registered with IANA, this document does not 969 require anything further of IANA. 971 9 Internationalization Considerations 973 This Delivery Method presents no internationalization considerations 974 beyond those covered in the [ipp-ntfy] document, and sections 6.1.3 and 975 6.2 of this document. 977 The Notification Recipient is expected to present the email as received 978 because the Printer does all necessary localization to the Event 979 Notification contents. 981 10 Security Considerations 983 The biggest security concern is that a Subscribing Client will cause 984 unsolicited Event Notifications to be sent to third parties, potentially 985 creating denial-of-service problems (i.e., spam). The problem is even 986 worse if the third parties are distribution lists. 988 There exist scenarios where third party notification is required (see 989 Scenario #2 and #3 in [ipp-not-req]). The fully secure solution would 990 require active agreement of all persons before they can become 991 Notification Recipients. However, requirement #9 in [ipp-req] ("There 992 is no requirement for IPP Printer receiving the print request to 993 validate the identity of an event recipient") argues against this. To 994 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 995 2000 997 minimize the risk, a Printer could disallow third party Notification 998 Recipients (a traditional facsimile model). 1000 The Delivery Method recommends that the Subscribing Client supply his or 1001 her email address as the value of the "notify-user-data" attribute in 1002 the Subscription Creation Operation when the Notification Recipient is a 1003 third party. To reduce the chance of spamming or identify the spammer, a 1004 Printer could disallow third party Notification Recipients if the 1005 Subscribing Client doesn't supply the "notify-user-data" attribute with 1006 a valid email address. 1008 Some firewall administrators prevent mail attachments from being 1009 accepted into their organizations because of the problem of the 1010 attachments containing computer viruses. The 'mailto' Delivery Method 1011 allows the Subscribing Client to request that the Content-Type of a 1012 message body be 'text/plain'. 1014 11 References 1016 [ipp-iig] 1017 Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P., 1018 "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers- 1019 guide-v11-01.txt, work in progress, May 9, 2000 1021 [ipp-mod] 1022 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1023 "Internet Printing Protocol/1.0: Model and Semantics", , March 1, 2000. 1026 [ipp-notify-poll] 1027 Manros, C., Hastings, T., Herriot, R., Lewis, H., "Internet 1028 Printing Protocol (IPP): The 'ipp' Notification Delivery Polling 1029 Method", , work in progress, 1030 May, 2000. 1032 [ipp-ntfy] 1033 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 1034 Bergman, R., "Internet Printing Protocol/1.1: IPP Event 1035 Notification Specification", , May 1036 10, 2000. 1038 [ipp-pro] 1039 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1040 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 1041 05.txt, March 1, 2000. 1043 [RFC821] 1044 Jonathan B. Postel, "Simple Mail Transfer Protocol", RFC 821, 1045 August, 1982. 1047 [RFC822] 1048 David H. Crocker, "Standard For The Format Of ARPA Internet Text 1049 Messages", RFC 822, August 13, 1982. 1051 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 1052 2000 1054 [RFC1341] 1055 N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 1056 Extensions): Mechanisms for Specifying and Describing the Format of 1057 Internet Message Bodies", RFC 1341, June, 1992. 1059 [RFC1521] 1061 N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 1062 Extensions) Part One: Mechanisms for Specifying and Describing the 1063 Format of Internet Message Bodies", RFC 1521, September 1993. 1065 [RFC1891] 1066 K. Moore, "SMTP Service Extension for Delivery Status 1067 Notifications", RFC 1891, January 1996 1069 [RFC2026] 1070 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 1071 2026, October 1996. 1073 [RFC2046] 1074 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1075 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1076 RFC 2616, June 1999. 1078 [RFC2368] 1079 P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL scheme", RFC 1080 2616, July 1998. 1082 [RFC2616] 1083 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1084 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1085 RFC 2616, June 1999. 1087 [RFC2633] 1088 B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633, 1089 June 1999. 1091 12 Author's Addresses 1093 Robert Herriot 1094 Xerox Corporation 1095 3400 Hillview Ave., Bldg #1 1096 Palo Alto, CA 94304 1098 Phone: 650-813-7696 1099 Fax: 650-813-6860 1100 Email: robert.herriot@pahv.xerox.com 1102 Henrik Holst 1103 i-data international a/s 1104 Vadstrupvej 35-43 1105 2880 Bagsvaerd, Denmark 1107 INTERNET-DRAFTIPP: The .mailto:. Notification Delivery MethodJuly 7, 1108 2000 1110 Phone: +45 4436-6000 1111 Fax: +45 4436-6111 1112 e-mail: hh@i-data.com 1114 Tom Hastings 1115 Xerox Corporation 1116 737 Hawaii St. ESAE 231 1117 El Segundo, CA 90245 1119 Phone: 310-333-6413 1120 Fax: 310-333-5514 1121 e-mail: hastings@cp10.es.xerox.com 1123 Carl-Uno Manros 1124 Xerox Corporation 1125 737 Hawaii St. ESAE 231 1126 El Segundo, CA 90245 1128 Phone: 310-333-8273 1129 Fax: 310-333-5514 1130 e-mail: manros@cp10.es.xerox.com 1132 13 Full Copyright Statement 1134 Copyright (C) The Internet Society (2000). All Rights Reserved. 1136 This document and translations of it may be copied and furnished to 1137 others, and derivative works that comment on or otherwise explain it or 1138 assist in its implementation may be prepared, copied, published and 1139 distributed, in whole or in part, without restriction of any kind, 1140 provided that the above copyright notice and this paragraph are included 1141 on all such copies and derivative works. However, this document itself 1142 may not be modified in any way, such as by removing the copyright notice 1143 or references to the Internet Society or other Internet organizations, 1144 except as needed for the purpose of developing Internet standards in 1145 which case the procedures for copyrights defined in the Internet 1146 Standards process must be followed, or as required to translate it into 1147 languages other than English. 1149 The limited permissions granted above are perpetual and will not be 1150 revoked by the Internet Society or its successors or assigns. 1152 This document and the information contained herein is provided on an "AS 1153 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1154 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1155 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1156 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1157 FITNESS FOR A PARTICULAR PURPOSE.