Re: Activity Identifiers - Draft Submission

On Fri, 24 May 2019 at 07:56, Scott Perham <scott@polystream.com> wrote:
>
> In a sense - in that it is randomly generated and is quite often used to identify uniqueness in a request (although also often used indirectly in a common use case of finding a specific request in logs, for example). The value would also be returned to the caller (this is also very common even when the caller didn’t send the value first for practical uses like support tickets, etc) and the same value would be used in _all_ requests in that chain.
>
> So, Client -> Service A -> Service B (and back again) would all contain the same Activity Id.
>
> For RESTful service implementers, this is one of the most common patterns to help with root cause analysis, idempotent behaviour and asynchronous message correlation and is reimplemented and redefined in each use case.
>
> Just two simple examples using widely known services would be Azure requests (client-request-id) and AWS requests (x-amzn-RequestId).
>
> The purpose is to standardise this approach for HTTP service implementers as it’s become increasingly more common for client requests to result in additional requests “behind the scenes”, sometimes asynchronously and requiring correlation.
>
> There are obviously some privacy concerns if the value originated from a client that was programmed to encode sensitive information into the value without the users consent, but I think that the recommendation may be to enforce UUIDs to ensure this is can’t happen.
>
> I’m slowing learning the depth the draft should have been to begin with

Are you looking to solve the once-and-only-once problem, or the
tracing problem, which I see as related but separate.

On the latter see https://www.w3.org/TR/trace-context/ for some recent
standardisation work, as well as the now merging opencensus +
opentracing projects which I expect this time around *will* define a
wire format.

-Rob

Received on Friday, 24 May 2019 07:26:22 UTC