idnits 2.17.1 draft-ietf-ipp-notify-mailto-04.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: ---------------------------------------------------------------------------- ** 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? 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 ([RFC2911,RFC2910], [RFC2566,RFC2565]), 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 40: '...nt is one of the RECOMMENDED Delivery ...' RFC 2119 keyword, line 117: '... defines an OPTIONAL extension to In...' RFC 2119 keyword, line 139: '...his document is one of the RECOMMENDED...' RFC 2119 keyword, line 161: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 162: '... NOT, MAY, NEED NOT, and OPTIONAL, h...' (93 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2911, but the abstract doesn't seem to directly say this. It does mention RFC2911 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 235 has weird spacing: '...for the mail...' == Line 1239 has weird spacing: '...for the purpo...' == Unrecognized Status in '[Target Category: standards track]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC2911, updated by this document, for RFC5378 checks: 1999-02-22) -- 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 17, 2001) is 8309 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: 'RFC2566' is mentioned on line 1220, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) == Missing Reference: 'RFC2565' is mentioned on line 1220, but not defined ** Obsolete undefined reference: RFC 2565 (Obsoleted by RFC 2910) == Missing Reference: 'RFC2119' is mentioned on line 163, but not defined == Missing Reference: 'RFC 822' is mentioned on line 435, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RFC 1521' is mentioned on line 564, 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 953, but not defined ** Obsolete undefined reference: RFC 2368 (Obsoleted by RFC 6068) == Missing Reference: 'RFC2567' is mentioned on line 1166, but not defined == Missing Reference: 'RFC2568' is mentioned on line 1168, but not defined == Missing Reference: 'RFC2569' is mentioned on line 1172, but not defined == Unused Reference: 'RFC822' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'RFC1341' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC1521' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1079, 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) ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) -- Duplicate reference: RFC2616, mentioned in 'RFC2616', was also mentioned in 'RFC2046'. ** 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) ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) Summary: 22 errors (**), 0 flaws (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Printing Protocol WG Robert Herriot 3 INTERNET-DRAFT Tom Hastings 4 Carl-Uno Manros 5 Updates: RFC 2911 Xerox Corp. 6 [Target Category: standards track] Henrik Holst 7 Expires: January 17, 2002 i-data international a/s 8 July 17, 2001 10 Internet Printing Protocol (IPP): 11 The 'mailto' Delivery Method for Event Notifications 13 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 17 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working 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 25 material 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 This document describes an extension to the Internet Printing 36 Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. 37 This document specifies the 'mailto' Delivery Method for use with the 38 "IPP Event Notifications and Subscriptions" specification [ipp-ntfy]. 39 When IPP Notification [ipp-ntfy] is supported, the Delivery Method 40 defined in this document is one of the RECOMMENDED Delivery Methods 41 for Printers to support. 43 For this Delivery Method, when an Event occurs, the Printer 44 immediately sends an Event Notification via an email message to the 45 Notification Recipient specified in the Subscription Object. The 46 message body of the email consists of Human Consumable text that is 47 not intended to be parsed by a machine. The Notification Recipient 48 receives the Event Notification in the same way as it receives any 49 other email message. 51 Table of Contents 53 1 Introduction.....................................................4 55 2 Terminology......................................................4 57 3 Model and Operation..............................................5 59 4 General Information..............................................6 61 5 Subscription Template Attributes.................................8 62 5.1 Additional Subscription Template Attributes....................8 63 5.1.1 notify-mailto-text-only (boolean)............................8 64 5.2 Additional Information about Subscription Template Attributes..9 65 5.2.1 notify-recipient-uri (uri)...................................9 66 5.2.2 notify-user-data (octetString(63))..........................10 68 6 Event Notification Content......................................10 69 6.1 Headers.......................................................11 70 6.1.1 'Date' header...............................................11 71 6.1.2 'From' header...............................................11 72 6.1.3 'Subject' header............................................12 73 6.1.4 'Sender' header.............................................12 74 6.1.5 'Reply-to' header...........................................13 75 6.1.6 'To' header.................................................13 76 6.1.7 'Content-type' header.......................................13 77 6.2 Message Body..................................................14 78 6.3 Plain Text Content............................................14 79 6.3.1 Event Notification Content Common to All Events.............15 80 6.3.2 Additional Event Notification Content for Job Events........17 81 6.3.3 Additional Event Notification Content for Printer Events....18 82 6.4 Examples......................................................18 83 6.4.1 Job Event Example...........................................19 84 6.4.2 Printer Event Example.......................................20 85 6.4.3 Printer Event Example (localized to Danish)................21 87 7 Conformance Requirements........................................23 89 8 IANA Considerations.............................................23 90 8.1 Attribute Registration........................................23 91 8.2 Additional uriScheme Attribute Value Registration for the 92 "operations-supported" Printer Attribute..........................24 94 9 Internationalization Considerations.............................24 96 10 Security Considerations........................................24 98 11 References.....................................................25 99 12 Author's Addresses.............................................27 101 13 Summary of Base IPP Documents..................................28 103 14 Full Copyright Statement.......................................29 105 Table of Tables 106 Table 1 - Information about the Delivery Method.....................6 107 Table 2 - Additional Subscription Template Attributes...............8 108 Table 3 - Printer Name in Event Notification Content...............16 109 Table 4 - Event Name in Event Notification Content.................17 110 Table 5 - Job Name in Event Notification Content...................17 111 Table 6 - Job State in Event Notification Content..................18 112 Table 7 - Printer State in Event Notification Content..............18 114 1 Introduction 116 The "IPP Event Notifications and Subscriptions" document [ipp-ntfy] 117 defines an OPTIONAL extension to Internet Printing Protocol/1.0 (IPP) 118 [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910] (for a description 119 of the base IPP documents, see section 13). That extension defines 120 operations that a client can perform in order to create Subscription 121 Objects in a Printer and carry out other operations on them. A 122 Subscription Object represents a Subscription abstraction. A client 123 associates Subscription Objects with a particular Job by performing 124 the Create-Job-Subscriptions operation or by submitting a Job with 125 subscription information. A client associates Subscription Objects 126 with the Printer by performing a Create-Printer-Subscriptions 127 operation. Four other operations are defined for Subscription 128 Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew- 129 Subscription, and Cancel-Subscription. The Subscription Object 130 specifies that when one of the specified Events occurs, the Printer 131 sends an asynchronous Event Notification to the specified 132 Notification Recipient via the specified Delivery Method (i.e., 133 protocol). 135 The "IPP Event Notifications and Subscriptions" document [ipp-ntfy] 136 specifies that each Delivery Method is defined in another document. 137 This document is one such document, and it specifies the 'mailto' 138 delivery method. When IPP Notification [ipp-ntfy] is supported, the 139 Delivery Method defined in this document is one of the RECOMMENDED 140 Delivery Methods and Printers to support. 142 For this Delivery Method, when an Event occurs, the Printer 143 immediately sends an Event Notification via an email message to the 144 Notification Recipient specified in the Subscription Object. The 145 message body of the email consists of Human Consumable text that is 146 not intended to be parsed by a machine. The 'mailto' Delivery Method 147 is a 'push' Delivery Method as defined in [ipp-ntfy]. 149 The Notification Recipient receives the Event Notification in the 150 same way as it receives any other email message. 152 2 Terminology 154 This section defines the following terms that are used throughout 155 this document: 157 This document uses the same terminology as [RFC2911], such as 158 "client", "Printer", "attribute", "attribute value", "keyword", 159 "operation", "request", "response", and "support". 161 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 162 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 163 conformance as defined in RFC 2119 [RFC2119] and [RFC2911] section 164 12.1. If an implementation supports the extension defined in this 165 document, then these terms apply; otherwise, they do not. These 166 terms define conformance to this document only; they do not affect 167 conformance to other documents, unless explicitly stated otherwise. 169 Capitalized terms, such as Notification Recipient, Event 170 Notification, Compound Event Notification, Printer, etc., are 171 defined in [ipp-ntfy], have the same meanings, and are not reproduced 172 here. 174 3 Model and Operation 176 In a Subscription Creation Operation, when the value of the "notify- 177 recipient-uri" attribute contains the URI scheme "mailto", the client 178 is requesting that the Printer use the 'mailto' Delivery Method for 179 Event Notifications generated from the new Subscription Object. 181 For this Delivery Method, the "notify-recipient-uri" attribute value 182 MUST consist of a "mailto" scheme followed by a colon, and then 183 followed by an address part (e.g., 'mailto:smith@abc.com'). See 184 section 5.2.1 for the syntax of the "notify-recipient-uri" attribute 185 value for this Delivery Method. 187 A Printer MUST support SMTP [RFC821], and it MAY support other email 188 protocols. A Printer MAY use additional services, such as SMTP 189 delivery status notification [RFC1891] or S/MIME encryption 190 [RFC2633]. 192 If the client wants the Printer to send Event Notifications via the 193 'mailto' Delivery Method, the client MUST choose a value for "notify- 194 recipient-uri" attribute which conforms to the rules of section 195 5.2.1. To avoid denial-of-service attacks, a client SHOULD NOT use 196 distribution lists as the Notification Recipient. 198 When an Event occurs, the Printer MUST immediately: 200 1.Find all pertinent Subscription Objects P according to the rules 201 of section 9 of [ipp-ntfy], AND 203 2.Find the subset M of these Subscription Objects P whose "notify- 204 recipient-uri" attribute has a scheme value of 'mailto', AND 206 3.For each Subscription Object in M, the Printer MUST 207 a)generate an email message as specified in section 5.2.2 AND 209 b)send the email message to the Notification Recipient specified 210 by the address part of the "notify-recipient-uri" attribute 211 value (see section 5.2.1). 213 If the Printer supports only SMTP, it MUST send the email message via 214 SMTP. If the Printer supports additional email protocols, it MUST 215 determine the protocol from the address part of the "notify- 216 recipient-uri" attribute value and then send the email message via 217 the appropriate email protocol. 219 When a Subscribing Client is subscribing to the 'job-progress' event 220 (which is a frequently occurring event), it SHOULD supply the 221 "notify-time-interval" attribute (see [ipp-ntfy]) in the Subscription 222 Creation request with a suitable value to limit the time between 223 'job-progress' Event Notifications sent by the Printer. 225 4 General Information 227 If a Printer supports this Delivery Method, the following are its 228 characteristics. 230 Table 1 - Information about the Delivery Method 232 Document Method Conformance Delivery Method Realization 233 Requirement 235 1. What is the URL scheme name for the mailto 236 Delivery Method? 238 2. Is the Delivery Method REQUIRED, RECOMMENDED 239 RECOMMENDED, or OPTIONAL for an IPP 240 Printer to support? 242 3. What transport and delivery A Printer MUST support 243 protocols does the Printer use to SMTP. It MAY support other 244 deliver the Event Notification email protocols. 245 Content, i.e., what is the entire 246 network stack? 248 4. Can several Event Notifications be A Printer implementation 249 combined into a Compound Event MAY combine several Event 250 Notification? Notifications into a single 251 email message (see section 252 6). 254 email message (see section 255 6). 257 5. Is the Delivery Method initiated by This Delivery Method is a 258 the Notification Recipient (pull), push. 259 or by the Printer (push)? 261 6. Is the Event Notification content Human Consumable 262 Machine Consumable or Human 263 Consumable? 265 7. What section in this document Section 6 266 answers the following question? For 267 a Machine Consumable Event 268 Notification, what is the 269 representation and encoding of 270 values defined in section 9.1 of 271 [ipp-ntfy] and the conformance 272 requirements thereof? For a Human 273 Consumable Event Notification, what 274 is the representation and encoding 275 of pieces of information defined in 276 section 9.2 of [ipp-ntfy] and the 277 conformance requirements thereof? 279 8. What are the latency and reliability Same as the underlying SMTP 280 of the transport and delivery (or other optional) email 281 protocol? transport 283 9. What are the security aspects of the Same as the underlying SMTP 284 transport and delivery protocol, (or other optional) email 285 e.g., how it is handled in transport 286 firewalls? 288 10. What are the content length None 289 restrictions? 291 11. What are the additional values or None 292 pieces of information that a Printer 293 sends in an Event Notification 294 content and the conformance 295 requirements thereof? 297 12. What are the additional See section 5.1.1 on 298 Subscription Template and/or "notify-mailto-text-only" 299 Subscription Description attributes 300 and the conformance requirements 301 thereof? 302 and the conformance requirements 303 thereof? 305 13. What are the additional Printer None 306 Description attributes and the 307 conformance requirements thereof? 309 5 Subscription Template Attributes 311 5.1 Additional Subscription Template Attributes 313 This Delivery Method introduces one additional Subscription Template 314 Attribute (See Table 2). 316 Table 2 - Additional Subscription Template Attributes 318 Attribute in Subscription Object Default and Supported Printer 319 Attributes 321 notify-mailto-text-only (boolean) N/A 323 5.1.1 notify-mailto-text-only (boolean) 325 When the Printer generates an Event Notification from a Subscription 326 Object, this attribute specifies whether the Printer generates the 327 Event Notification with only plain text (i.e. 'text/plain') or with 328 Content-Types that the Printer chooses. 330 The Printer MUST support this attribute if it supports the 'mailto' 331 Delivery Method. 333 A client MAY supply this attribute. If a client does not supply this 334 attribute, the Printer MUST populate this attribute with the value of 335 'false' on the Subscription Object. There is no "notify-mailto-text- 336 only-default" attribute. 338 If the value of this attribute is 'true' in a Subscription Object, 339 the message body of each Event Notification that the Printer 340 generates from the Subscription Object MUST contain plain text only 341 (i.e. 'text/plain' with the charset specified by the "notify-charset' 342 Subscription Object attribute). 344 If the value of this attribute is 'false' in a Subscription Object, 345 the Content-Type of the message body of each Event Notification that 346 the Printer generates from the Subscription Object MUST be either 347 'text/plain' or 'multipart', depending on implementation. If the 348 Content-Type is 'multipart', one message body of the 'multipart' MUST 349 be the same as the 'text/plain' message body when this attribute has 350 the value of 'true'. Each of the other message bodies of the 351 'multipart' MAY be any Content-Type (e.g. 'text/html', 'image/gif', 352 'audio/basic', etc.). 354 A Printer MUST support both values ('true' and 'false') of this 355 attribute. There is no "notify-mailto-text-only-supported" attribute. 357 5.2 Additional Information about Subscription Template Attributes 359 This section describes additional values for attributes defined in 360 [ipp-ntfy]. 362 5.2.1 notify-recipient-uri (uri) 364 This section describes the syntax of the value of this attribute for 365 the 'mailto' Delivery Method. The syntax for values of this attribute 366 for other Delivery Method is defined in other Delivery Method 367 Documents. 369 In order to support the 'mailto' Delivery Method, the Printer MUST 370 support the following syntax for the 'mailto' Delivery Method when 371 the Printer uses SMTP. The line below use RFC 822 syntax rules and 372 terms. 374 "mailto:" mailbox 376 Note: the above syntax allows 1 occurrence of 'mailbox'. The 377 occurrence of 'mailbox' represents an email address of a Notification 378 Recipient. 380 For SMTP, the phrase 'address part' of the "notify-recipient-uri" 381 attribute value refers to the 'mailbox' part of the value. Example: 383 mailto:jones@acme.com 385 Unlike other URLs, the mailto scheme MUST NOT use // after the colon 386 (see [RFC2368]). 388 The Printer MAY support other syntax for the 'address part' if it 389 supports email protocols in addition to SMTP. 391 As noted in [ipp-ntfy], the uriScheme value of the corresponding 392 "notify-schemes-supported" Printer attribute does not include the ":" 393 character. 395 5.2.2 notify-user-data (octetString(63)) 397 This attributes has a special use for the 'mailto' Delivery Method. 398 It specifies the email address of the Subscribing Client. It is 399 primarily useful when the Notification Recipient is some person other 400 than the Subscribing Client. Then the Notification Recipient has a 401 way to reply to the Subscribing Client. 403 If a client specifies this Delivery Method in a Subscription Creation 404 Operation, and the specified Notification Recipient is not associated 405 with the same person as the client, the client SHOULD supply its 406 email address as the value of the "notify-user-data" attribute. If 407 the client does not supply this attribute, the Printer MUST NOT 408 populate the Subscription Object with this attribute. 410 6 Event Notification Content 412 This section describes the content of an Event Notification sent via 413 the 'mailto' Delivery Method using the SMTP protocol. This document 414 does not describe the content for other email protocols, but an 415 implementation should use this section as a model. 417 When a Printer sends an email message via SMTP, the content MUST 418 conform to RFC 822. The following sections define the content that a 419 Printer MUST send. A Printer MAY send additional content as long as 420 the resulting content conforms to RFC 822. 422 While the "Event Notification Ordering" in [ipp-ntfy] section 9 423 specifies ordering requirements for Printers when sending separate 424 Event Notifications, email messages are not guaranteed to arrive in 425 the order sent so that the Notification Recipient may not receive 426 them in the same order. 428 Each subsection below specifies the syntax that pertains to the 429 subsection. The syntax rules and syntactic terms (e.g. 'date-time') 430 in each subsection come from RFC 822, except for the section on 431 "Content-Type" which comes from RFC 1521. 433 The Event Notification content has two parts, the headers and the 434 message body. The headers precede the message body and are separated 435 by a blank line (see [RFC 822]). 437 A Printer implementation MAY combine several Event Notifications into 438 a single email message body. Such an email message is considered a 439 single Compound Event Notification and MUST follow the "Event 440 Notification Ordering" requirements for Event Notifications within a 441 Compound Event Notification specified in [ipp-ntfy] section 9. 443 6.1 Headers 445 When a Printer sends an Event Notification via SMTP, it MUST include 446 the following headers. RFC 822 RECOMMENDS that the headers be in the 447 order that they appear below. 449 6.1.1 'Date' header 451 Syntax: "Date" ":" date-time 453 This header contains the date and time that the Event occurred. 455 The Printer MUST include a "Date" header if and only if it supports 456 the "printer-current-time" Printer attribute. 458 6.1.2 'From' header 460 Syntax: "From" ":" mailbox 462 where 464 mailbox = addr-spec / phrase route-addr 466 This header causes a typical email reader to show the email as coming 467 from the Printer that is sending the Event Notification. 469 The Printer MUST include a "From" header whose syntax is specified 470 above. 472 The Printer MUST use the second alternative of the syntax for 473 'mailbox' defined above (i.e. 'phrase route-addr'). The 'phrase' is 474 the Printer's display name and it MUST be the value of the "printer- 475 name" Printer attribute. The 'route-addr' MUST contain an email 476 address (inside angle brackets) belonging to either an administrator 477 or the output-device. This email address NEED NOT be capable of 478 receiving mail. There is no Printer attribute to hold this email 479 address, so that it cannot be configured using the IPP protocol 480 without an implementation-defined attribute extension. 482 6.1.3 'Subject' header 484 Syntax: "Subject" ":" *text 486 This header specifies the subject of the message and contains a short 487 summary of the Event Notification. 489 The Printer MUST include a "Subject" header whose syntax is specified 490 above. 492 The Printer MUST localize the '*text' using the values of the 493 "notify-charset" and "notify-natural-language" Subscription Object 494 attributes. 496 For Printer Events, the '*text' SHOULD start with the localized word 497 "printer:", followed by the Printer name, and then followed by the 498 localized Event name, e.g., in English: "printer: 'tiger' stopped" or 499 in Danish: "Printeren 'tiger' er standset". 501 For Job Events, the '*text' SHOULD start with the localized phrase 502 "print job:", followed by the Job name, and then followed by the 503 localized Event name, e.g., in English: "print job: 'financials' 504 completed". 506 The wording is implementation dependent. A Notification Recipient 507 MUST NOT expect to be able to parse this text. But an email filter 508 might look for "printer" or "print job". 510 6.1.4 'Sender' header 512 Syntax: "Sender" ":" mailbox 514 This header causes a typical email reader to show the email as coming 515 on behalf of the person associated with the Subscribing Client. 517 If the Subscription Object contains the "notify-user-data" attribute, 518 and if its value satisfies the RFC 822 syntax rules for 'mailbox', 519 the Printer MUST include a "Sender" header whose syntax is specified 520 above. Otherwise, the Printer MUST NOT include a "Sender" header. 522 For the "Sender" header, the 'mailbox' MUST be the value of the 523 "notify-user-data" Subscription Object attribute. See section 5.2.2 524 for details about the "notify-user-data" attribute. 526 6.1.5 'Reply-to' header 528 Syntax: "Reply-to" ":" mailbox 530 If the Notification Recipient replies to Event Notification email, 531 this header causes a typical email reader to send email to the person 532 acting as the Subscribing Client. The rules are identical to the 533 "Sender" header. 535 If the Subscription Object contains the "notify-user-data" attribute, 536 and if its value satisfies the RFC 822 syntax rules for "mailbox", 537 the Printer MUST include a "Reply-to" header whose syntax is 538 specified above. Otherwise, the Printer MUST NOT include a "Reply-to" 539 header. 541 For the "Reply-to" header, the "mailbox" MUST be the value of the 542 "notify-user-data" Subscription Object attribute. See section 5.2.2 543 for details about the "notify-user-data" attribute. 545 6.1.6 'To' header 547 Syntax: "To" ":" 1#mailbox 549 See [RFC 1521] for the syntax. 551 This header specifies the Notification Recipient(s). 553 The Printer MUST include a "To" header whose syntax is specified 554 above. 556 The '1#mailbox' MUST be the '1#mailbox' part of the value of the 557 "notify-recipient-uri" Subscription attribute, i.e. the part after 558 the "mailto:". 560 6.1.7 'Content-type' header 562 Syntax: "Content-Type" ":" type "/" subtype *(";"parameter) 564 See [RFC 1521] for the syntactic terms (e.g. 'type'). 566 This header specifies the format of the message body. 568 The Printer MUST include the "Content-Type" header. 570 The "notify-mailto-text-only" attribute determines the 'type' and 571 'subtype' values. The possible values are "text/plain" and 572 "multipart" values. 574 6.2 Message Body 576 The message body MUST contain Human Consumable content as plain text. 577 It MAY also contain other types of implementation dependent content. 579 For plain text, the Content-Type of Human Consumable content MUST be 580 'text/plain'. For implementation dependent content, the Content-Type 581 of Human Consumable content MUST be 'multipart'. The Content-Type of 582 one body part MUST be 'text/plain' and the Content-Types of the other 583 body parts are implementation dependent. See section 6.3 for a 584 description of plain text content. 586 The following table shows the Content-Type of the message body for 587 the "notify-mailto-text-only" attribute: 589 "notify- Content-Type of Message Body 590 mailto-text- Message Body 591 only" 592 attribute 594 false 'text/plain' Human Consumable 596 true 'text/plain' or* Human Consumable plain text 598 'multipart' Human Consumable where one 599 body part is plain text 601 * The Content-Type depends on the implementation. A Printer MAY send 602 'text/plain' only or it MAY send several body parts of various 603 Content-Types within a message body whose Content-Type is 604 'multipart'. 606 6.3 Plain Text Content 608 When a Printer sends a plain text message, it MUST localize the text 609 using the values of the "notify-charset" and "notify-natural- 610 language" Subscription Object attributes. 612 Section 9.2 in [ipp-ntfy] specifies the information that a Delivery 613 Method MUST specify and a Printer SHOULD send. 615 A Printer SHOULD send the following localized information in the 616 message body. The specific wording of this information and its layout 617 are implementation dependent. 619 a)the Printer name (see Table 3) 620 b)omitted (see below). 621 c)for Printer Events only: 622 i) the Event (see Table 4) and/or Printer state information 623 (see Table 7) 624 d)for Job Events only: 625 i) the job identity (see Table 5) 626 ii) the Event (see Table 4) and/or Job state information (see 627 Table 6) 629 Item b) in the above list is omitted because the Printer sends the 630 time of the Event as an email header (see section 6.1.1 on the 631 'Date' header). 633 The subsections of this section specify the attributes that a Printer 634 MUST use to obtain this information. 636 The Printer MAY send additional information, depending on 637 implementation. 639 Notification Recipients MUST NOT expect to be able to parse the 640 message. 642 The next three sections define the attributes in Event Notification 643 Contents that are: 645 a)for all Events 647 b)for Job Events only 649 c)for Printer Events only 651 6.3.1 Event Notification Content Common to All Events 653 The Printer MUST send the following information. 655 There is a separate table for each piece of information. Each row in 656 the table represents a source value for the information and the 657 values are listed in order of preference, with the first one being 658 the preferred one. An implementation SHOULD use the source value from 659 the earliest row in each table. It MAY use the source value from 660 another row instead, or it MAY combine the source values from several 661 rows. An implementation is free to determine the best way to present 662 this information. 664 The tables in this section and following sections contain the 665 following columns for each piece of information: 667 a)Source of Value: the name of the attribute that supplies the 668 value for the Event Notification 670 b)Sends: 672 MAY: this is the only value used in the tables. It means that 673 the Printer OPTIONALLY sends this value. However, the Printer 674 SHOULD use at least one value from each table. 676 c)Source Object: the object from which the source value comes. 678 Table 3 lists the source of the information for the Printer Name. The 679 "printer-name" is more user-friendly unless the Notification 680 Recipient is in a place where the Printer name is not meaningful. For 681 example, an implementation could have the intelligence to send the 682 value of the "printer-name" attribute to a Notification Recipient 683 that can access the Printer via value of the "printer-name" attribute 684 and otherwise send the value of the "notify-printer-uri" attribute. 686 Table 3 - Printer Name in Event Notification Content 688 Source Value Sends Source Object 690 printer-name (name(127)) MAY Printer 692 notify-printer-uri (uri) MAY Subscription 694 Table 4 lists the source of the information for the Event name. A 695 Printer MAY combine this information with state information described 696 for Jobs in Table 6 or for Printers in Table 7. 698 Table 4 - Event Name in Event Notification Content 700 Source Value Sends Source Object 702 notify-subscribed-event (type2 keyword) MAY Subscription 704 6.3.2 Additional Event Notification Content for Job Events 706 This section lists the source of the additional information that a 707 Printer MUST send for Job Events. 709 Table 5 lists the source of the information for the job name. The 710 "job-name" is likely more meaningful to a user than "job-id". 712 Table 5 - Job Name in Event Notification Content 714 Source Value Sends Source Object 716 job-name (name(MAX)) MAY Job 718 job-id (integer(1:MAX)) MAY Job 720 Table 6 lists the source of the information for the job-state. If a 721 Printer supports the "job-state-message" and "job-detailed-state- 722 message" attributes, it SHOULD use those attributes for the job state 723 information, otherwise, it should fabricate such information from the 724 "job-state" and "job-state-reasons". For some Events, a Printer MAY 725 combine this information with Event information. 727 Table 6 - Job State in Event Notification Content 729 Source Value Sends Source Object 731 job-state-message (text(MAX)) MAY Job 733 job-detailed-status-messages (1setOf Job 734 text(MAX)) MAY 736 job-state (type1 enum) MAY Job 738 job-state-reasons (1setOf type2 keyword) MAY Job 740 6.3.3 Additional Event Notification Content for Printer Events 742 This section lists the source of the additional information that a 743 Printer MUST send for Printer Events. 745 Table 7 lists the source of the information for the printer-state. If 746 a Printer supports the "printer-state-message", it SHOULD use that 747 attribute for the job state information, otherwise it SHOULD 748 fabricate such information from the "printer-state" and "printer- 749 state-reasons". For some Events, a Printer MAY combine this 750 information with Event information. 752 Table 7 - Printer State in Event Notification Content 754 Source Value Sends Source Object 756 printer-state-message (text(MAX)) MAY Printer 758 printer-state (type1 enum) MAY Printer 760 printer-state-reasons (1setOf type2 MAY Printer 761 keyword) 763 printer-is-accepting-jobs (boolean) MAY Printer 765 6.4 Examples 767 This section contains three examples. One is a Job Event and the 768 other two are Printer Events, the latter in Danish. 770 A Printer implementation NEED NOT generate Event Notification content 771 that is identical or even similar to these examples. In fact it would 772 be unfortunate if every implementation copied these example as is. 773 These examples merely show some possibilities and are not necessarily 774 the best way to convey information about an Event. 776 6.4.1 Job Event Example 778 This section contains an example of an Event Notification of a Job 779 Event. 781 A Subscribing Client Mike Jones (who works for xyz Corp.) performs a 782 Subscription Creation Operation as part of the Print-Job operation on 783 Printer "ipp://tiger@abc.com". Mike Jones specifies that the "job- 784 name" is "financials". Mike is printing the Job for Bill Smith at abc 785 Corp. The Subscription Object then has the following attributes: 787 Attribute Name Attribute Value 789 notify-recipient-uri mailto:bsmith@abc.com 791 notify-events job-completed 793 notify-user-data mjones@xyz.com 795 notify-mailto-text-only true 797 notify-charset us-ascii 799 notify-natural-language en-us 801 notify-subscription-id 35692 803 notify-sequence-number 0 805 notify-printer-up-time 34593 807 notify-printer-uri ipp://tiger@abc.com 809 notify-job-id 345 811 notify-subscriber-user-name mjones 813 When the Job completes, the Printer generates and sends the following 814 email message: 816 Date: 17 Jul 00 1632 PDT 817 From: tiger 818 Subject: print job: 'financials' completed 819 Sender: mjones@xyz.com 820 Reply-to: mjones@xyz.com 821 To: bsmith@abc.com 822 Content-type: text/plain 824 printer: tiger 825 job: financials 826 job-state: completed 828 The reader should note that the phrases are not identical to IPP 829 keywords. They have been localized to English. 831 6.4.2 Printer Event Example 833 This section contains an example of an Event Notification of a 834 Printer Event. 836 A Subscribing Client Peter Williams, a Printer admin, performs a 837 Create-Printer-Subscriptions operation on Printer 838 "ipp://tiger@abc.com". The Subscription Object then has the following 839 attributes: 841 Attribute Name Attribute Value 843 notify-recipient-uri mailto:pwilliams@abc.com 845 notify-events printer-state-changed 847 notify-mailto-text-only true 849 notify-charset us-ascii 851 notify-natural-language en-us 853 notify-subscription-id 4623 855 notify-sequence-number 0 857 notify-printer-uptime 23002 859 notify-printer-uri ipp://tiger@abc.com 861 notify-lease-expiration-time 0 863 notify-subscriber-user-name pwilliams 865 When the Printer jams, the Printer generates and sends the following 866 email message: 868 Date: 29 Aug 00 0832 PDT 869 From: tiger 870 Subject: printer: 'tiger' has stopped 871 To: pwilliams@abc.com 872 Content-type: text/plain 874 Printer tiger has stopped with a paper jam. 876 The reader should note that the phrases are not identical to IPP 877 keywords. They have been localized to English. 879 6.4.3 Printer Event Example (localized to Danish) 881 This section contains an example of an Event Notification of a 882 Printer Event localized to Danish. 884 A Subscribing Client Per Jensen, a Printer admin, performs a Create- 885 Printer-Subscriptions operation on Printer "ipp://tiger@def.dk". The 886 Subscription Object then has the following attributes: 888 Attribute Name Attribute Value 890 notify-recipient-uri mailto:pjensen@def.dk 892 notify-events printer-state-changed 894 notify-mailto-text-only true 896 notify-charset utf-8 898 notify-natural-language da 900 notify-subscription-id 50225 902 notify-sequence-number 0 904 notify-printer-uptime 53217 906 notify-printer-uri ipp://tiger@def.dk 908 notify-lease-expiration-time 0 910 notify-subscriber-user-name pjensen 912 When the Printer jams, the Printer generates and sends the following 913 email message: 915 Date: 29 Jan 00 0832 CET 916 From: tiger 917 Subject: Printeren 'tiger' er standset 918 To: pjensen@def.dk 919 Content-type: text/plain;charset=utf-8 921 Printerens navn er 'tiger'. 922 Printeren er standset. 923 Aarsagen er papir stop. 925 7 Conformance Requirements 927 The 'mailto' Delivery Method is RECOMMENDED for a Printer to support. 929 If the Printer supports the 'mailto' Delivery Method, the Printer 930 MUST: 932 1.meet the conformance requirements defined in [ipp-ntfy]. 934 2.support the "notify-mailto-text-only" Subscription Object 935 attribute defined in section 5.1.1. 937 3.support the syntax for the "notify-recipient-uri" Subscription 938 Object attribute defined in section 5.2.1 940 4.support the use for the "notify-user-data" Subscription Object 941 attribute defined in section 5.2.2 943 5.support SMTP for sending Event Notifications. 945 6.support the 'text/plain' Content-Type for the message body. 947 7.support sending Event Notification via email with the content 948 specified in section 5.2. 950 8 IANA Considerations 952 Because the 'mailto' URL scheme is already defined in a standards 953 track document [RFC 2368] and has been registered with IANA as a URL 954 scheme, this document does not require that the mailto URL scheme be 955 further registered as a protocol scheme. 957 The rest of this section contains the exact registration information 958 for IANA to add to the various IPP Registries according to the 959 procedures defined in RFC 2911 [RFC2911] section 6 to cover the 960 definitions in this document. 962 Note to RFC Editors: Replace RFC NNNN below with the RFC number 963 for this document, so that it accurately reflects the content of 964 the information for the IANA Registry. 966 8.1 Attribute Registration 968 The following table lists the attribute defined in this document. 969 This is to be registered according to the procedures in RFC 2911 970 [RFC2911] section 6.2. 972 Subscription Template attributes: Ref. Section: 973 notify-mailto-text-only (boolean) RFC NNNN 5.1.1 975 The resulting attribute registration will be published in the 976 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attributes/ 978 area. 980 8.2 Additional uriScheme Attribute Value Registration for the 981 "operations-supported" Printer Attribute 983 The following table lists the uriScheme value defined in this 984 document as an additional uriScheme value for use with the "notify- 985 schemes-supported" Printer attribute defined in [ipp-ntfy]. This is 986 to be registered according to the procedures in RFC 2911 [RFC2911] 987 section 6.1. 989 uriScheme Attribute Values: Ref. Section: 990 mailto RFC NNNN 5.2.1 992 The resulting uri scheme attribute value registration will be 993 published in the 994 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute- 996 values/notify-schemes-supported/ 997 area. 999 9 Internationalization Considerations 1001 This Delivery Method presents no internationalization considerations 1002 beyond those covered in the [ipp-ntfy] document, and sections 6.1.3 1003 and 6.2 of this document. 1005 The Notification Recipient is expected to present the email as 1006 received because the Printer does all necessary localization to the 1007 Event Notification contents. 1009 10 Security Considerations 1011 The biggest security concern is that a Subscribing Client will cause 1012 unsolicited Event Notifications to be sent to third parties, 1013 potentially creating denial-of-service problems (i.e., spam). The 1014 problem is even worse if the third parties are distribution lists. 1016 There exist scenarios where third party notification is required (see 1017 Scenario #2 and #3 in [ipp-not-req]). The fully secure solution 1018 would require active agreement of all persons before they can become 1019 Notification Recipients. However, requirement #9 in [ipp-req] 1020 ("There is no requirement for IPP Printer receiving the print request 1021 to validate the identity of an event recipient") argues against this. 1022 To minimize the risk, a Printer could disallow third party 1023 Notification Recipients (a traditional facsimile model). 1025 The Delivery Method recommends that the Subscribing Client supply his 1026 or her email address as the value of the "notify-user-data" attribute 1027 in the Subscription Creation Operation when the Notification 1028 Recipient is a third party. To reduce the chance of spamming or 1029 identify the spammer, a Printer could disallow third party 1030 Notification Recipients if the Subscribing Client doesn't supply the 1031 "notify-user-data" attribute with a valid email address. 1033 Some firewall administrators prevent mail attachments from being 1034 accepted into their organizations because of the problem of the 1035 attachments containing computer viruses. The 'mailto' Delivery 1036 Method allows the Subscribing Client to request that the Content-Type 1037 of a message body be 'text/plain'. 1039 11 References 1041 [ipp-iig] 1042 Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P., 1043 "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers- 1044 guide-v11-03.txt, work in progress, July 17, 2001. 1046 [ipp-ntfy] 1047 Herriot, R., Hastings, T., Isaacson, S., Martin, J., deBry, R., 1048 Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP 1049 Event Notifications and Subscriptions", , July 17, 2001. 1052 [RFC821] 1053 Jonathan B. Postel, "Simple Mail Transfer Protocol", RFC 821, 1054 August, 1982. 1056 [RFC822] 1057 David H. Crocker, "Standard For The Format Of ARPA Internet Text 1058 Messages", RFC 822, August 13, 1982. 1060 [RFC1341] 1061 N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 1062 Extensions): Mechanisms for Specifying and Describing the Format of 1063 Internet Message Bodies", RFC 1341, June, 1992. 1065 [RFC1521] 1067 N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 1068 Extensions) Part One: Mechanisms for Specifying and Describing the 1069 Format of Internet Message Bodies", RFC 1521, September 1993. 1071 [RFC1891] 1072 K. Moore, "SMTP Service Extension for Delivery Status 1073 Notifications", RFC 1891, January 1996 1075 [RFC2026] 1076 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 1077 2026, October 1996. 1079 [RFC2046] 1080 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1081 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1082 RFC 2616, June 1999. 1084 [RFC2368] 1085 P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL scheme", RFC 1086 2368, July 1998. 1088 [RFC2616] 1089 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1090 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1091 RFC 2616, June 1999. 1093 [RFC2633] 1094 B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633, 1095 June 1999. 1097 [RFC2910] 1098 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1099 Protocol/1.1: Encoding and Transport", RFC 2910, September, 2000. 1101 [RFC2911] 1102 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1103 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, 1104 September, 2000. 1106 12 Author's Addresses 1108 Robert Herriot 1109 Xerox Corporation 1110 3400 Hillview Ave., Bldg #1 1111 Palo Alto, CA 94304 1113 Phone: 650-813-7696 1114 Fax: 650-813-6860 1115 Email: robert.herriot@pahv.xerox.com 1117 Henrik Holst 1118 i-data international a/s 1119 Vadstrupvej 35-43 1120 2880 Bagsvaerd, Denmark 1122 Phone: +45 4436-6000 1123 Fax: +45 4436-6111 1124 e-mail: hh@i-data.com 1126 Tom Hastings 1127 Xerox Corporation 1128 737 Hawaii St. ESAE 231 1129 El Segundo, CA 90245 1131 Phone: 310-333-6413 1132 Fax: 310-333-5514 1133 e-mail: hastings@cp10.es.xerox.com 1135 Carl-Uno Manros 1136 Xerox Corporation 1137 737 Hawaii St. ESAE 231 1138 El Segundo, CA 90245 1140 Phone: 310-333-8273 1141 Fax: 310-333-5514 1142 e-mail: manros@cp10.es.xerox.com 1144 IPP Web Page: http://www.pwg.org/ipp/ 1145 IPP Mailing List: ipp@pwg.org 1147 To subscribe to the ipp mailing list, send the following email: 1148 1) send it to majordomo@pwg.org 1149 2) leave the subject line blank 1150 3) put the following two lines in the message body: 1151 subscribe ipp 1152 end 1154 Implementers of this specification document are encouraged to join 1155 IPP Mailing List in order to participate in any discussions of 1156 clarification issues and review of registration proposals for 1157 additional attributes and values. In order to reduce spam the 1158 mailing list rejects mail from non-subscribers, so you must subscribe 1159 to the mailing list in order to send a question or comment to the 1160 mailing list. 1162 13 Summary of Base IPP Documents 1164 The base set of IPP documents includes: 1166 Design Goals for an Internet Printing Protocol [RFC2567] 1167 Rationale for the Structure and Model and Protocol for the Internet 1168 Printing Protocol [RFC2568] 1169 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 1170 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 1171 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 1172 Mapping between LPD and IPP Protocols [RFC2569] 1173 Internet Printing Protocol (IPP): IPP Event Notifications and 1174 Subscriptions [ipp-ntfy] 1176 The "Design Goals for an Internet Printing Protocol" document takes a 1177 broad look at distributed printing functionality, and it enumerates 1178 real-life scenarios that help to clarify the features that need to be 1179 included in a printing protocol for the Internet. It identifies 1180 requirements for three types of users: end users, operators, and 1181 administrators. It calls out a subset of end user requirements that 1182 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 1183 been added to IPP/1.1. 1185 The "Rationale for the Structure and Model and Protocol for the 1186 Internet Printing Protocol" document describes IPP from a high level 1187 view, defines a roadmap for the various documents that form the suite 1188 of IPP specification documents, and gives background and rationale 1189 for the IETF working group's major decisions. 1191 The "Internet Printing Protocol/1.1: Model and Semantics" document 1192 describes a simplified model with abstract objects, their attributes, 1193 and their operations that are independent of encoding and transport. 1194 It introduces a Printer and a Job object. The Job object optionally 1195 supports multiple documents per Job. It also addresses security, 1196 internationalization, and directory issues. 1198 The "Internet Printing Protocol/1.1: Encoding and Transport" document 1199 is a formal mapping of the abstract operations and attributes defined 1200 in the model document onto HTTP/1.1 [RFC2616]. It defines the 1201 encoding rules for a new Internet MIME media type called 1202 "application/ipp". This document also defines the rules for 1203 transporting over HTTP a message body whose Content-Type is 1204 "application/ipp". This document defines the 'ippget' scheme for 1205 identifying IPP printers and jobs. 1207 The "Internet Printing Protocol/1.1: Implementer's Guide" document 1208 gives insight and advice to implementers of IPP clients and IPP 1209 objects. It is intended to help them understand IPP/1.1 and some of 1210 the considerations that may assist them in the design of their client 1211 and/or IPP object implementations. For example, a typical order of 1212 processing requests is given, including error checking. Motivation 1213 for some of the specification decisions is also included. 1215 The "Mapping between LPD and IPP Protocols" document gives some 1216 advice to implementers of gateways between IPP and LPD (Line Printer 1217 Daemon) implementations. 1219 The "IPP Event Notifications and Subscriptions" document defines an 1220 extension to IPP/1.0 [RFC2566, RFC2565] and IPP/1.1 [RFC2911, 1221 RFC2910]. This extension allows a client to subscribe to printing 1222 related Events and defines the semantics for delivering asynchronous 1223 Event Notifications to the specified Notification Recipient via a 1224 specified Delivery Method (i.e., protocols) defined in (separate) 1225 Delivery Method documents. 1227 14 Full Copyright Statement 1229 Copyright (C) The Internet Society (2000). All Rights Reserved. 1231 This document and translations of it may be copied and furnished to 1232 others, and derivative works that comment on or otherwise explain it 1233 or assist in its implementation may be prepared, copied, published 1234 and distributed, in whole or in part, without restriction of any 1235 kind, provided that the above copyright notice and this paragraph are 1236 included on all such copies and derivative works. However, this 1237 document itself may not be modified in any way, such as by removing 1238 the copyright notice or references to the Internet Society or other 1239 Internet organizations, except as needed for the purpose of 1240 developing Internet standards in which case the procedures for 1241 copyrights defined in the Internet Standards process must be 1242 followed, or as required to translate it into languages other than 1243 English. 1245 The limited permissions granted above are perpetual and will not be 1246 revoked by the Internet Society or its successors or assigns. 1248 This document and the information contained herein is provided on an 1249 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1250 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1251 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1252 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1253 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1255 Acknowledgement 1257 Funding for the RFC Editor function is currently provided by the 1258 Internet Society.