Re: Activity Identifiers - Draft Submission

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 😊 

Thanks,
Scott

> On 23 May 2019, at 20:20, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> 
> https://datatracker.ietf.org/doc/draft-activity-identifiers/?include_text=1
> 
>> It is very common that implementers of HTTP severs require the ability
>> to associate an identifier to an HTTP request and or response, this can
>> be for a number of reasons which could include checking for duplicate
>> requests,
> 
> Is Activity-Id supposed to be nonce ? Different value on every request?
> 
> / Kari Hurtta
> 
> 
>

Received on Thursday, 23 May 2019 19:54:35 UTC