- From: Tyler Ham <tyler@thamtech.com>
- Date: Fri, 23 Sep 2022 14:56:48 -0600
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: "Backman, Annabelle" <richanna@amazon.com>, Justin Richer <jricher@mit.edu>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAGQ3E+ePQTh=+851ucNpaFwLfu1XnjgmfWOjHqLYgekBvtr0sQ@mail.gmail.com>
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 <lucaspardue.24.7@gmail.com> wrote: > "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 >>> >> >>
Received on Friday, 23 September 2022 20:57:11 UTC