Re: Bikeshed: "context" parameter for signatures

[Tyler Ham <[e-mail]>]

I agree with those thoughts. I like "tag" slightly better than "label", but
both sound good to me.

The words "domain", "reference", and "ref" also come to mind. I think these
are worse for various reasons, but wanted to toss them out there in case
they spark any other ideas.

Tyler


On Fri, Sep 23, 2022, 11:33 AM Lucas Pardue <[e-mail]>
wrote:

> "tag" or "label" sound like good options to me.
>
> On Fri, Sep 23, 2022 at 5:54 PM Backman, Annabelle <[e-mail]>
> 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)
>> [e-mail]
>>
>>
>>
>>
>> On Sep 22, 2022, at 11:53 AM, Tyler Ham <[e-mail]> 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 <[e-mail]> 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
>>>
>>
>>