idnits 2.17.00 (12 Aug 2021) /tmp/idnits41200/draft-ng-opes-irmlsubsys-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: ---------------------------------------------------------------------------- == There are 47 instances of lines with non-ascii characters in the document. == 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 a Security Considerations 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], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 162 has weird spacing: '...roperty name...' == Line 163 has weird spacing: '...roperty matc...' == Line 164 has weird spacing: '...roperty case...' == Line 165 has weird spacing: '...roperty sub-...' == Line 166 has weird spacing: '...roperty no-s...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2001) is 7615 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) == Outdated reference: A later version (-03) exists of draft-beck-opes-irml-00 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT C. W. Ng 3 Document: draft-ng-opes-irmlsubsys-00.txt P. Y. Tan 4 Expires: January 2002 H. Cheng 5 Panasonic Singapore Labs 6 July 2001 8 Sub-System Extension to IRML 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 23 reference 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 The Intermediary Rule Markup Language (IRML) [2] is an XML-based 34 language that can be used to describe service-specific execution 35 rules for network edge intermediaries under the Open Pluggable Edge 36 Services (OPES) framework, as described in [3] and [4]. This memo 37 discusses the need for OPES framework to have different sub-systems 38 in different deployment scenario, and proposes additions to IRML for 39 a more flexible approach to supporting different sub-systems. 41 Table of Contents 43 1. Introduction....................................................2 44 2. Motivation for Different Sub-Systems............................2 45 3. Proposal to IRML Sub-Systems....................................3 46 3.1. The ôsub-systemö Attribute....................................3 47 3.2. The ôno-sub-systemö Attribute.................................3 48 3.3. Proposed IRML DTD.............................................4 49 3.4. Proposed Architecture.........................................4 50 4. Example.........................................................5 51 4.1. Scenario Overview.............................................5 52 4.2. IRML Examples.................................................6 53 5. References......................................................7 54 6. Author's Address................................................8 56 1. Introduction 58 The Intermediary Rule Markup Language (IRML) [2] is an XML-based 59 language that can be used to describe service-specific execution 60 rules for network edge intermediaries under the Open Pluggable Edge 61 Services (OPES) framework, as described in [3] and [4]. This memo 62 discusses the need for OPES framework to have different sub-systems 63 in different deployment scenario, and proposes additions to IRML for 64 a more flexible approach to supporting different sub-systems. 66 This memo begins in Section 2 by presenting the motivation behind 67 having sub-systems support in IRML. Section 3 proposed a set of QoS 68 extension to the "property" element defined in the IRML, and Section 69 4 presents some examples illustrating possible use of these 70 extensions. 72 2. Motivation for Different Sub-Systems 74 In [4], various different examples services that the OPES 75 intermediary can provide are presented. These services cover a wide 76 application range, including data insertion into HTML pages, web or 77 AV content adaptation, and user profiles creation. These different 78 services would have different set of requirements. The current set 79 of IRML properties, in its initial drafting, has been focused to the 80 Hyper Text Transfer Protocol (HTTP). These lead to difficulty in 81 constructing rules for other applications. For instance, limited 82 client bandwidth adaptation and streaming media adaptation requires 83 a whole set of quality of services properties, such as bandwidth 84 allocated and the packet lost rate, which is absent from the IRML 85 framework. Creation of user profiles needs user specific 86 parameters, such as the user identification, current IP address of 87 the user, etc. 89 Since the required set of property parameters is different for 90 different services, it would be much more manageable to classify 91 these parameters into different sub-systems. Furthermore, this 92 allows a specific implementation of the OPES intermediary to 93 incorporate only the parameters in the sub-systems that it needs for 94 the services it provides, and not the entire range of properties 95 that is defined. 97 In addition, since the development of the OPES framework is still in 98 its infancy stage, the sub-systems concept in IRML allows 99 researchers to create new sub-systems to experiment with new 100 properties, and still maintain conformance to the standard OPES 101 framework. For example, some implementations may desire the 102 ômatchesö attributes of the ôpropertyö element to have arithmetic 103 support, instead of restricting to regular expression. They can 104 implement such support using new sub-systems. 106 3. Proposal to IRML Sub-Systems 108 This memo proposed two new attributes to the ôpropertyö element of 109 the current IRML specifications: ôsub-systemö and ôno-sub-systemö. 111 3.1. The ôsub-systemö Attribute 113 The ôsub-systemö attribute is used to specify the sub-system where 114 the value of the property specified by the ônameö attribute can be 115 derived. 117 In order to maintain compatibility with the current IRML 118 specification, the ôsub-systemö attribute is optional. When it is 119 omitted, the default value of ôStandardö is assumed, which implies 120 that the property belongs to the set of parameters currently defined 121 in [2]. 123 3.2. The ôno-sub-systemö Attribute 125 The ôno-sub-systemö attribute complements the ôsub-systemö 126 attribute, and is used to specify the default matching result when 127 the sub-system required (as specified by the ôsub-systemö attribute) 128 is not supported by the IRML engine. It can have a value of ômatchö 129 or ôno-matchö. 131 A value of ômatchö implies that if the required sub-system is not 132 supported, the IRML engine should treat it as if the ôpropertyö 133 condition is met. Conversely, a value of ôno-matchö implies that if 134 the requires sub-system is not supported, the rule engine should 135 treat it as if the ôpropertyö condition is not met. 137 In order to maintain compatibility with the current IRML 138 specification, the ôno-sub-systemö attribute is optional. When it 139 is omitted, the default value of ôno-matchö is assumed. 141 3.3. Proposed IRML DTD 143 The proposed IRML DTD (Document Type Definition) with the two 144 proposed attributes for the ôpropertyö element is shown below. 146 148 149 152 154 156 158 159 161 162 163 164 165 166 168 170 3.4. Proposed Architecture 172 The proposed architecture with sub-systems is shown in Figure 1 173 below. Here the entire IRML rule engine consists of three parts: the 174 rule parser, the ôStandardö sub-system, and any other additional 175 sub-systems. 177 The rule parser and the ôStandardö sub-system are mandatory. 178 Together, they implements all the standard IRML rule engine 179 functionality specified in [2]. Any other additional sub-systems 180 are optional. These additional sub-systems either provide enhance 181 functionality, or is for experimental purposes. 183 +---------------+ +---------------+ 184 | | | | 185 Mandatory | Rule |<---->| Standard | 186 | Parser | | Sub-System | 187 | | | | 188 +---------------+ +---------------+ 189 ^ 190 | 191 | 192 v 193 +---------------+ 194 | | 195 Optional | Additional | 196 | Sub-system(s) | 197 | | 198 +---------------+ 200 Figure 1 Architecture of Rule Engine 202 With such an implementation, the rule parser will parse each 203 property and see what kind of sub-system the property uses. If the 204 required sub-system is supported, the property is then passed to the 205 corresponding sub-system for evaluation (i.e. check if the condition 206 specified is met). In the event that the required sub-system is 207 absent, the rule parser will then assume the condition to be met or 208 not according to the ôno-sub-systemö attribute of the property. 210 In this modular approach, implementation becomes easier. In 211 addition, because conditions are evaluated by the sub-systems, each 212 sub-system can choose to support arithmetic comparison, bolean 213 expressions, etc, instead of being limited to regex, which may be 214 sufficient for matching HTTP headers, but are at best awkward for 215 evaluating conditions which involve QoS or System parameters. 217 4. Example 219 4.1. Scenario Overview 221 Figure 2 below depicts a scenario, which illustrates the concept of 222 sub-system. In this figure, three sub-systems are shown interfacing 223 with the OPES rule engine. These are: ôStandardö sub-system, ôQoSö 224 sub-system, and the ôSystemö sub-system. The ôStandardö sub-system 225 uses the standard HTTP properties as defined by [2]. The ôQoSö sub- 226 system provides the rule engine an interface with the QoS control 227 and monitoring modules, such as Traffic Engineering Module. This 228 enables rules to construct condition involving QoS parameters. The 229 ôSystemö sub-system provides the rule engine an interface to the 230 operating system. This enables rules to be constructed using 231 conditions involving system parameters, such as the system load, the 232 number of TCP/UDP connections the system is currently handling, etc. 234 +---------------+ +---------------+ 235 | | | | 236 | Rule |<---->| Standard | 237 | Parser | | Sub-System | 238 | | | | 239 +---------------+ +---------------+ 240 ^ ^ 241 | | 242 | | 243 v v 244 +---------------+ +---------------+ 245 | | | | 246 | System | | QoS | 247 | Sub-System | | Sub-System | 248 | | | | 249 +---------------+ +---------------+ 251 Figure 2 Sub-Systems interfaces with rule engine. 253 4.2. IRML Examples 255 The first example below illustrates the case where a HTML page is 256 adapted to suit the allocated bandwidth of the client. Here we 257 assume that there is a ôQoSö sub-system which defined the property 258 name of ôallocated-bandwidthö to give the value of bandwidth 259 allocated to the client in bits per second. In addition, the ôQoSö 260 sub-system also overloads the ômatchesö attributes to support 261 arithmetic comparison (i.e. greater than, smaller than). 263 In this example, the bandwidth of client is used to determine how 264 the HTML page is translated to WML page. If the bandwidth allocated 265 is large than 9.6 kbps, the translated WML page will contain some 266 bitmaps. If it is smaller, bitmaps are replaced by alternate text. 268 When the ôQoSö sub-system is not supported, the rule-engine should 269 assume that the client has a tight bandwidth. 271 272 273 275 276 proxylet://localhost/html2wml?image=no 277 278 280 281 proxylet://localhost/html2wml?image=yes 282 283 285 The second example illustrates the scenario where the access 286 provider wishes to re-direct the client request periodically to a 287 remote proxy for logging purposes. Here, we assume that there is a 288 ôSystemö sub-system that provides support for the property name 289 ôrequest-countö. This gives the accumulated number of requests the 290 proxy has serviced. In addition, the ôSystemö sub-system also 291 overloads the ômatchesö attribute to support arithmetic expressions. 292 In this example, the ômatchesö attribute is ô($%400)==0ö. The ô$ö 293 is a token to be replaced by the value of the parameter specified by 294 the ônameö attribute. 296 297 298 300 301 icap://log.server/log 302 303 305 5. References 307 [1] Bradner, S., "The Internet Standard Process û Revision 3", BCP 9, 308 RFC 2026, October 1996. 310 [2] Beck, A., Hoffman, M., "IRML: A Rule Specification Language for 311 Intermediary Services", Work In Progress, draft-beck-opes-irml- 312 00.txt, February 2001. 314 [3] Tomlinson, G., Orman, H., Condry, M., Kempf, J., "Extensible Proxy 315 Services Framework", Work In Progress, draft-tomlinson-epsfw- 316 00.txt, 2000. 318 [4] Beck, A., Hoffman, M., Condry, M., "Example Services for Network 319 Edge Proxies", Work In Progress, draft-beck-opes-esfnep-01.txt, 320 November 2000. 322 6. Author's Address 324 Chan-Wah Ng 325 Panasonic Singapore Laboratories Pte Ltd 326 Blk 1022 Tai Send Ave #04-3530 327 Tai Seng Industrial Estate 328 Singapore 534415 329 Phone: (+65) 381 5420 330 Email: cwng@psl.com.sg 332 Pek-Yew Tan 333 Panasonic Singapore Laboratories Pte Ltd 334 Blk 1022 Tai Send Ave #04-3530 335 Tai Seng Industrial Estate 336 Singapore 534415 337 Phone: (+65) 381 5470 338 Email: pytan@psl.com.sg 340 Cheng Hong 341 Panasonic Singapore Laboratories Pte Ltd 342 Blk 1022 Tai Send Ave #04-3530 343 Tai Seng Industrial Estate 344 Singapore 534415 345 Phone: (+65) 381 5477 346 Email: hcheng@psl.com.sg