A New HTTP Request Header for Specifying Task Contexts

[AdamSobieski]

Introduction

URL-addressable Task Contexts

What tasks are a user performing? Where are they in those tasks?

With such data, developers could create next-generation context-aware technologies. Such data could, for instance, enable or enhance search engines, Q&A systems, recommender systems, and AI assistants.

Let us consider users’ task contexts to be components of business process model diagrams. Interestingly, this means that users’ task contexts can be URL-addressable. URLs could refer to business process model diagrams and their fragment identifiers could refer to components inside of these diagrams.

https://en.wikiprocess.org/wiki/process12345678.bpmn#component

Client-side Context-aware Computing

Let us consider a thought experiment where users have "task management" or "context management" applications which can load and display diagrams for tasks (e.g., BPMN diagrams). These task diagrams might each have starting nodes and users would be able to click upon, or otherwise select, components of these diagrams as they progressed through the visually depicted tasks.

Further, these applications might have multiple tabs, each tab displaying its own task diagram, to support multitasking scenarios.

Next, let us consider that users would soon want their AI assistants to be able to handle interacting with these "task management" or "context management" applications so that the users could focus their attentions entirely on performing and completing their tasks using their other software tools. Users might want their AI assistants to be able to manually or automatically load task models and to be able to mark progressions through these tasks using combinations of natural-language dialogue and observations of users’ interactions with their other software tools.

Client-side context data could be obtained from users manually making use of interoperable "task management” or "context management" applications, today, and AI assistants could be increasingly useful with respect to context management, into the future.

Client-server Context-aware Computing

How might users share their task contexts with trusted services? Presented, here, is that a new HTTP header, Context, could be of use for sending URLs both representing and referring to users' task contexts.

Considered Scenarios

1. A Well-known Third-party Service Hosts Business Process Model Diagram

Context: https://en.wikiprocess.org/wiki/process12345678.bpmn#component

A trusted service would receive a context URL from a client. This URL would allow that service to retrieve a resource, e.g., a business process model diagram. Alternatively, this URL may function as a URI and be well-known to the service, e.g., a URL signifying that a user is conducting scholarly research and searching for papers.

2. Another Third-party Service Hosts Business Process Model Diagram

Context: https://a.cloud/user1234/assistant5/process678.bpmn#component

Here, a client shares a URL for sharing a user’s task context, a URL referring to a third-party service which, for example, could be orchestrated by a user’s AI assistant.

3. A Client Hosts Business Process Model Diagram

Context: https://123.45.6.7:8910/clientdevice/process.bpmn#component

Here, a client sends a context URL which refers to a resource on itself, the client device.

Example Walkthroughs

Vanilla

1. User opens a tab and enters https://www.search.com into the address bar.
   1. The user has previously provided permission for that domain to access their task context.
2. The user’s browser initiates an HTTP request with the header Context set to a URL value.
3. The server uses the context URL to retrieve a remote resource (the resource may be cached).
4. The server processes the resource, e.g., a business process model diagram, to provide context-aware content or services.
5. The server responds.

More Efficient

1. User opens a tab and enters https://www.search.com into the address bar.
   1. The user has previously provided permission for that domain to access their task context.
2. The user’s browser initiates an HTTP request with the header Context set to a URL value.
3. The server efficiently responds with an HTTP response, a page with a text input box for the user to enter a search query.
   1. While the user reacts to the presented content, the server performs an HTTP request to the provided Context URL.
   2. The server caches that response.
   3. The server performs processing necessary to respond to predicted subsequent requests from the user.
4. The user enters a search query into the text input box and presses return.
5. The browser initiates an HTTP request to https://www.search.com/?q=text with the header Context set with an identical value as before in step 2.
6. The server rapidly provides a context-aware search result, having performed processing on the user’s context data in steps 3.i – 3.iii while the user was reacting to presented content and subsequently entering a query.

Security

A security-related concern is that a malicious actor could wield a botnet to initiate or escalate a DDOS attack using a large-scale service, e.g., a search engine, which would retrieve content using specified context URLs.

This concern is assuaged by two of the three scenarios indicated above: (1) the context URL refers to a business process model diagram hosted by a well-known third-party service, (3) the context URL refers to a business process model diagram hosted by the client device.

Only in one of the three indicated scenarios, (2) the context URL refers to a non-well-known third-party, would measures for mitigating DDOS attacks be acutely pertinent, if this scenario (2) were supported by a service at all.

Privacy

Such features involving sharing users’ task contexts with trusted services would, as considered, require users’ permissions, after which a Web browser or other client-side software application could obtain these URLs from users’ operating systems and forward them to trusted services.

Perhaps users could toggle this permission on or off using lock-icon menus provided in Web browsers’ address bars.

As considered, this feature would be unavailable for in-private Web browsing experiences.

Other Discussion Topics

Alternatives

In addition to providing a URL for the value of a HTTP Context header, a JSON string could be provided for the value of this HTTP header. Using a JSON string could enhance expressiveness. As considered, these JSON strings would utilize URLs for task contexts as described above.

Other Context-related Data

Additionally, should more context details be useful, beyond where in a specified task that a user is, other HTTP request headers could be utilized, e.g.: Cookie, Context-Cookie, or Context-Details. These headers could provide a sequence of delimited key-value pairs and the semantics and schema for these could be inferred from the value of the Context header.

Supporting Multitasking

Could operating systems, “task management” or "context management" applications, and AI assistants support multiple "tabs" for multiple tasks?

Could multiple Context headers in a HTTP request signify that a user was multitasking?

Artificial Intelligence

Beyond Web browsing scenarios, users' other software tools utilizing HTTP, e.g., their AI assistants, could utilize the dynamic context data obtained from operating systems or from interoperating "task management" or "context management" applications, in a configurable manner, to better interact with trusted context-aware services on their users' behalves.

Conclusion

With respect to HTTP request headers, a core set of fields is standardized by the IETF in RFC 9110 and 9111. The Field Names, Header Fields and Repository of Provisional Registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application.

I wanted to share these ideas, here, first, with the W3C WICG for discussion and brainstorming. What do you think about these ideas for a new standard HTTP request header to enable new context-aware technologies, e.g., context-aware search engines, Q&A systems, recommender systems, and AI assistants?