idnits 2.17.1 draft-schmeing-smtp-priorities-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 886. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 23, 2006) is 6456 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) ** Downref: Normative reference to an Experimental RFC: RFC 1845 (ref. '2') ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2476 (ref. '6') (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 2821 (ref. '7') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3265 (ref. '10') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3462 (ref. '12') (Obsoleted by RFC 6522) ** Downref: Normative reference to an Informational RFC: RFC 3487 (ref. '15') Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Schmeing 3 Internet-Draft FGAN 4 Expires: February 24, 2007 J. Brendecke 6 K. Carlberg 7 G11 8 August 23, 2006 10 SMTP Service Extension for Priority Message Handling 11 draft-schmeing-smtp-priorities-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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 28 material 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 at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 24, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This memo defines an extension to the SMTP (Simple Mail Transfer 45 Protocol) service whereby messages are sent with a priority to 46 achieve a certain order in which the messages are transferred by an 47 MTA (Message Transfer Agent). This priority or precedence order is 48 used instead of the first-come-first-serve rule. This extension is 49 not to be confused with "Importance of a Message" which is widely 50 deployed using an email header such as Importance or even Priority or 51 Precedence with common values of HIGH, NORMAL and LOW. Importance of 52 a Message does not affect the priority of the transport itself in any 53 way. Nevertheless, there may be policy defined relations between 54 priorities and importance indicators. 56 This extension uses the term priority in the meaning of expedited 57 treatment of a message by the server according to its priority. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Terminology & background . . . . . . . . . . . . . . . . . . . 5 64 4. Framework for the Priority Extension . . . . . . . . . . . . . 6 65 5. The Priority Service Extension . . . . . . . . . . . . . . . . 8 66 5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 8 67 5.1.1. Probability . . . . . . . . . . . . . . . . . . . . . 9 68 5.1.2. Preemption of sessions or transactions . . . . . . . . 9 69 5.1.3. Handling of emails with multiple recipients . . . . . 10 70 5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 10 71 5.3. Resolving conflicts for the sending order of messages 72 with the same priority . . . . . . . . . . . . . . . . . . 10 73 5.4. Size Limitation . . . . . . . . . . . . . . . . . . . . . 11 74 5.5. Further Constraints . . . . . . . . . . . . . . . . . . . 12 75 6. Recipient Dependent Priority . . . . . . . . . . . . . . . . . 13 76 6.1. Maillists, Aliases and Forwarding . . . . . . . . . . . . 13 77 7. NameSpaces . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.1. Conflicts with external constraints . . . . . . . . . . . 15 79 7.2. Handling Non-priority Servers and Mismatching Policies . . 16 80 7.3. Recipients without priorities . . . . . . . . . . . . . . 17 81 7.4. Invalid priority levels . . . . . . . . . . . . . . . . . 17 82 7.5. Mappings to other NameSpaces . . . . . . . . . . . . . . . 17 83 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 11. List of abbreviations . . . . . . . . . . . . . . . . . . . . 22 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 12.1. Informative Reference . . . . . . . . . . . . . . . . . . 23 89 12.2. Normative References . . . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 91 Intellectual Property and Copyright Statements . . . . . . . . . . 26 93 1. Introduction 95 Prioritization is an issue that gains attention when resources are 96 scarce and sets of users (and their data) are considered more 97 important than others. Military Message Handling Systems (MMHS) such 98 as AUTODIN and the Defense Messaging System (DMS), have requirements 99 to prioritize their traffic to help ensure that important data is 100 given preferential treatment over what would normally be viewed as 101 best effort. 103 Deployments of MMHS typically include the ability to preempt or 104 displace less important data traffic. This displacement can be in 105 the form of dropped packets, removal of reservations or termination 106 of end-to-end sessions. Outside MMHS systems such as GETS rely on 107 increasing the probability of obtaining resources or successfully 108 forwarding downstream packets instead of preempting resources. In 109 either case, the critical feature incumbent in both systems is an 110 ability to prioritize data in anticipation of resource contention. 112 The Simple Mail Transfer Protocol [7] (SMTP) is one of the most 113 popular applications used over the Internet by today's general 114 public. The examinations documented in [1] show that SMTP, including 115 some SMTP extensions, also provides most of the features requested by 116 the military (a user community whose requirements are more stringent 117 than the general public). But one of the most important requirements 118 of MMHS not provided by SMTP is priority or precedence in handling 119 between Message Transfer Agents (MTA). 121 This document defines an SMTP Service Extension offering such a 122 service allowing Mail Transfers Agents to determine which emails 123 require expedited handling. 125 2. Terminology 127 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 128 and "MAY" in this document are to be interpreted as described in "Key 129 words for use in RFCs to Indicate Requirement Levels" [4]. 131 The terms SMTP client and SMTP server are used with the same 132 definition as given in section 2.3.2 of RFC 2821 [7]: 134 o The SMTP client is the (computer) process initiating an SMTP 135 session and controlling it issuing commands to the server. 137 o The SMTP server is the process waiting for clients to connect and 138 executing the commands from the client. 140 As this document is concerned with SMTP only, the terms client and 141 server may as well be used without the SMTP prefix. 143 An email is waiting to be sent, if it resides in the queue of an MTA 144 and can be send to the next hop or delivered to its final 145 recipient(s) once available resources at the sending MTA allow this. 146 Emails having their processing delayed for some reason are NOT 147 waiting to be sent during this delay. The most important reason for 148 emails to be delayed is a transient error response from the next MTA 149 to which the email must be transferred. 151 An email is ready to be sent, if it is waiting to be sent and either 152 no emails with higher priority are waiting to be sent or available 153 resources allow to send more emails in parallel than the number of 154 emails with higher priorities that are waiting to be sent. Note that 155 an email may be ready to be sent but the transfer or delivery process 156 can not yet be initiated, because the number of emails ready to be 157 sent exceeds the number of emails that can be processed in parallel. 159 The policy defining the use of priorities within a given NameSpace is 160 called "NameSpace Policy". A NameSpace is a name (or label) for a 161 finite and ordered set of priorities. In some instances, this memo 162 or a NameSpace Policy may allow additions to the definitions of the 163 NameSpace Policy. These additions are called "local policy". 165 3. Terminology & background 167 RFC 3487 [15] articulates a set of requirements for prioritizing 168 access to services and resources using the Session Initiation 169 Protocol (SIP). As in the case of SMTP, SIP has a priority field 170 used to convey the importance of a session (or message, in the case 171 of SMTP) to the end-user. However, the value within the field was 172 not meant for intermediate nodes. From these requirements, the SIP 173 working group defined a new optional Resource Priority field in RFC 174 4412 [16] for the SIP protocol. The new field was divided into two 175 distinct parts. The first is Value subfield, which contains the 176 priority associated with the SIP message. The second subfield is the 177 NameSpace, which identifies a set or family of 1 or more priorities. 178 The strength in this approach is that support for the prioritization 179 feature is not bound to a one-size-fits-all design. As an example, 180 the DoD/NATO community has an existing set of 5 priorities used for 181 its messaging system. Other communities of interest may have sets 182 that are smaller or larger than that currently used by DoD/NATO. 184 Underneath the SIP layer, and its Resource Priority extension, on- 185 going work is being done by the NSIS working group to define a QSPEC 186 that includes fields correlating to SIP's NameSpace/Value tuple. In 187 addition, the TSV Working Group is in the process of defining an 188 extension to RSVP that defines a priority policy element correlating 189 to the NameSpace/Value tuple. Both of these efforts are aimed at 190 facilitating underlying signaling of network elements to obtain 191 resources based on the priority set at the application layer. 193 4. Framework for the Priority Extension 195 o The textual name of this extension is "Priority Message Handling". 197 o The EHLO-Keyword is PRIORITY. 199 o One mandatory parameter is used with this keyword. This parameter 200 is a list of NameSpaces supported by the server. The syntax for 201 this value is described below. The "token-nodot" production is 202 copied from RFC 3265 [10]. 204 namespace-list = namespace * (COMMA namespace) 205 namespace = token-nodot 206 token-nodot = 1*(alphanum / "-" / "!" / "%" / "*" / 207 " " / "+" / "`" / "'" / "~") 209 A NameSpace is a name of an ordered set of priorities with 210 attached policy. 212 o No new SMTP verbs are defined. 214 o One optional parameter using the keyword "PRIORITY" is added to 215 the RCPT TO command. The value associated with this parameter is 216 in alpha-numeric form. The syntax of the value is : 218 priority-arg = "PRIORITY" EQUAL value 219 value = namespace "." priority 220 priority = token-nodot 222 o Two examples of PRIORITY parameters are shown below: 224 PRIORITY=Example.1 226 PRIORITY=AnotherExample.Flash 228 o The 'value' parameter in the 'PRIORITY' extension indicates the 229 concatenated tuple of the 'namespace', the 'priority' within that 230 NameSpace and the "." character separating the two. An entry in a 231 'namespace' must be unique from all other NameSpaces. Entries in 232 a 'priority' must be unique within a NameSpace, but they may be 233 the same as those in other NameSpaces. 235 o The maximum length of a RCPT TO command line is increased by 9 236 characters plus the length of the 'value-list' by the possible 237 addition of the PRIORITY keyword and value. 239 o As one of the most likely instances to assign transport priorities 240 is the submitting party of an email (i.e. the originator or 241 sender), this extension is valid for message submission according 242 to RFC 2476 [6]. 244 5. The Priority Service Extension 246 The priority of a message expresses itself in the order they are 247 transfered from the client to the server. This is largely 248 independent from the order in which they where received by the 249 server. The Priority Service Extension increases the possibilities 250 of SMTP service extensions such as Deliver-By [8] and Delivery Status 251 Notification [11][14][13][12] or (non-standard) header fields such as 252 Importance. 254 In military scenarios, priorities usually come with additional 255 associated constraints. Examples are limitations of the message size 256 or the allowed delivery time. 258 5.1. Expedited Transfer 260 The main service provided by the Priority Message Handling SMTP 261 Service Extension is expedited transfer of emails with a higher 262 priority. Therefore a client that has more than one email to send at 263 a given time MUST send those with a higher priority before those with 264 a lower one. 266 Priorities are assigned on a per-recipient basis. The priority of an 267 email is the highest priority assigned to any of the yet unprocessed 268 recipients. Thus the priority of the email may vary while it is 269 processed by an MTA or UA and may be different at different MTAs. 270 The priority of any given recipient is nevertheless constant. 272 As a default policy, emails with higher priority waiting to be sent 273 by a client MUST NOT initiate transactions for emails with lower 274 priorites. It MAY however send an email with highest priority even 275 to recipients with lower priorities if this can be done within the 276 same transaction as the higher priorities. Policy associated with a 277 specific NameSpace may override this default policy; an example being 278 the use of a weighted round robin initiation of transactions in order 279 to prevent a starving of resources from lower priorities. 281 The handling of messages with the same priority level is described in 282 Section 5.3. 284 Especially in networks with limited available data rate the actual 285 transfer over the network may create a significant portion of the 286 overall delivery time. Besides the actions taken at the application 287 level it can thus be important to deploy priority or precedence 288 mechanisms offered by the network itself to ensure timely delivery of 289 the emails. One example would be the use of RSVP and the work-in- 290 progress effort extension to RSVP that prioritizes reservations. If 291 such services are available, it is a matter of NameSpace Policy to 292 decide whether to use them. The mapping from the priorities defined 293 at the SMTP level to those offered by the underlying network is as 294 well to be defined in the NameSpace Policy. If the NameSpace Policy 295 does not regulate the use of network priorities, their use can be 296 defined by local policy 298 Most current SMTP MTAs are capable of handling several inbound and 299 outbound connections at once. With this feature it should be 300 possible to start additional outbound connections for emails with 301 higher priorities even if there are already several connections 302 running for other emails. The manner in which expedited transfer can 303 be accomplished is divided into two approaches. One is probability, 304 the other involves preemption, both of which are described in more 305 detail below. 307 5.1.1. Probability 309 As the name suggests, probabiblity involves increasing the chances of 310 obtaining resources without adversely affecting previously 311 established connections. One example would involve requesting 312 resources set aside for specific priority levels. If these 313 additional resources are exhausted, then the desired connection is 314 denied. Queues, new timers, or combinations thereof can be used to 315 facilitate the higher priority requests, but the key is that 316 mechanisms focus on increasing the probability of message transfer. 318 5.1.2. Preemption of sessions or transactions 320 Preemption is binary type of action and focusses only on a 321 comparision of priorities to determine if previously established 322 transactions must be displaced in favor of higher priority requests. 323 If no additional connection is possible, a client MUST abort a 324 running session for emails with lower priority no later than directly 325 after the current transaction. The client even MAY interrupt an 326 active transaction and SHOULD do this, if otherwise constraints such 327 as delivery time would be violated for the email with higher 328 priority. This preliminary termination of sessions or transactions 329 is called preemption. 331 If preemption of running transactions occurs, the client MUST preempt 332 the lowest number of transactions sufficient to process the higher 333 priority emails. It must chose the transactions for the emails with 334 the lowest priorities currently processed. NameSpace Policies and 335 local policies MAY add additional criteria to choose the transaction 336 to be preempted in the case that more transactions than required 337 would qualify for preemption due to the priority of the emails. 338 Regulations from local policy MUST NOT be applied before NameSpace 339 Policy and MUST NOT conflict with NameSpace policy settings. If 340 after applying the priority test and all criteria defined by 341 applicable NameSpace Policy and the local policy still the number of 342 transactions to preempt is greater than needed, the decision is left 343 to the implementation. 345 If the client has an option to interrupt transactions in a way that 346 it can be restarted at the interruption point later, it SHOULD deploy 347 it. An example for a mechanism providing such a service is the "SMTP 348 Service Extension for Checkpoint/Restart" defined in RFC 1845 [2] 350 If a client opts for the preemption of sessions instead of 351 transactions, it MUST preempt the next session that reaches the end 352 of a transaction independent of the priority of the emails being 353 processed. 355 5.1.3. Handling of emails with multiple recipients 357 If a client has to send an email with multiple recipients bearing 358 different priorities to the same server, it SHOULD do so in one 359 transaction treating the email according to the highest priority set 360 for any of the recipients. 362 The reorganization of the transfer order MUST NOT alter or even 363 corrupt the emails, therefore allowing safe transmission of all 364 emails in dependency of their priority. 366 5.2. Timely Delivery 368 An important constraint usually associated especially with higher 369 priority levels is, that messages with that priority have to reach 370 its destination within a defined period of time. In some cases, 371 higher priorities mean shorter maximum allowed time of delivery. 373 As SMTP does not natively offer a service for timely delivery, the 374 decision whether to use delivery time constraints for any or all 375 priority levels is left to the NameSpace Policy. 377 The "Deliver By SMTP Service Extension" (Deliver-By Extension) 378 defined in [8] is an example of an SMTP extension providing a service 379 that can be used to implement such constraints. 381 If applicable NameSpace Policy does not specify time constraints for 382 a given priority, no such constraints are applied. 384 5.3. Resolving conflicts for the sending order of messages with the 385 same priority 387 If two or more emails with the same priority are ready to be sent at 388 the same time, clients SHOULD send them in parallel if possible. 389 NameSpace Policy and local policy MAY define rules to determine the 390 order in which emails of the same priority are sent if the number of 391 emails ready to be sent exceeds the number of emails that can be 392 processed in parallel. Definitions from NameSpace Policy always take 393 precedence over definitions from local policy. NameSpace Policy MAY 394 disallow local policy to define addtitional criteria to determin 395 sending order. 397 If all applicable rules to determine the sending order from this 398 memo, applicable NameSpace Policy and (if permitted) local policy 399 still leave more emails ready to be sent than can be processed in 400 parallel, the final decision is left to the implementation. 402 5.4. Size Limitation 404 The larger a message, the longer the time required to send it over a 405 given connection. In constrained networks this can impair the 406 possibility of the MTS to deliver large messages with high priorities 407 in time. Therefore, NameSpace Policy MAY define size constraints for 408 any or all of its priority levels. 410 These constraints can always be enforced independent of the SMTP 411 Service Extensions supported by the server receiving the email. It 412 is always possible for the server to count the number of received 413 octets after the client indicated the end of the email and base the 414 decision to accept or reject the email on this number. 416 Therefor, after completely receiving the content of the email the 417 server MUST check that the actual received size does not exceed the 418 lowest size limitation allowed by the priorities set for all 419 recipients. If the actual size is too big for at least one 420 recipient, the server MUST NOT send a successful reply but MUST 421 reject the email with an error code of "556 Priority defined size 422 limit exceeded". If the client uses an SMTP Service Extension which 423 allows to transmit the content in several chunks, such as [9], the 424 server SHOULD check the current size after every chunk and SHOULD 425 abort the email with the above error code as soon as the size 426 constraint applicable for the email is violated. 428 In addition to just counting the received octets while the email is 429 being transmitted, a client and server may also deploy mechanisms, 430 that allow for an earlier detection of size violations. An example 431 for such a service is the "SMTP Service Extension for Message Size 432 Declaration" (SIZE Extension) from RFC 1870 [3]. 434 The SIZE Extension allows a client to declare the size of the email 435 with an optional parameter to the MAIL FROM: SMTP command. This 436 parameter can be used for example to decide for each individual 437 recipient whether the email fulfils the size constraints. Unless 438 NameSpace Poicy defines another course of action, if the size 439 provided with the SIZE argument of the MAIL FROM: command is too 440 large for the priority set for any of the recipients, the recipient 441 MUST be rejected with an error code of "556 Priority defined size 442 limit exceeded". Processing for the remaining recipients is to 443 continue normally. 445 If the NameSpace Policy does not address size constraints, the 446 default is that emails may be of arbitrary size. Constraints imposed 447 by other circumstances such as available storage space or general 448 limitations are, of course, unaffected by this. 450 5.5. Further Constraints 452 Depending on the actual scenario in which this priority extension is 453 deployed, it may be necessary to add further constraints to certain 454 priority levels. Although it is strongly believed that limiting the 455 delivery time and email size should be sufficient for most if not all 456 purposes, NameSpace Policy may add further constraints such as 457 limitations on content types or security classifications. 459 For example, in military applications of priorities, messages without 460 classification or with low classification may only be sent at the 461 lower priority levels. 463 6. Recipient Dependent Priority 465 Often, not all recipients need to receive the message with the same 466 (high) priority. For example copy (CC, carbon copy) and blind copy 467 (BCC, blind carbon copy) recipients usually can accept a lower 468 priority than the primary recipient(s) because they do not have to 469 act on the message but receive it only for informational purposes. 471 Limiting the high priority messages only to the primary recipient 472 complies with the basic principle of using high priorities only if 473 really necessary. So the number of high priority messages is reduced 474 to a minimum. Assigning every recipient an individual priority could 475 be realized by sending the same message several times. This is 476 unnecessary, non-practical and a waste of resources. Binding the 477 priority to the recipient allows to deploy the multiple recipient per 478 transaction feature of SMTP even when having different priorities for 479 different recipients of the message. 481 To lower the burden on the network, an MTA SHOULD send any message to 482 as many recipients as possible with one transaction, even if the 483 recipients have different priorities bound to them. In this case, 484 the MTA MUST treat the email according to the highest priority bound 485 to any of the recipients and MUST retain the original priority values 486 for each recipient. 488 A recipient address, that has a priority other than the non-priority 489 set, is called a prioritized recipient (address). 491 6.1. Maillists, Aliases and Forwarding 493 Several options exist to translate the address of an email recipient 494 into one or more other addresses. Examples for this are aliases, 495 maillist or email redirections e.g. via a .forward file. 497 Priorities are assigned for a reason. Therefore, if a prioritized 498 recipient address is to be translated or expanded as explained above, 499 the translating or expanding entity (maillist manager, MTA etc.) 500 SHOULD retain the original priority if possible and SHOULD set it for 501 all expanded or translated addresses. NameSpace Policy however MAY 502 deviate from this behavior for good reason. 504 7. NameSpaces 506 A NameSpace identifies a set of one or more alpha-numeric priorities. 507 These NameSpaces are registered with IANA and are unique for the 508 registry associated with the SMTP priority extension. Ideally a 509 given NameSpace satisfies the needs for groups of organizations and 510 user sets. As an example, a NameSpace that correlates to the Q.735.3 511 protocol in support of Multi-Level Precedence and Preemption (MLPP) 512 would be applicable to all messaging systems that support Q.735.3. 514 New NameSpaces MUST be defined as an Informational RFC after Expert 515 Review in accordance with the policy set forth in RFC 2434 [5]. The 516 Expert Reviewer will consult with the Application Area Directors and 517 the IEPREP mailing list. The following elements MUST be addressed 518 when registering a new NameSpace: 520 o Priority level(s) must be enumerated as a finite ordered list 522 o A priority algorithm must be defined and described. This 523 algorithm defines the schema of how messages are handled based on 524 their labeled priority. For example, one algorithm may describe 525 the use of preemption of resources of a lower priority message 526 (i.e., dropped message) to satisfy a higher priority message. 527 Another algorithm may involve queuing of messages based on 528 availability of extra resources set aside for specific priorities. 529 A third algorithm may be a hybrid of preemption and queuing. 531 o Any new new response codes (warning or Error) unique to the 532 NameSpace must be listed and explained. 534 o The document needs to specify a new row for the following table 535 that summarizes the features of the NameSpace. For the tabel 536 below, there is ONE NameSpace label and ONE Algorithm. There 537 N-number of levels, each having a corresponding Warning-Code OR 538 Error-Code. It is expected that the warning/error codes are the 539 same for each NameSpace.Priority tuple. Finally, an RFC is used 540 as the reference for the table of information. 542 NameSpace Algo Priority(s) Warn-Code Error-Code Reference 543 --------- -------- ----------- --------- ---------- --------- 544