idnits 2.17.1
draft-beck-opes-psrl-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:
----------------------------------------------------------------------------
== The page length should not exceed 58 lines per page, but there was 10
longer pages, the longest (page 4) being 66 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Introduction section.
** 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.)
** 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 ([2], [3]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
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 (November 17, 2000) is 8553 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Missing reference section? '1' on line 14 looks like a reference
-- Missing reference section? '2' on line 255 looks like a reference
-- Missing reference section? '3' on line 102 looks like a reference
-- Missing reference section? '4' on line 74 looks like a reference
-- Missing reference section? '5' on line 350 looks like a reference
-- Missing reference section? '6' on line 361 looks like a reference
-- Missing reference section? '7' on line 347 looks like a reference
-- Missing reference section? '8' on line 364 looks like a reference
Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Draft A. Beck
3 M. Hofmann
4 Expires: May 2001 Lucent Technologies
5 Document: draft-beck-opes-psrl-00.txt November 17, 2000
6 Category: Informational
8 PSRL: A Rule Specification Language for Proxy Services
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026 [1].
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six
21 months and may be updated, replaced, or obsoleted by other documents
22 at any 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
26 http://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 Abstract
33 Proxy services are a new class of applications running on caching
34 proxies or dedicated application servers, preferably at the network
35 edge. They are described in [2] and [3]. Execution of proxy services
36 is triggered by certain conditions. These conditions are service
37 specific and have to be provided by the party on behalf of which the
38 affected service modules are executed.
40 The Proxy Service Rule Specification Language (PSRL) is an XML-based
41 language that can be used to describe service specific execution
42 rules. It allows a service provider to tell a proxy caching provider
43 when and how the services should be executed.
45 Table of Contents
47 1 Terminology....................................................2
48 2 Problem Description and Goals..................................3
49 3 PSRL Syntax and Grammar........................................4
50 3.1 The "rulemodule" Element.....................................4
51 3.2 The "owner" Element..........................................4
52 3.2.1 Attributes of "owner".......................................4
53 3.2.2 The "name" Element..........................................4
54 3.2.3 The "id" Element............................................5
55 3.3 The "protocol" Element.......................................5
56 3.4 Examples of the "owner", "name", "id", "protocol" Elements...5
57 3.5 The "rule" Element...........................................6
58 3.5.1 Attributes of "rule"........................................6
59 3.5.2 The "property" Element......................................7
60 3.5.3 The "action" Element........................................8
61 3.5.4 Examples of the "rule", "property" and "action" elements....8
62 4 Order of Service Execution.....................................9
63 5 Security Considerations........................................9
64 6 References....................................................10
65 7 Author's Addresses............................................10
66 A Appendix - PSRL DTD...........................................11
67 B Appendix - Rule Module Examples...............................11
69 1 Terminology
71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
73 document are to be interpreted as described in RFC 2119 [4].
75 rule module
77 A rule module contains a set of rules and information about the rule
78 module owner.
80 rule
82 Rules contain conditions and actions that are to be executed if the
83 conditions are met.
85 action
87 The execution of a local/remote service module or a proxy library
88 function. Message properties MAY be modified as the result of the
89 execution.
91 service module
93 Service modules are executable code modules that can be executed in
94 a local service execution environment on the caching proxy or a
95 remote service execution environment on a dedicated application
96 server. They may run on behalf of content providers, access
97 providers, and clients.
99 2 Problem Description and Goals
101 The three parties that may wish to run value-added proxy services
102 (as described in [2] and [3]) are the same parties that are involved
103 in a typical Web transaction:
105 1. Client
106 2. Access provider (e.g. an ISP)
107 3. Content provider
109 Each party must be able to express the conditions under which they
110 wish to run a service. A content provider, for instance, might want
111 to adapt its pages for users with small wireless devices. Providers
112 of free Internet services might want to insert advertisements into
113 all HTML pages served to their clients. Web users may wish to have
114 certain Web pages translated into a different language.
116 These examples demonstrate the need for rules that tell the caching
117 proxy when to run what service. These rules must be provided to the
118 caching proxy by the three parties on behalf of which services may
119 be executed. A rule engine on the caching proxy evaluates rules that
120 apply to incoming requests/outgoing responses in order to determine
121 what service modules need be executed when and in what order.
123 As the caching proxy processing the rules is not necessarily
124 maintained by the party that authors the rules, a standard
125 specification language is required.
127 This document defines the Proxy Services Rule Specification Language
128 (PSRL) in an attempt to create a standard rule format that will be
129 supported by vendors of service enabled caching proxies and by third
130 parties offering proxy service applications.
132 The Proxy Services Rule Specification Language defined in this
133 document also serves as a standard representation of rules for proxy
134 services. This facilitates the exchange and discussion of these kind
135 of rules between and within groups of rule authors.
137 It is beyond the scope of this document to define a secure and
138 reliable mechanism for transferring rule files to caching proxies.
139 Likewise, this document does not describe the specifics of how to
140 (efficiently) process rules on the caching proxy.
142 3 PSRL Syntax and Grammar
144 PSRL is an application of XML. Thus, its syntax is governed by the
145 rules of the XML syntax as defined in [5], and its grammar is
146 specified by a DTD, or Document Type Definition. The PSRL DTD can be
147 found in Appendix A.
149 Valid and well-formed PSRL documents consist of one or more rule
150 modules. Each rule module contains a set of rules and information
151 about the rule module provider. Rule modules are provided by a
152 content provider, an access provider, or by a client (although
153 usually indirectly through an access provider). The rules contained
154 in rule modules each consist of a number of conditions and a number
155 of consequent actions that must be executed if the conditions are
156 met. The conditions within a rule refer to message properties in the
157 request or response of a given Web transaction. They are met if the
158 property value matches the pattern specified in the condition.
160 3.1 The "rulemodule" Element
162 The "rulemodule" element is the root element for all rule modules
163 and MAY/MUST contain the following elements (see also PSRL DTD in
164 Appendix A).
166 3.2 The "owner" Element
168 The "owner" element specifies the owner of the rule module. Each
169 rule module can have exactly one owner.
171 3.2.1 Attributes of "owner"
173 Name Values
174 ----------------------------------------------------
175 class content provider|access provider|client
177 The "class" attribute assigns a rule module owner to one of the
178 three types of rule module providers: content providers, access
179 providers, and clients.
181 3.2.2 The "name" Element
183 The "name" element contains a descriptive name for the rule module
184 owner. This could be the company name for content and access
185 providers and a customer login for clients. The name does not have
186 to be unique among rule module owners.
188 3.2.3 The "id" Element
190 The "id" element contains an identifier for the rule module owner.
191 The identifier MUST be unique within a class of rule module
192 providers. The "id" element determines whether a particular Web
193 transaction is relevant to a rule module and thus, whether the
194 contained rules have to be processed for this particular Web
195 request/response. For example, a rule module provided by a content
196 provider should only be processed for Web request referring to Web
197 resources owned by the same content provider.
199 Therefore, if the rule module owner is a content provider, the "id"
200 element MUST contain the domain name(s) of the content provider. If
201 a content provider owns more than one domain and the relevant rule
202 module pertains to more than one of them, the "id" element MAY even
203 contain more than one domain name separated by the "|" character
204 (see "owner" example). The specified domain name(s) MAY also contain
205 a port number. If no port number is specified, then the default port
206 for the specified protocol is assumed, e.g. 80 for HTTP.
208 If the rule module owner is an access provider, then the "id"
209 element is of less importance, since a particular caching proxy is
210 usually associated with only one specific access provider.
212 If the rule module owner is a client, then a unique client
213 identifier, e.g. a customer id, MUST be chosen in order to associate
214 client rule modules with client requests. If the client's access
215 provider does not assign dynamic IP numbers to its customers, the
216 "id" element can also contain the IP number of the module owner.
217 Otherwise, the dynamic IP addresses of incoming client requests MUST
218 be mapped to the unique client "id" element value in order to
219 determine whether a specific rule module must be processed.
221 3.3 The "protocol" Element
223 The "protocol" element contains the name of the protocol acronym the
224 rule module pertains to. For now, only "http" is supported. In a
225 future version of this document other protocols will be supported as
226 well.
228 3.4 Examples of the "owner", "name", "id", "protocol" Elements
230
231 Yahoo Inc.
232 www.yahoo.com|dir.yahoo.com:8000
233
234 http
236
237 abeck
238 205.167.45.1
239
240 http
242 3.5 The "rule" Element
244 The "rule element" contains one or more "property" elements.
246 3.5.1 Attributes of "rule"
248 Name Values
249 ----------------------------
250 processing-point 1|2|3|4
252 The "processing-point" attribute specifies at which of the four
253 points in figure 1 a rule must be processed by the rule engine on
254 the caching proxy. The four "processing-points" are derived from the
255 Extensible Proxy Services Framework as described in [2]. Other
256 implementation architectures might define additional "processing-
257 points", which can be specified with PSRL by allowing additional
258 values for the "processing-point" attribute.
260 Figure 1 shows the typical HTTP data flow between a client, a
261 caching proxy, and an origin server. The four processing points (1-
262 4) represent locations in the round trip message flow where rules
263 can be processed and service modules can be executed. Note that the
264 message flow may skip points 3 and 4 after point 1 if the requested
265 object can be served from cache.
267 +--------+ +-----------+ +--------+
268 | |<------|4 3|<------| |
269 | Client | | Caching | | Origin |
270 | | | Proxy | | Server |
271 | |------>|1 2|------>| |
272 +--------+ +-----------+ +--------+
274 Figure 1: Rule Processing/Service Execution Points
276 Point 1: Client Request
277 A HTTP request from a client has been received. A possible
278 cache lookup has not yet occurred.
280 Point 2: Proxy Request
281 The requested Web object cannot be served from the cache and
282 the origin server is about to be contacted for the HTTP
283 resource.
285 Point 3: Origin Server Response
286 The HTTP response from the origin server has been received. It
287 has not yet been stored in the cache.
289 Point 4: Proxy Response
290 The HTTP response from the cache or the origin server is about
291 to be sent back to the client.
293 Depending on the service type, rules may be processed and services
294 may be executed at any of the four points outlined in figure 1. A
295 virus scanning service for instance should be executed at point 3 in
296 figure 1 in order to scan all Web objects for viruses before they
297 can be stored in the cache. A URL-based request filtering service on
298 the other hand should be executed at point 1 and an ad insertion
299 service will probably be executed at point 4.
301 We can imagine that in the future there will be a need to have more
302 processing points (at a finer granularity) than the ones mentioned
303 above. This will be reflected in a future version of this document.
305 3.5.2 The "property" Element
307 The "property" element contains one or more other "property"
308 elements and one or more "action" elements. "property" elements are
309 conditions, that, if met, will lead to the execution of the service
310 modules specified in the contained "action" elements. Nested
311 "property" elements represent a hierarchical "AND" relationship.
312 This means that an inner "property" condition can only be true, if
313 the outer "property" condition is true and so forth.
315 Attributes of "property"
317 Name Values
318 ----------------------------
319 name CDATA
320 matches CDATA
322 The "name" attribute specifies the name of the message property that
323 is to be matched. This can be either a request or a response message
324 property. The protocol specified in the "protocol" element
325 determines what are legal property names. If the message property is
326 an HTTP request or response header, the list of legal header names
327 can be taken from [6].
329 For HTTP messages, the following property names are defined in
330 addition to the list of legal HTTP headers in [6]:
332 Property Name Refers to
333 --------------------------------------------------------------
334 "request-line" the first line of a HTTP request
335 "response-line" the first line of a HTTP response
336 "request-path" the relative path of the request URI
337 "request-body" the body of a HTTP request (POST)
338 "response-body" the body of a HTTP response
339 "user-id" a value to identify a user, assigned by
340 the access provider and unique for all
341 customers of the same access provider
343 The matches "matches" attribute specifies the pattern against which
344 the property value MUST be compared by the rule engine on the
345 caching proxy. The "matches" pattern MUST be a regular expression
346 compliant with the basic or extended regular expression syntax as
347 defined in [7].
349 If needed, the double-quote character (") MUST be represented in any
350 attribute value as """ or (as specified in [5]).
352 3.5.3 The "action" Element
354 The "action" element contains the name of the service module that is
355 to be executed on the caching proxy or a dedicated application
356 server. Instead of a service name the "action" element MAY also
357 contain the name of a built-in proxy library function.
359 Any arguments MAY be passed as part of the service module name,
360 using the standard "?"-encoding of attribute-value pairs used in
361 HTTP [6]. If the service module resides on a dedicated application
362 server and ICAP [8] will be used as the transport protocol, the
363 "action" element MAY contain an ICAP-URI as defined in the current
364 version of the ICAP specification [8].
366 Only one service/function/ICAP-URI MAY be specified per "action"
367 element. A "property" element, however, MAY contain several "action"
368 elements.
370 3.5.4 Examples of the "rule", "property" and "action" elements
372
373
374
375
376
377
378 icap://trans.net/translate?mode=respmod
379
380
381
383
384
385
386
387 icap://mcaffee.com/viruscheck?mode=respmod
388
389
391 4 Order of Service Execution
393 The order in which service modules on the caching proxy are executed
394 may change the final result of a Web transaction. For example, an ad
395 insertion service executed against the result of a Web page
396 translation service may produce a different result than a reverse
397 execution order.
399 Up to three rule modules may have to be processed by a caching proxy
400 per Web transaction. The order in which these rule modules are
401 processed MUST reflect the order in which the message flow reaches
402 the rule module owners. This means that for incoming requests at
403 points 2 and 3 in figure 1, the order MUST be:
405 1. Client rule module
406 2. Access provider rule module
407 3. Content provider rule module
409 For outgoing responses at points 3 and 4, the order MUST be:
411 1. Content provider rule module
412 2. Access provider rule module
413 3. Client rule module
415 Within a single rule module, the caching proxy MUST process and
416 execute all rules and actions IN THE ORDER THEY ARE SPECIFIED in the
417 rule module (both within "property" and "rule" elements). If the
418 rule processor determines that an action must be executed, it MUST
419 do so BEFORE continuing the rule matching process, since service
420 modules MAY modify message property values. This may influence the
421 result of subsequent pattern matches.
423 The authors of rule modules should therefore pay special attention
424 to the order of the "action" elements in their rule modules, as this
425 may have an effect on the final result.
427 5 Security Considerations
429 Although beyond the scope of this document, it is clearly necessary
430 to define a secure mechanism for transferring rule modules to
431 caching proxies. This will include authenticating and authorizing
432 rule module owners and caching proxies. The integrity of rule
433 modules must be guaranteed through the use of strong encryption as
434 they are transferred over the Internet.
436 Also, a security context must be established on the caching proxy
437 for each rule module to ensure that rule modules may not execute
438 service modules or call proxy library functions without without
439 being authorized to do so. Service modules running on the caching
440 proxy also must be restrained from consuming too many resources on
441 the caching proxy.
443 6 References
445 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
446 9, RFC 2026, October 1996
448 2 Tomlinson, G., et al., "Extensible Proxy Services Framework",
449 http://www.ietf.org/internet-drafts/draft-tomlinson-epsfw-00.txt,
450 July 2000
452 3 Hofmann, M., Beck, A., "Example Services for Network Edge
453 Proxies", Workshop on Extensible Proxy Services Framework, San
454 Jose, CA, USA, September 13, 2000. Available at
455 http://www.cs.utah.edu/~horman/opencache/draft-hofmann-isfnep-
456 00.txt
458 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
459 Levels", Request for Comments 2119, Harvard University, March
460 1997
462 5 Bray, T., et al., Extensible Markup Language (XML) 1.0 (Second
463 Edition), http://www.w3.org/TR/2000/REC-xml-20001006,
464 October 2000
466 6 Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1",
467 Request for Comments 2616, June 1999
469 7 ISO/IEC DIS 9945-2:1992, Information technology - Portable
470 Operating System Interface (POSIX) - Part 2: Shell and Utilities
471 (IEEE Std 1003.2-1992); X/Open CAE Specification, Commands and
472 Utilities, Issue 4, 1992
474 8 Elson, J., et al., "ICAP, the Internet Content Adaptation
475 Protocol", http://www.i-cap.org/icap_v1-25.txt, January 2000
477 7 Author's Addresses
479 Andre Beck
480 Markus Hofmann
481 Bell Laboratories
482 Lucent Technologies
483 101 Crawfords Corner Rd.
484 Holmdel, New Jersey 07733
485 Phone: (732) 332-5983
486 Email: {abeck, hofmann}@bell-labs.com
488 A Appendix - PSRL DTD
490
491
492
493
494
495
496
497
498
500
501
502
504 B Appendix - Rule Module Examples
506 Content Provider Rule Module Example for Advertisement Insertion
507 Service
509
510
511
512 Lucent Technologies
513 www.lucent.com
514
515 http
516
517
518
519
520
521 icap://adserver.net/insertad?mode=respmod
522
523
524
525
527 Access Provider Rule Module Example for Advertisement Insertion
528 Service for Free Internet Service
530
531
532
533 Comcast Free Internet Service
534 comcast
535
536 http
537
538
539
542 icap://adserver.com/insert_ad?mode=respmod
543
544
545
546
548 Client Rule Module Example for Language Translation and Virus
549 Scanning Service
551
552
553
554 Markus Hofmann
555 23242
556
557 http
558
559
560
561 icap://mcaffee.com/virus_scan?mode=respmod
562
563
564
565
566
567 Document language is probably not
569 German -> Page needs to be translated -->
570
571 icap://icap.net/translate?mode=respmod
572
573
574
575
577 Content Provider Rule Module Example for Content Adaptation Service
578 for Wireless Web Access Devices
580
581
582
583 Yahoo Inc.
584 www.yahoo.com
585
586 http
587
588
589
590
591
592 icap://wapgateway.nl/transcode?mode=respmod
593
594
595
596
598 Full Copyright Statement
600 Copyright (C) The Internet Society (2000). All Rights Reserved.
602 This document and translations of it may be copied and furnished to
603 others, and derivative works that comment on or otherwise explain it
604 or assist in its implementation may be prepared, copied, published
605 and distributed, in whole or in part, without restriction of any
606 kind, provided that the above copyright notice and this paragraph
607 are included on all such copies and derivative works. However, this
608 document itself may not be modified in any way, such as by removing
609 the copyright notice or references to the Internet Society or other
610 Internet organizations, except as needed for the purpose of
611 developing Internet standards in which case the procedures for
612 copyrights defined in the Internet Standards process must be
613 followed, or as required to translate it into languages other than
614 English.
616 The limited permissions granted above are perpetual and will not be
617 revoked by the Internet Society or its successors or assigns.
619 This document and the information contained herein is provided on an
620 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
621 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
622 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
623 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
624 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
626 Acknowledgement
628 Funding for the RFC editor function is currently provided by the
629 Internet Society.