C. W. Ng Document: Panasonic Singapore Labs Expires: Delivery Context Sub-System for IRML Status of this Memo Yet to be published. Abstract TBD Ng [Page 1] Delivery Context Sub-System for IRML Table of Contents 1 Motivations....................................................3 2 OPES Framework.................................................3 3 Delivery Context Sub-system....................................4 3.1 Properties..................................................5 3.2 The "matches" and "non-matches" Attributes..................5 3.3 The "case-insensitive" Attribute............................6 3.4 The "context" Attribute.....................................6 4 IAB Consideration..............................................6 5 Security Considerations........................................6 6 References.....................................................6 7 Author's Addresses.............................................7 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Ng [Page 2] Delivery Context Sub-System for IRML 1 Motivations As the Internet grows, so does the range of devices that are used to access contents from the Web. This diversification of browser types has been accelerated with recent advancements in wireless Internet technology, whereby tiny handheld devices such as digital personal assistants (PDA) and mobile phones have micro-browsers built in that browse the web, or playback audio/visual streams. No longer can content authors develop contents with the assumption that the created content will only be viewed by users using traditional desktop computers. Device independence is now a critical consideration [2]. A viable approach to achieving device independence is through the framework defined by the Open Pluggable Edge Service (OPES) Working Group of the Internet Engineering Task Force (IETF) [3]. In essence, the OPES framework depicts a rule engine sitting on top of a traditional Hypertext Transfer Protocol (HTTP) proxy. This rule engine interprets the rules written in a highly abstract form known as the Intermediary Rule Markup Language (IRML) [4], and triggers adaptations services based on conditions specified by the rules to dynamically adapts the HTTP contents. Such a framework allows authors to write rules and adaptation services to achieve device independence. In fact, there are various current work in progress targeted on these issues, most notably Personalization Callout Server by A. Babir et. al. [5]. However, the current focus on the OPES rule engine are on HTTP, and consequently, the rules can only be constructed based on parameters that are carried within a HTTP header. This greatly limits the usefulness of an OPES rule engine as the amount of personalization and device context information contained in a HTTP header is minimal. In this document, we will propose an approach to achieving device independence with the OPES rule engine based on the sub-systems extension to the IRML [6]. We will describe the OPES framework, and seek for open discussion on the proposed approach. 2 OPES Framework The OPES framework was first proposed by the IETF with the idea to extend the functionality of traditional HTTP proxy beyond simple caching and relaying requests. Examples of additional services that can be provided by the intermediary are presented in [7], including advertisement insertion, HTML content adaptation, and limited bandwidth adaptation. A complete OPES infrastructure is currently being developed. In essence, the OPES infrastructure consists of a rule engine, an adaptation server, and a HTTP proxy. The rule engine intercepts the HTTP requests and responses flowing through the proxy and trigger Ng [Page 3] Delivery Context Sub-System for IRML services provided by the adaptation server to act on the HTTP contents. Conditions are specified using IRML, a rule specification language that is an application of the eXtensible Markup Language (XML). Ordinarily, these conditions are based on parameters contained in the HTTP headers. As the amount of delivery context that can be transferred within the HTTP headers are very limited, the application of OPES framework for device independence does not look attractive. However, recent efforts from the Ng et. al. have resulted in the OPES rule engine having the capability of sub-systems extension [6]. This allows the rule specification to extend beyond the limitations of HTTP headers, since sub-system can be defined to interpret parameters that are out of the scope of HTTP. For instance, a QoS sub-system is defined in [8] to interpret a set of Quality of Service (QoS) parameters. 3 Delivery Context Sub-system For an OPES Intermediary to have better support in delivery context, we proposed to introduce a new sub-system for IRML to handle delivery context parameters, known as Delivery Context Sub-system. A viable strategy is for the sub-system to interface with a module that is external to the OPES framework. This module can be a CC/PP or UAProf agents that can retrieve context delivery parameters. This sub-system will simply acts as a middleman between the OPES rule engine and the said agents. Advantage for such an approach is that this allows OPES rule engine to extend adaptation services based on context delivery parameters such as user preferences and device capabilities. This is done without any need to change specifications of the OPES rule engine and IRML, thanks to the sub-system capabilities of IRML. In addition, current work on UAProf or CC/PP need not worry too much on the interoperability with the OPES rule engine. Any changes from either the OPES framework or the UAProf standards merely affects the delivery context sub-system. Efforts in developing the delivery context sub-system could work closely with the personalization call-out server [5]. For example, the callout server requires the OPES rule engine to identify the user. Such a requirement can be fulfilled if a sub-system can interpret user identification for the rule engine through the User Profile Information Protocol [9], or the Application Configuration Access Protocol [10]. In addition, the service personalization call-out server also entails dynamically loading a set of rules into the OPES rule engine, where in such rules are dynamically generated by the call-out server to effectively adapts the contents for personalization. A sub-system specifically design to handle delivery context parameters will greatly enhance the personalization call-out server, since the rules that are dynamically generated need no longer be constrained by the limitations of HTTP headers. Instead, the rules can refer to terms like the device capabilities Ng [Page 4] Delivery Context Sub-System for IRML and user preferences, which are absent in the HTTP headers and would be invaluable in personalized adaptations. The following sub-sections are included to encourage discussions. 3.1 Properties What kind of IRML properties is needed in the Delivery Context Sub- system? To start off discussions, the following categories of properties might be considered: a. User Preferences Category This category can include properties that describe the human user preferences, such as browsing preference, language preference, display preferences, and demographic information of the user, e.g. age, gender, job nature. b. Agent Capabilities Category This category can include properties that describe the software agent capabilities, such as the type of agent, supported formats, supported languages, and supported protocol. However, it must be noted that some of these information are carried in the "User- Agent", "Accept-Coding", and "Accept-Language" general headers. c. Device Capabilities Category This category can include properties that cover device capabilities, such as the processor speed and family, memory capacity, screen depth and resolution, and operating system. d. Natural Environment Category This category can include properties that describe the natural environment the human user is in, such as location (e.g. indoor or outdoor), mobility of the user (e.g. velocity), and illumination conditions. 3.2 The "matches" and "non-matches" Attributes Most properties pertaining to delivery context are descriptive in nature, such as browsing preferences. There are, however, useful properties such as screen sizes and mobility that may require arithmetic comparison. Should we stick to regular expression matching for the delivery context sub-system? Or should we employ an arithmetic comparison scheme such as those described in the QoS sub-system [8]? Or should we attempt a hybrid approach: allowing both regular expression and arithmetic matching? Ng [Page 5] Delivery Context Sub-System for IRML 3.3 The "case-insensitive" Attribute If we use regular expression, this attribute might be meaningful. 3.4 The "context" Attribute Is there any use of the "context" attribute? 4 IAB Consideration TBD 5 Security Considerations TBD 6 References [1] RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gimson, R., et. al., "Device Independence Principles", W3C Working Draft, http://www.w3.org/TR/di-princ/, September 2001. [3] Tommlinson, G., et. al., "A Model for Open Pluggable Edge Services", IETF Internet Draft, Work In Progress, http://www.ietf.org/internet-drafts/draft-tomlinson-opes-model- 01.txt, November 2001. [4] Beck, A. and Hofmann, M., "IRML: A Rule Specification Language for Intermediary Services", IETF Internet Draft, Work In Progress, http://www.ietf.org/internet-drafts/draft-beck-opes- irml-02.txt, November 2001. [5] Barbir, A., Bennett, N., Penno, R., Menon, R., and Sengodan, S., "Requirements for an OPES Service Personalization Callout Server", IETF Internet Draft, Work In Progress, http://www.ietf.org/internet-drafts/draft-barbir-opes-spcs- 01.txt, March 2002. [6] Ng, C.W., Tan, P.Y., and Cheng, H., "Sub-System Extension to IRML", IETF Internet Draft, Work In Progress, http://www.ietf.org/internet-drafts/draft-ng-opes-irmlsubsys- 00.txt, July 2001. [7] McHenry, S., Condry, M. and G. Tomlinson, "Open Pluggable Edge Services Use Cases and Deployment Scenarios", IETF, Work In Ng [Page 6] Delivery Context Sub-System for IRML Progress, http://www.ietf.org/internet-drafts/draft-mchenry- opes-deployment-scenarios.txt, November 2001. [8] Ng, C.W., Tan, P.Y., and Cheng, H., "QoS Extension to IRML", IETF Internet Draft, Work In Progress, http://www.ietf.org/internet-drafts/draft-ng-opes-irmlqos- 01.txt, February 2002. [9] Penno, R., and Pham, H. T., "User Profile Information Protocol", IETF Internet Draft, Wok In Progress, http://www.ietf.org/internet-drafts/draft-penno-cdnp-nacct- userid-05.txt, July 2001. [10] Newman, C., and Myers, J. G., "ACAP – Application Configuration Access Protocol", IETF RFC 2244, http://www.ietf.org/rfc/rfc2244.txt, November 1997. 7 Author's Addresses Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #04-3530 Tai Seng Industrial Estate Singapore 534415 Phone: (+65) 6550 5420 Email: cwng(_at_)psl(_dot_)com(_dot_)sg Ng [Page 7]