OPES workshop 6/7/2001 Intel Campus 9:10am Agenda bashing Lee Rafalow - Objection raised to vendor-specific association with Web Services. Comment made to combine Web Services bullet w/ SOAP, UDDI, WSDL, ESI. ICAP agenda item discussion Lee Rafalow Concerned about the way that agenda treats iCAP as starting point, rather than looking at requirements and structuring things to those requirements Michael Condry - disagreed with this assumption Hilarie Orman - need rationalization of the discussion Markus Hofmann - if there is something, get practical experience with it - hence the inclusion in the agenda Lee Rafalow: Discussion about whether looking at iCAP experiences is relevant. Gary Tomlinson: Hosting services at the edge is the point of OPES. iCAP is a protocol that exists. Michael Condry: There are mixed implementations on the market now. Need to understand what we're dealing with. Let's get the draft we're all willing to bless. Lee Rafalow: Our charter says to understand requirements of intermediary. A change to the agenda was made moving the other callout protocols to the first part of the meeting to be discussed along with iCAP. Michael Condry (MC) agreed to put modified agenda on the website for the record. Michael Condry: Agenda complete! Michael Condry: I'm hoping we get into publisher-side directives in much further detail in London. 9:25am OPES Deployment Scenarios - Michael Condry ==================== The document will show examples of several kinds of deployment scenarios and indicate how we will have a requirements document to follow. It will similarly indicate how we will test this environment. Possible outline of document: Briefly introduce and motivate OPES principles & key elements. Discuss several use cases. Present potential OPES configurations, which describe how various OPES entities can be combined to provide certain services. A question to the group: Should the deployment scenario document evolve out of examples? One response was received that it should be separate. The present work is on seeding the requirements document by producing a scenario document. Hilarie Orman asked what would go in scenarios and not in requirements. Markus Hofmann: How you would deploy each component? In front of servers? At hosting centers? How we could think of deploying the technology. One example: Most of the time when we talk about remote callout services, some are collocated with a cache. However there might be a reason to locate your remote callout at a totally different data center, so you'd need a remote callout protocol. Markus Hofmann suggested exploring possible deployments - e.g. callout boxes not necessarily collocated It was agreed that the deployment scenarios will be described in the same document along with the examples. Steven McHenry volunteered to be editor for this document with help from Markus Hofmann. It was also decided that a separate document will be required to describe the OPES models and architecture. Robert Chen and Gary Tomlinson volunteered to be editors for this document. Section one of the document will be the taxonomy and will be produced before any other sections. Michael Condry asked for volunteers for authorship of the two documents. Interested volunteers were asked to email him. 9:35am Callout Protocols - Hilarie Orman ======================================== Apologized for attempting to use a vendor-specific term as a generic term for an open Internet web services environment. ** Briefing slide: New directions in content-based standards Overarching concept: (some vendor specific vision) Business services: UDDI, univeral description, discovery, integration (www.uddi.org) Web services description language (xml.coverpages.org/wsdl.html) SOAP/ROPE (www.soap-wrc.com) Cacheable dynamic content, such as edge side includes (http://www.edge-delivery.org) ** Re OPES: - small key piece of technology in the content Internet space - how does OPES position itself in the space, operating as the basic enabling technology? Lee Rafalow: SOAP is framework in which something that has the semantics of icAP could be embodied. It's a principal way the industry is calling remote services. Gary Tomlinson - iCAP is a very semantically fixed protocol - iCAP designed to dovetail into standard HTTP servers / SOAP requires additional stuff Wayne Carr - XMLP/SOAP attachments (multipart/related) - raw data with the SOAP message. After boundary just put the bits into the attachment. Hilarie Orman: Issue is whether it's possible to copy the data, or whether there is a MIME re-encoding/marshalling. Does every line break need to be reencoded? Reply: No. A long discussion followed regarding protocols such as UDDI, SOAP. It was noted that selection/creation of protocols should be done with the processing requirements in mind. It was agreed that OPES protocols will be based on the fact that they will be used in wire-speed scenarios (as opposed to W3C where that may not be a hard requirement) - Hilarie Orman and Michael Condry explained the need for OPES and the justification for involving the network in doing some of the tasks that might appear to belong at end systems. - what is the processing done by the base OPES processor, and what are its requirements for operating at line rate processing? (Getting the data through the pipe - the remote processing is another issue.) Lee Rafalow - Same concern about performance - believes his company can meet requirements using SOAP This is a Web Service, so we should look at these frameworks that are being worked on in the industry. Hilarie Orman: currently looking at using existing protocol engine and just adding arguments as additional parts to the headers (e.g. iCAP). Other techniques are to keep existing protocol as a BLOB and pass it over another protocol, e.g. SOAP/BEEP. Hilarie Orman: But MIME is heavy. Here's the issue I see. ICAP is the minimum you need to do to encapsulate HTTP for a remote server. If something more generic requires rexamination of every character, that seems to me to be too much work for the task at hand. Michael Condry: Overhead of any such protocol has to be reasonable given we're working in a wirespeed type app environment. Gary Tomlinson: Two ends of the spectrum from an app standpoint. Apps that need to transfer bulk data is what icap has been intended to do. Different classes need to do asynch callbacks, finer granularity. Can one protocol do both efficiently? [Discussion of marshalling in SOAP] Wayne Carr: SOAP-based method calls, whole bunch of data types, that would require marshalling. It can point to some file with a URI, URI follows it untouched without marshalling. Hilarie Orman: There's no marshalling in iCAP. Wayne Carr: iCAP can't handle complex calls. Hilarie Orman: Turning an HTTP attachment into the format we want, it's more overhead than we'd want. Wayne Carr: WSDL and UDDI are all sitting on top of SOAP. They use SOAP to transmit their messages. Hilarie Orman: Could they use another RPC? Wayne Carr: You could. W3C is finishing up the XML infrastructure in general, they're headed to semantic Web (hype), and then Web services, will pick up WSDL by the end of the year, for B2B uses. Hilarie Orman: These aren't being designed with the notion of in-flow processing, at intermediaries. Wayne Carr: A header section mentions intermediaries. Michael Condry: Wayne is looking at it from the W3C side. Hilarie from network side (has to be fast enough). Question on the table, can they meet? We don't know but it's the question that has to be answered. Regardless of the method being used. This is an issue with complexity that needs to be resolved and identified. Lee Rafalow: We ought to satisfy ourselves that SOAP can meet performance requirements. Derek White: Are these all sort of potential options for the protocol between opes and icap? Is the challenge determining which callout service is best. Hilarie Orman gave an outline of how publisher side directives are related to OPES - where OPES would look at rules would fire to do the include operation. Does not need to be using a callout protocol. Could rules consider the includes. Lee Rafalow: What are the protocols you use between a client and an edge device. Edge services is a case of clients seeking web services. We do have a terminology problem. Web services is what I think it is. There's uddi, wsdl and soap, together I think of them as ws, to find a svc, find out how to bind to that service, and actually bind to that service. Hilarie Orman: A generic issue. You can take a protocol that has a header and body, all protocols have this, if you can extend the header, you can put in what amounts to calling arguments, have the original protocol processor take stuff coming through flow, go out to a normal protocol X processor of some kind. I think at a very high level that's what ICAP is trying to do. I've looked at trying to do it with RTSP, even with HTTP (if HTTP is protocol X). The alternative is to reencode the whole thing, encode all your arguments up here, using SOAP or something else. In contrast, the advantage of header extensions is that you don't have to introduce a new protocol which deencapsulates and passes protocol X onto the original processor. Lee Rafalow: SOAP doesn't have to be bound to HTTP as a transport. Could be bound to TCP. Could send any stream as an attachment. Could have BEEP as transport, SOAP as a callout mechanism. Michael Condry: More complicated, can have live streams. Seed conversation is on the agenda. Hilarie Orman: These are good issues. Publisher-side directives (found on Web) allow publishers to insert content meant to be inserted in the network. Got some tags. This is the OPES architecture for this. Something needs to parse those tags so there is a publisher-directed parser that notices the tags and says they're present, then you have a OPES rule, if there are publisher directives, then send the data out to an OPES callout server for further interpretation. Has anybody thought of doing an OPES architecture for publisher-side directives? Rich: Yes. But at a loss to know what this provides better than JavaScript. Maurice: ESI could be done using JavaScript. Michael Condry: Your receiving device may not have a browser. OPES helps simplify the environment of client diversity. Rich: A lot of reasons for doing publisher directives are somewhat simple. A lot of other scenarios where you can't have the true edge at browser. May need virus scanning before it reaches the client device. Michael Condry: There is a collection of activities where the edge is a more logical place for services than going back to the client. We're interested in being the well-defined, called-for middleman. The middleman services architecture. Yes today you can do some things in the browser. Maybe better to do it this way. Undetermined yet. Robert Chen explained briefly their iProxy project which adds new services without modifying end systems: Examples. IPRoxy, to create new services on the proxy for the pages to download without changing either client or server. Suppose want to dload ny times article, user can determine dyanmically services to invoke. Replace with links to dictionary terms. Or links to stock quotes. Not appropriate to use Javascript between . we have something called menuswitch, for every page, switch to a proxy page shows all the services you can apply. Michael Condry: It's not transparent. You decide. You look at other content areas like streaming, complexity of services not necessarily provided by content provider, we foresee as being a very large growth area in the content delivery area. Do things that are not very doable with the content providers. Maurice: ESI work could be done without a middleman. Ian Cooper: ESI is same as server side include, just not being done on that particular server. Hilarie Orman: The Ellis Island problem. Ellis island database was put online, scaled for a large of concurrent users and is public info. Demand for it was approximately 100 fold over what it had been provisioned for. So very few people got their requests through. In any rational world that database should have migrated out through the network and automatically scaled. It shouldn't have been a problem for database designers. It is a case where the pure client/server model does not scale. Michael Condry: and we're seeing more and more. Particularly when we look at streaming content. Rich: we need to look closely at tool used to solve the problem. Type of content and user, successive requests for same area of database are very low. Hilarie Orman: I don't think that's an obvious theorem. Rich: More obvious than all hitting the Pearl Harbor movie. Hilarie Orman: You go back, there aren't very many families. Michael Condry: Clearly we want to talk about this more in London. 10:37am iCAP implementation - Markus Hoffman (MH) ================================================= Andre Beck, Markus Hoffman, [abeck, hofmann](_at_)bell-labs(_dot_)com We see the limitations of iCAP and the good things; could it fit into our framework? We implemented one iCAP client and two different servers (Apache, Java from scratch). All implementations support both iCAP modes and message preview. Client implementation: based on simple HTTP proxy. Contains a simple rule engine that redirects incoming requests/responses to certain iCAP server depending on their URL ICAP server implementation: Alternative 1. Apache core had to be modified (Not necessary in next generation of Apache Web server where new protocol support can be added through Apache modules). Supports HTTP as well as iCAP. Alternative 2. Based in Java. Multi-threaded architecture. Support for additional protocols can easily be added. ICAP service can be implemented using an interface similar to the Java Servlet API. Detected quite some open issues in the spec. Andre sent out an email 2 days ago summarizing these open issues. Issue: the need for the browser to connect to the iCAP server. - After debate, the need was expressed as one for a mechanism to get the state/profile information into the iCAP/OPES server from the client as opposed to an explicit way for the client to identify the server. - The need for a OPES taxonomy reiterated. 10:40am Martin Stecher iCAP Implemenation Experience ============================= Experience as a user of iCAP protocols. Will look at SOAP and BEEP. We have already a lot of iCAP experience: Aug. 2000: First look at iCAP. Oct. 2000: iCAP 0.95 server implementation talking to NetCache 5.0. Dec. 2000: shipped product to customer (HypoV, 46,000 clients). Today, .095 server evaluation and and implementations by several customers. Netcache 5.0/5.1 support. >From four possible vectoring points, the implementation is using two. Advertising-filter, referer, cookie, webbugs, employee internet access, media-type, embedded objects, script (Java, Vbasic). All services are in response modification mode. Experiences with iCAP 1.0: biggest problem is encoding of encapsulated headers. [chunking discussion] [wrong samples] OPTIONs implementation left undefined. Issues with caching results only for specified through. How to manage iCAP server farms? How to deal with iCAP service updates? Browser should have a chance to address the iCAP server through the client. And what about HTTPS? FTP? Mail? Access control? Virus checking? There is a strong need for open feedback on iCAP implementations so that the specs can be improved. - AC suggested the need for a no-transform tag. HO objected that it was beyond the scope of iCAP to have such a tag. Reason being that iCAP should not have objects specific to transformation because iCAP can be used for functions other than transformation. - AC pointed out that server farm issues and the like were intentionally left out of iCAP. - HO suggested to avoid using the term "encryption" in iCAP and use "privacy" or "authentication" instead. - AC stated that if he were to receive feedback from implementers he would have another draft out in a week or two. Once reviewed he could have another version in time for the London meet. - There was a small discussion on intellectural property issues and iCAP. Hilarie Orman: Why should the browser talk to the server? Martin: We have a Web interface to control all the settings we have. So an admin can connect to the iCAP server. When we change the HTML file that is coming, we sometimes exchange image text that was an ad banner to some other image that is just a transparent GIF. Where to get it from? Can provide as an internal HTTP request. Browser needs to ask somebody for this GIF. Could be the iCAP server. Michael Condry: Seem this is about talking to the OPES server, that device says should be done via iCAP. I tend to agree with Hilarie's point. I don't think the browser wants to know a thing about the iCAP server. Markus Hofmann: This has nothing to do with iCAP. This machine needs user specific information. This is what Martin is talking about. Machine needs to know which ads the client wants stripped. Lee Rafalow: I would use this as an argument for a policy framework. Michael Condry: Callout servers vs. iCAP client and server. Markus Hofmann: We agree there has to be some state, some mechanism to get rules and parameters into a callout box. Could let user specify directly, whether a good idea or not. Michael Condry: Missing from current draft to get state info into the server. Whether to do one particular implementation strategy is not our issue. Some state info about user, user preferences. ??: Admin interface needs to be discussed. Markus Hofmann: But do you want to solve this through iCAP? ??: The ad example was more interesting. If the OPES server wants to add a URI into the response back, needs to educate EU to make request back to it to get content, or ... Alberto Cerpa: An author of iCAP document, an arbiter: The iCAP server can send back a response to the iCAP client and therefore the client on the user. Hilarie Orman: OPES says you don't bypass the proxy. ??: iCAP server can send back a modified request and also a response. Can be an http error. Markus Hofmann: This has to be fed back into the OPES architecture. Hilarie Orman: This is asking to change it. Markus Hofmann: Maybe we need to discuss this. Martin Stecher: In iCAP 0.9 we just had response mod. Now with request mod it's much simpler. It may be try to make a fake URL we fetch the request mod. Request modification solves the problem. This is my old 0.95 experience. [This talk was interrupted to accommodate the schedule of the next speaker] 11:05am Outstanding issues on iCAP - Alberto Cerpa (AC) ====================================================== - Expressed the strong need for open feedback on iCAP implementations so that the specs can be improved. - AC stated that if he were to receive feedback from implementers he would have another draft out in a week or two. Once reviewed he could have another version in time for the London meet. Alberto Cerpa: Trying to clean up ICAP and put out an RFC. Not trying to sell this as a callout protocol for OPES. Only 2 people have given feedback. Need more on OPES mailing list. Need a BNF for entire ICAP messages, maybe as an appendix. AC suggested the need for a no-transform tag. Hilarie Orman: What does it mean for content to be transformed? Alberto: Content can be redirected in the middle. Hilarie Orman: Content modification is a concept separate from iCAP. It's like saying I want privacy. iCAP can be used for things that do not transform content. Gary Tomlinson: Proxy is not the right term. It's an edge delivery node for a CDN. Whose domain are you in? I am the origin server. If it's an avatar, that's an entirely different scenario. Markus Hofmann: Even if you have arbiter at edge, it might make sense, have message pass through to count how often this page got requested. Hilarie's point is there might be services that don't have anything to do with transformation. Hilarie Orman suggested avoidance of the term "encryption" in iCAP and suggested "privacy" or "authentication" instead. Hilarie Orman: We should be talking about requirements for data integrity, then map that down onto services provided. Gary Tomlinson: This is a policy issue. Lee Rafalow: Do we want to treat policy as something that's static, or generated on the fly? If on fly, I can't see them showing up as specific commands in iCAP. Alberto: Suppose a user doesn't want to get content directly from origin server. Lee Rafalow: This is an issue of compilation of rules. Part of contract with ISP are your preferences plus preferences of advertiser. Wayne Carr: A browser shouldn't be able to send the equivalent of no-cache. But may have French-to-English implemented on a per-request basis. For other things may run all content through ICAP or OPES to have viruses checked. Hilarie Orman: Holes in authentication. Alberto: Authentication gets handled outside of the iCAP specification. Michael Condry: Let's get all these issues out to the mailing list. Alberto: Regarding [iCAP] server farms. We are leaving out all these issues. Not part of the transfer protocol. Michael Condry: There may be other ways of load balancing. Hilarie Orman: SSL does benefit from load balancing. If your encryption method is SSL, there are load balancing issues. It's not something that has to be settled right now. Martin: Would be helpful to know about the version of an iCAP service. Alberto: Hold on. ISTAG - cookie describing state of iCAP server. Michael Condry: Need to get comments for final IETF submission. Deadline, mid-July. The document is following the IETF rules. If progress is being inhibited by any individual or group, the team has the right to get new editors as opposed to waiting for someone to make their political decision. [There was a small discussion on intellectual property rights issues and iCAP.] Lee Rafalow: 3 issues are getting munged together. IP associated with copyright of document. Patents that might exist in presence of that document. Third issue, whether or not this goes forward as standard or informational. Or at all. Markus Hofmann: Look for a modified draft to the list. Goal to have a stable doc for the London IETF before the cutoff date for the London IETF. Quite a few requirements came up. And maybe it's a goal to have a different goal. Ron Hegley: I envision some sort of admin interface to administer policy. Who's "Bob"? How do I know if this request is coming from "Bob"? The more info we can provide about who the requester is, at any of the 4 execution points, the better. Hilarie Orman: The draft doesn't say what you get to know. It says if you do get info, this is what it is. If it's policy the user gets informed and has the ability to opt out. [Discuss of performance issues introduced by dynamic rules] Martin continues: I'm unsure whether to rely on encapsulated header byte counts or better trust empty lines only ICAP is very powerful and works. We want it. There is high customer interest but it's important it gets standardized very soon. Markus Hofmann: Stable. Martin Stecher: Defined Transfer Protocol is too complicated. See lots of good ideas under NDA. Need ideas to go to mailing list. Martin(_at_)webwasher(_dot_)com Discussion of alternate transfer protocol and also of using chunked encoding. Alberto Cerpa: Plan is to get feedback (particularly implementation) and then become stable. - Next week - get the draft - Feedback on that draft to the mailing list - comments to that draft (must be in time for July 20 [rev additions]) 11:42am Back to Martin Stecher's presentation ============================================= Discussed potential for a testbed, tool development etc. Requested feedback for interop test options. Ron Hegli pointed out: - there's no way to tell cache that it should cache things only for a group. - end user client authentication is an issue - dynamic insertion of rules to prohibit access so that callout is not used every time. Martin was asked to send his slides out to the mailing list for feedback The need for a OPES taxonomy was reiterated. 11:55am Interoperability - Markus Hoffman ========================================= Markus Hofmann: (iCAP) Interoperability tests. An OPES testbed? The sooner we start verifying interoperability the better. Can feed this back into the protocol specification. IETF standards require different implementations of standards to interoperate. Multiple non-exclusive options for interop testing. Looking for feedback on what approach to do. Independent third-party organization like The Measurement Factory. We started with WebWasher and 8e6 to do iCAP interop tests. Other parties expressed interest and are likely to join the trials in the near future. This is nothing that happens behind closed doors. This is not product testing. These are research prototypes. Current focus is on basic message exchange in both operation modes ("just get it running"). Can be used not just for iCAP but for other protocols. Action items: get implementations done, let others know. Let us know about your interest in joining an external testbed. Getting involved in third-party evaluation. As the number of participants increases, we need to imporve and automate management of the external testbed. 1:05pm OPES Policy Requirements, Lee Rafalow ============================================ No dynamic policies? - Lee Rafalow would like policy based on human configuration Discussed ambiguity between static and dynamic policies. In the event of dynamic rules (e.g. stop sending me stuff) - how to get system to start sending requests back to the callout. Behavior could be modified without changing rules - e.g. adding users to groups rather than saying that individuals are blocked. Performance aspects of procedural and declarative specification of rules. Declarative vs. procedural rule execution model? Markus Hofmann needs procedural (example is inclusion of locality based material, and weather forecast is then included on the basis of the info that has just been included). Procedural has high processing requirements. Possibly use stubs - state information held between invocation of services - stub identifies whether rule needs to be called. Hilarie Orman: use meta-data? Possibility of 'n' processing points in a declarative specification to provide multiple passes. Discussed the model for Policy Framework (PMP, PDP, PEP) (Policy decisions, enforcement, etc.) [Static vs. dynamic policy discussion.] Policy WG never got a good handle around the distinction between policy and state. Hilarie Orman: There need to be roles in rule management. E.g. rule providers must not be able to specify rules that are not within their scope of authority (from Lee's notes). Resolution of conflicts using priority, Rule evaluation, Order Priority plus legal contracts will resolve all policy conflicts. Does order determine what happens in the end, or does priority? Ought to be done declaritively, optimizing your evaluation engine. Hilarie Orman: IPSec chose first-matching. Lee Rafalow: It is a declarative model. Says when you get to the end of an evaluation tree the highest-priority rule will apply. Hilarie Orman: Policy framework has to specify the evaluation strategy. Lee Rafalow: That's what first matching and all matching are trying to do. Hilarie Orman: Those are two of a whole spectrum. Lee Rafalow: I think all matching is problematic. Some of this is debates between Cisco and others. Hilarie Orman: So OPES wants all matching and actions in order. Due to the complex issues involved Michael Condry suggested that Gary Tomlinson (GT), Andre Beck (AB), Lily Yang (LY) and Lee Rafalow (LR) get together and evaluate OPES requirements for policies. 3:00pm Miscellaneous discussion, Michael Condry =============================================== Michael Condry: IESG Working Group Formation Report Lee Rafalow: ECMA has a nice fast path into ISO Michael Condry: If something's being submitted to ECMA, you have a dual specification draft. Ian Cooper: I heard they (ECMA) were looking at it. Lee Rafalow: Agenda in Vienna is 2-1/2 day workshop, why are we here, let's work out the details. Markus Hofmann: There were emails on the ECMA list that say iCAP is going forward as an ECMA standard. Michael Condry: I'm not pleased that we're not on the actual WG list like WEBI, but I'm pleased we're on the formation report page. We will keep working with the IETF. 3:05pm Streaming in OPES - Christian Maccioco, R. Menon, M. Condry ================================================================== -motivation -review of static (http) content arch -what is streaming architecture? Motivation Does the current arch work for streaming content & services What are the requirements for a streaming arch? Review of static arch Intermediary device controls sequencing of services What happens for streaming: OPES device in the data path, a request is modified or not modified, content flows back to the device, rules are used to set up esrvices, data goes out of device to the services (callout services), being served to the end user device Pros: one coordinated pt of data delivery to the client; similar arch to static one; acess to data stream allows intermed dev ctrls and sequnces services Cons: lack of scalability and throughput issues; can an OPES device be a streaming proxy for real, windows media, etc. Scenario 2, OPES in the control path Based on request, device sets up services, with metadata info, modified request sent to server, stream the data to the services, which is what happened with windows media and real, potentially back to OPES device to decide a control structure, then sent back to client bypassing OPES device At&t, the other one won't scale Markus Hofmann: this is how streaming works most of the time. Gary Tomlinson: In our case we are the video server as well. But still we may have callouts going. Ian Cooper: I see some midcom pinholes. Robin Chen: We have an HTTP client and a video client. Hilarie Orman: You may be making a request via a Web page, but the video stream returned may not be HTTP Michael Condry: This area is going to be more than just the Web technology requirement. The edge service of the future is going to be more than just the Web. Gary Tomlinson: Many people believe Web streaming is part of the Web. Ian: Essentially it's a pure redirect. Michael Condry: It's a little more complicated. OPES represents itself as a control box. For example, stop, make it black and white. That request goes back into the OPES box and then back into the callout service. Ian: Hilarie and I agree it's drawn as a network engineering nightmare. Gary Tomlinson: In OPES and HTTP, we've said we can modify control and data things. In streaming we're real asymetric, we say we don't deal with the data. FTP too? ??: Think of MPEG4. Callout protocols: -iCAP? Inadequate for non-sequential content like MPEG-4 Inadequate for wall clock content delivery Fixed semantics vs BEEP or SOAP] Asynchronous callback -BEEP? -SOAP? -ESI? Is a rule based system adequate? Timing relationship between services at the edge? Control/feedback path between services and OPES Hilarie's list of things you want to do on the data stream: · Ad insertion · Expletive deletion, very important in some regions, you can do it real time · Indexing · Compression · Watermarking 3:40pm Open issues in IRML and rule processing, Lily Wang ========================================================= Pointed out that she and Lee Rafalow were differing in rule evalution methods They and Markus Hofmann agreed that the service and service provider can be specified for binding but not the exact location of the server. 3:50pm iMobile Technology - Robert Chen ============================== Goals are very similar to OPES. People are starting to access info from all sorts of devices With respect to the four processing point in the OPES document: First point, think about a URL. In this case, a service request. Mobile users don't want to think about URLs, they want to think about what they want to do. Translate into a URL. Infolet is an information access method for an info space. Processing point #3, can be stored in a proxy cache. We create an XML file that stores info about an info structure. Proc pt #4, right templates. IM, less than 8KB, full Web browser, complete Web page. Need to authenticate the user, transcode content using device profiles. Rules, policies. Trying to implement security policy manager separate from this. i.e. AT&T security office determines if employee info can be sent via IM. Hilarie Orman: Why do we still have phone numbers? You don't have to. Can say "Try to reach Robin Chen" owns cell phone #, IM ID, telnet terminal ID, all recorded in this proxy. I used to do a demo, your boss wants to see you now. And they all arrive at different times. You can have all kinds of policies. Deliver this to the last channel robin chen used. Could use location services. Now policies: who can determine where you are? Arch is rich enough to support apps like this. Also did integration with our video server. You can request a video from a cell phone or IM, but delivery is only to a video client. End of Minutes