Re: Bikeshed: "context" parameter for signatures

"tag" or "label" sound like good options to me.

On Fri, Sep 23, 2022 at 5:54 PM Backman, Annabelle <richanna@amazon.com>
wrote:

> "appdata" doesn't address the structured data concerns Justin raised,
> which I agree with.
>
> I like "tag" or "label", as they capture both the variable,
> application-defined meaning of this parameter's value, and its optionality.
>
> —
> Annabelle Backman (she/her)
> richanna@amazon.com
>
>
>
>
> On Sep 22, 2022, at 11:53 AM, Tyler Ham <tyler@thamtech.com> wrote:
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> My first thought when I see the labels "app" and "application" is that the
> value is meant to be the name of an application.
>
> How about something like "appdata"? This changes the noun to a generic
> "data", but it keeps "app" in there as an adjective to indicate that this
> parameter is for something application-specific.
>
> Tyler
>
>
> On Thu, Sep 22, 2022, 8:43 AM Justin Richer <jricher@mit.edu> wrote:
>
>> I missed an issue that had been filed (but not tagged) prior to the
>> publication of signatures-12, and it asks a pretty simple question:
>>
>> We added a “context” parameter to allow applications to put a specific
>> string that the application can recognize into the signature parameter set,
>> so that (for example) an authz protocol can declare that a specific value
>> be used or a cloud deployment can have all of its proxies use the same
>> value. However, the term “context” is used in other ways in the spec, so
>> it’s not the best term to use for this new parameter. The proposal is to
>> change “context” to “application” or even the shorter “app”:
>>
>> https://github.com/httpwg/http-extensions/issues/2249
>>
>>
>> I’d like to do a quick bike shed on this parameter name here, for anyone
>> who has an opinion. Since it’s newer, existing libraries mostly don’t have
>> it supported yet so if we’re going to change it we should change it right
>> now.
>>
>>
>> Thanks,
>>  — Justin
>>
>
>