idnits 2.17.1 draft-ietf-opes-rules-p-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 86 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 278: '.... Object writers SHOULD follow common ...' RFC 2119 keyword, line 279: '... MUST document actual operator seman...' RFC 2119 keyword, line 280: '... The interpreter MUST NOT allow object...' RFC 2119 keyword, line 449: '... MUST continue evaluating the expres...' 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 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 (September 16, 2003) is 7499 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2616' is defined on line 568, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational draft: draft-ietf-opes-architecture (ref. 'I-D.ietf-opes-architecture') -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services A. Beck 3 Internet-Draft Lucent Technologies 4 Expires: March 16, 2004 A. Rousskov 5 The Measurement Factory 6 September 16, 2003 8 P: Message Processing Language 9 draft-ietf-opes-rules-p-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 16, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 P is a simple configuration language designed for specification of 40 message processing instructions at application proxies. P can be used 41 to instruct an intermediary how to manipulate the application message 42 being proxied. Such instructions are needed in an Open Pluggable Edge 43 Services (OPES) context. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3. Language elements . . . . . . . . . . . . . . . . . . . . . . 6 50 3.1 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 3.2 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 3.3 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 3.4 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 3.5 Assignments . . . . . . . . . . . . . . . . . . . . . . . . . 9 55 4. Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 56 5. OPES Services . . . . . . . . . . . . . . . . . . . . . . . . 12 57 6. Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 59 8. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 61 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 62 Normative References . . . . . . . . . . . . . . . . . . . . . 19 63 Informative References . . . . . . . . . . . . . . . . . . . . 20 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 65 Intellectual Property and Copyright Statements . . . . . . . . 21 67 1. Introduction 69 The Open Pluggable Edge Services (OPES) architecture 70 [I-D.ietf-opes-architecture], enables cooperative application 71 services (OPES services) between a data provider, a data consumer, 72 and zero or more OPES processors. The application services under 73 consideration analyze and possibly transform application-level 74 messages exchanged between the data provider and the data consumer. 75 OPES processors need to be told what services are to be applied to 76 what application messages. P language can be used for this 77 configuration task. 79 In other words, P language primary objective is to express statements 80 similar to: 82 if message meets criteria C, 83 then apply service S; 85 Figure 1 87 Thus, P programs mostly deal with formulating message-dependent 88 conditions and executing services. 90 P design attempts to satisfy several conflicting goals: 92 flexibility: Application intermediaries deal with a wide range of 93 applications and protocols (SMTP, HTTP, RTSP, IM, etc.). The 94 language must be able to accommodate virtually all known tasks in 95 selecting a desired adaptation service for a message of a known 96 application protocol (and conceivable future applications). 98 efficiency: Language interpretation must be efficient enough to be 99 comparable with other message processing overheads at a typical 100 application proxy (e.g., interpreting HTTP headers to determine 101 response cachability). 103 simplicity: Typical configurations must be easy to write and 104 understand for a typical OPES system administrator. 106 correctness: Many message handling configurations are written without 107 direct access to intermediaries that will use those 108 configurations. The extent of off-line (compile-time) correctness 109 checks should catch all syntax errors and many common semantic 110 errors such as undefined values and type conflicts. 112 compactness: It is possible that some processing instructions will be 113 piggybacked as headers/metadata to messages they refer to, placing 114 stringent size requirements on language code. 116 security: It should be difficult if not impossible to write malicious 117 code that would result in security vulnerability of compliant 118 language interpreter. 120 While P addresses OPES needs, its design is meant to be applicable 121 for a variety of similar intermediary configuration tasks such as 122 access control list (ACL) specification and message routing in proxy 123 meshes or load-balancing environments. 125 P design is based on a minimal useful subset of features from several 126 programming languages such as R (S), Smalltalk, and C++. Technically 127 speaking, P is a single-assignment, lazy evaluation, strongly typed 128 functional programming language. 130 2. Syntax 132 P syntax is defined by the following Augmented Backus-Naur Form 133 (ABNF) [RFC2234]: 135 code = *(statement ";") 137 statement = assignment / function-call / if-statement 139 assignment = identifier ":=" expression 141 if-statement = "if" "(" expression ")" "{" code "}" 143 expression = 144 name / function-call / "{" code "}" 145 ... ; more to be defined (logical and arithmetic expressions) 147 name = identifier *( "." identifier) 149 function-call = name "(" [params] ")" 151 params = expression *( "," expression) 153 identifier = ALPHA *(ALPHA / DIGIT / "_") 155 ... ; more primitives to be defined as needed 157 Figure 2 159 XXX: add /* comments */. 161 3. Language elements 163 3.1 Objects 165 P is centered around the concept of an "object" that is similar to 166 objects from other object-oriented languages. An object is, 167 essentially, a piece of data or information. The value of an object 168 is indistinguishable from the object itself. Object type is defined 169 by the semantics of applicable operations and manipulations. Almost 170 everything in P is an object, even a piece of code. Here are a few P 171 objects, listed one per line: 173 0 174 "http://www.ietf.org/" 175 Core 176 { a := 1/0; } 178 Many objects contain other objects, often called members. Members 179 are accessible by their name, using the member access operator ("."). 180 Member access operator has a single parameter: the name of the member 181 to access. All P objects support "." operator, but not all objects 182 have members. Here are a few examples: 184 Http.message.headers 185 Core.interpreter.stop 186 "string".nosuchmember 188 Many objects support operators other than member access. For example, 189 member objects that support function call "()" operator are often 190 call methods. 192 Http.message.headers.have(header) 193 Core.interpreter.stop() 194 1 / 0 195 "string" + "string" 197 P operators are described in Section 3.2. below. 199 P does not have built-in facilities for describing object types. When 200 writing a P program, only objects known to interpreter (e.g., Core) 201 and objects generated by known objects (e.g., Core.import("Http")) 202 can be used. P supports loadable modules that can be used to add 203 objects to support new application protocols. In fact, P core 204 supports no application protocols directly. Instead, modules like 205 "Http" can be used to process messages depending on application 206 protocol being proxied. 208 No default (silent) object type conversion is supported. However, 209 explicit conversion (casting) is rarely needed because many methods 210 are polymorphic (can work with several object types). 212 3.2 Operators 214 Several operators are used in P to denote common operations. These 215 symbols are deemed to improve readability of P code as compared to 216 their spelled-out-in-English counterparts. 218 P Operators 220 +--------------+----------------------------------------------------+ 221 | operator | default semantics | 222 +--------------+----------------------------------------------------+ 223 | A == B | A is semantically equal to B; does not modify A or | 224 | | B. | 225 | | | 226 | A != B | semantical inequality, same as !(A == B). | 227 | | | 228 | !A | logical negation, same as (A == false) | 229 | | | 230 | A and B | logical concatenation, same as !(!A or !B) | 231 | | | 232 | A or B | logical disjunction (inclusive), same as !(!A or | 233 | | !B) | 234 | | | 235 | A + B | sum of A and B; does not modify A or B. | 236 | | | 237 | A * B | product of A and B; does not modify A or B. | 238 | | | 239 | A - B | difference between A and B; does not modify A or | 240 | | B. | 241 | | | 242 | A / B | ratio of A to B; does not modify A or B. | 243 | | | 244 | A.n | access to A's member named n; does not modify A; | 245 | | fails if A has no member named n. | 246 | | | 247 | A(...) | object A is to perform a function call with zero | 248 | | or more parameters; may modify A and/or parameters | 249 +--------------+----------------------------------------------------+ 251 Operator precedence defines natural evaluation order used in 252 mathematics and many programming languages. In the following list, 253 operators are ordered based on their precedence. Operators with 254 smaller precedence index are evaluated first. Operators with the same 255 precedence index are evaluated in the left-to-right order of 256 occurrence in an expression. 258 1. . 260 2. () 262 3. ! 264 4. * / 266 5. + - 268 6. == != 270 7. and 272 8. or 274 Except for the member access operator ("."). operators do not have to 275 be supported by an object. Moreover, operator semantics may differ 276 from one object to another (or even from one invocation to another 277 for the same object though the latter is unlikely to be common in 278 practice). Object writers SHOULD follow common operator semantics and 279 MUST document actual operator semantics when adding support for these 280 operators to their objects. The interpreter MUST NOT allow object 281 writers to change operator precedence. 283 Operators are not global special symbols but are passed to the object 284 for interpretation, along with their parameters. Applying an operator 285 is semantically equivalent to calling an object method. For example, 286 the following three expressions are equivalent: 288 a + b + c 289 (a.+(b)) + c 290 (a.+(b)).+(c) 292 Figure 6 294 The "a + b + c" form is preferred for purely visual reasons. Core P 295 module provides basic objects and operators for them (e.g., boolean 296 and integer). Application-specific modules usually provide 297 applications-specific objects; those objects usually have 298 application-specific methods and may not have methods to support 299 operations common for basic types. For example, an Http module 300 supplies an HTTP header object that does not have a "*" method. 302 3.3 Expressions 304 P expressions are used in if-statements to specify the condition for 305 the if-statement body to be interpreted. 307 if (Http.request.method == "GET" and time.current() > time.noon) { 308 ... 309 } 311 Figure 7 313 Evaluation of an expression stops when the value of an expression is 314 known and cannot be changed by further evaluation. This 315 short-circuiting optimization technique is common to many programming 316 languages. In the following example, the value of A will never be 317 interpreted when C is interpreted, regardless of the context where C 318 is used: 320 C := false and A; 321 if (C) { ... }; 322 if (!C) { ... }; 323 ... 325 Figure 8 327 3.4 Statements 329 Objects are manipulated using if-statements and function-calls. 331 if (Http.request.method == "GET") { 332 Services.applyOne(serviceFoo); 333 } 335 Figure 9 337 3.5 Assignments 339 Most procedural programming languages use variables to store 340 intermediate processing results. In such languages, a variable is 341 essentially a named piece of memory that can be assigned a value and 342 can be updated with new values as needed. P does not have such 343 variables. Instead, P uses a "single assignment" approach: an 344 expression can be tagged with a name and that name can be reused many 345 times in the program. On the surface, this is equivalent to having 346 all "traditional" variables declared as "constant". The following two 347 if-statements are semantically equivalent in P: 349 if (Http.request.headers.have(Http.makeHeader("Client-IP"))) {...} 351 h := Http.makeHeader("Client-IP"); 352 hs := Http.request.headers(); 353 if (hs.have(h)) {...} 355 Figure 10 357 If the expression changes, a new name must be used to tag the new 358 expression. After an assignment statement, the value of the name is 359 not the value of the expression, but the expression itself. Thus, 360 the following two code fragments are equivalent and make no sense in 361 P (the first fragment would make sense in languages such as C++): 363 h := Http.makeHeader("Client-IP"); 364 h := Http.makeHeader("Server-IP"); 366 h := Http.makeHeader("Client-IP"); 367 Http.makeHeader("Client-IP") := Http.makeHeader("Server-IP"); 369 Figure 11 371 The interpreter can but does not have to evaluate the expression 372 named in the assignment statement until the name is actually used in 373 an expression that requires evaluation (e.g., as a parameter of a 374 function call statement). This allows for optional performance 375 optimizations where only used expressions are evaluated. 377 P does not have user-defined functions. However, some code reuse is 378 possible because P code is a valid expression and, hence, can be 379 named and reused: 381 code := { ... complicated service action ... }; 382 if (condition1) { code; }; 383 ... 384 if (condition2) { code; }; 386 Figure 12 388 XXX: document whether expression has to be evaluated in the 389 assignment context or use context. Document name scope. 391 4. Modules 393 Application-specific support is available in P via modules. Basic P 394 primitives such as integer types and boolean operations comprise the 395 Core module. Module is an object. The Core modules supplies the 396 following methods to manipulate other modules: 398 Core.import("M"): load a module called "M" and return it as the 399 result. 401 Core.lookup(M): start looking up unresolved attributes and method 402 identifiers in a previously loaded module M. 404 The Core module is assumed to be loaded (and being looked up) before 405 the interpretation starts. 407 XXX: document lookup conflict resolution. 409 5. OPES Services 411 Services module contains basic attributes and methods for searching 412 and executing OPES services: 414 Services.findOne(URI): returns a service object that corresponds to 415 the specified URI. Fails if no corresponding object exists. 417 Services.applyOne(service, ...): applies the specified service to the 418 current application message and optionally supplies 419 service-specific application parameters. XXX: should parameters 420 include the part of the message to be modified or just services 421 metadata? 423 Here is a service application example for a German to French 424 translation service: 426 Http := import("Http"); 427 if (Http.response.language_is("german")) { 428 service := Services.find("opes://services/tran/german/french"); 429 service.toDialect("southern"); 430 Services.applyOne(service, Http.request.headers); 431 } 433 Figure 13 435 XXX: explain how failures are propagated and can be handled 437 XXX: add Core.interpreter.stop and Core.interpreter.restart methods. 439 6. Failures 441 Virtually any P statement may fail: expression denominator may be 442 zero, named members may not exist, objects may not support applied 443 operators, service execution may fail, interpreter may ran out of 444 resources during an assignment, etc. A failure immediately stops 445 interpretation of the first surrounding code block and assigns that 446 block a boolean value of false. 448 If the failed block is a part of a larger expression, the interpreter 449 MUST continue evaluating the expression containing the failed block 450 using usual expression evaluating rules, including short-circuiting 451 boolean expressions. If the failed block is a stand-alone statement, 452 that statement fails and the failure is propagated using the above 453 rules. If the implicit code block surrounding the program fails 454 (XXX: document or require an implicit surrounding block like XML 455 does), the entire P program interpretation terminates with a failure. 457 Failure propagation rules allow to catch failures, similar to an 458 exception mechanisms in languages like C++ or Java, except that P 459 exceptions are not objects (they carry no information). For example, 460 here is a simple way to introduce a backup/failover service: 462 { 463 ... 464 Services.applyOne(unsafeService); 465 } or { 466 ... 467 Services.applyOne(failoverService); 468 }; 470 Figure 14 472 The following example illustrates how a failure-prone service can be 473 retried twice if needed: 475 code := { 476 /* code executing the service */ 477 }; 478 code or code or code; 480 Figure 15 482 It is possible to force the interpreter to fail using the 483 "Core.interpreter.fail(reason)" call. This is handy when there is a 484 logical failure that the interpreter cannot detect on its own: 486 { 487 /* large piece of code executing several services, 488 each manipulating the current HTTP message ... */ 490 /* checkpoint */ 491 if (!Http.message.headers.have("Content-Length")) { 492 Core.interpreter.fail("services did not set CL"); 493 } 495 /* OK, continue message manipulation ... */ 496 } or { 497 /* recover from failure ... */ 498 } 500 Figure 16 502 7. Security Considerations 504 XXX: document non-obvious vulnerabilities: too many names, too deep 505 nesting, invalid math, too much error logging; execution of 506 unauthorized services, unauthorized exposure of sensitive information 507 to authorized services. 509 8. Compliance 511 XXX: define what a compliant interpreter is. 513 Appendix A. Examples 515 This appendix contains half-baked examples to illustrate P usage in 516 common OPES environments. Example themes are taken from 517 [I-D.beck-opes-irml] to ease the comparison with IRML. 519 Here is a data provider example: 521 interpreter.languageVersion("1.0"); // fails if incompatible 523 Http := import("Http"); 524 lookup(Http); 526 // Is the requested web document our home page? 527 isHome := request.uri.looksLikeHome(); 529 // Does the user send us a specific cookie? 530 cookie := makeHeader("Cookie", "sew=23"); 531 haveCookie := request.headers.have(cookie); 533 if (isHome and haveCookie) { 534 Services := import("Services"); 535 service := Services.findOne("opes://local.net/add-lcl-content"); 536 service.clientIp(request.clientIp); 537 Services.applyOne(service); 538 } 540 Figure 17 542 Here is a data consumer example: 544 Services := import("Services"); 545 service := Services.findOne("opes://privacy.net/priv-serv"); 546 service.action("remove-referer"); 547 Services.applyOne(service); 549 Figure 18 551 Appendix B. Change Log 553 Internal WG revision control IDs: $RCSfile: rules-lang.xml,v $ 554 $Revision: 1.5 $. 556 Normative References 558 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 559 Specifications: ABNF", RFC 2234, November 1997. 561 [I-D.ietf-opes-architecture] 562 Barbir, A., "An Architecture for Open Pluggable Edge 563 Services (OPES)", draft-ietf-opes-architecture-04 (work in 564 progress), December 2002. 566 Informative References 568 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 569 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 570 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 572 [I-D.beck-opes-irml] 573 Beck, A. and M. Hofmann, "IRML: A Rule Specification 574 Language for Intermediary Services", 575 draft-beck-opes-irml-03 (work in progress), June 2003. 577 Authors' Addresses 579 Andre Beck 580 Lucent Technologies 581 101 Crawfords Corner Rd. 582 Holmdel, NJ 583 US 585 Phone: +1 732 332-5983 586 EMail: abeck@bell-labs.com 588 Alex Rousskov 589 The Measurement Factory 591 EMail: rousskov@measurement-factory.com 592 URI: http://www.measurement-factory.com/ 594 Intellectual Property Statement 596 The IETF takes no position regarding the validity or scope of any 597 intellectual property or other rights that might be claimed to 598 pertain to the implementation or use of the technology described in 599 this document or the extent to which any license under such rights 600 might or might not be available; neither does it represent that it 601 has made any effort to identify any such rights. Information on the 602 IETF's procedures with respect to rights in standards-track and 603 standards-related documentation can be found in BCP-11. Copies of 604 claims of rights made available for publication and any assurances of 605 licenses to be made available, or the result of an attempt made to 606 obtain a general license or permission for the use of such 607 proprietary rights by implementors or users of this specification can 608 be obtained from the IETF Secretariat. 610 The IETF invites any interested party to bring to its attention any 611 copyrights, patents or patent applications, or other proprietary 612 rights which may cover technology that may be required to practice 613 this standard. Please address the information to the IETF Executive 614 Director. 616 Full Copyright Statement 618 Copyright (C) The Internet Society (2003). All Rights Reserved. 620 This document and translations of it may be copied and furnished to 621 others, and derivative works that comment on or otherwise explain it 622 or assist in its implementation may be prepared, copied, published 623 and distributed, in whole or in part, without restriction of any 624 kind, provided that the above copyright notice and this paragraph are 625 included on all such copies and derivative works. However, this 626 document itself may not be modified in any way, such as by removing 627 the copyright notice or references to the Internet Society or other 628 Internet organizations, except as needed for the purpose of 629 developing Internet standards in which case the procedures for 630 copyrights defined in the Internet Standards process must be 631 followed, or as required to translate it into languages other than 632 English. 634 The limited permissions granted above are perpetual and will not be 635 revoked by the Internet Society or its successors or assignees. 637 This document and the information contained herein is provided on an 638 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 639 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 640 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 641 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 642 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 644 Acknowledgement 646 Funding for the RFC Editor function is currently provided by the 647 Internet Society.