Re: A New HTTP Request Header for Specifying Task Contexts

What would a server do in response to this?

How would this differ from having a different resource for each stage of a process?  That is, if the client has different state, why can it not request a different resource according to a map (state -> resource).

On Sat, Nov 23, 2024, at 14:30, Adam Sobieski wrote:
> IETF HTTP Working Group,
>
> Hello. I recently thought of and would like to share with the group 
> some ideas involving a new HTTP request header, "Context", for 
> providing users’ task contexts to trusted context-aware services, e.g., 
> search engines, Q&A systems, recommender systems, and AI assistants.
>
> As far as I know, it is a new idea to represent task contexts using 
> URLs. In these regards, URLs could refer to business process model 
> diagrams (which task that a user was doing):
>
> https://en.wikiprocess.org/wiki/process12345678.bpmn
>
> and URLs’ fragment identifiers could refer to components in those 
> diagrams (where a user was in that task):
>
> https://en.wikiprocess.org/wiki/process12345678.bpmn#component
>
> Next, these ideas involve using a new HTTP request header, "Context", 
> in a manner resembling:
>
> Context: https://en.wikiprocess.org/wiki/process12345678.bpmn#component
>
> to share URLs both representing and referring to users’ task contexts 
> with trusted context-aware services.
>
> I recently wrote about these ideas in greater detail in a new GitHub 
> issue: https://github.com/WICG/proposals/issues/188 . I would like to 
> invite anyone interested in commenting upon, discussing, and improving 
> upon these ideas to reply either in this mailing list or, preferably, 
> in that GitHub issue.
>
> Thank you for reading and considering these ideas. I am looking forward 
> to discussing them with you.
>
>
> Best regards,
> Adam Sobieski
> http://www.phoster.com

Received on Sunday, 24 November 2024 21:16:39 UTC