Re: message-signatures: Renaming "Content Identifiers"

I agree that these should label the input to the signature — that’s kinda what Annabelle and I :thought: we were doing with “content identifier” in the first place, but obviously that was incorrect. :) 

“Message” is a good thing to hang from, but to me, the problem is less that and more of what do you call the specific part of the message that you’re talking about — and what do you call all of them collectively, as parts. So “message part” might work, in that sense — but “multi-part” is already an established term in this space that means something very different.

 — Justin

> On Jul 26, 2021, at 11:02 PM, ‪Amos Jeffries‬ <squid3@treenet.co.nz> wrote:
> 
> Possibly the draft could change viewpoint from naming output ("content") to that of inputs - the HTTP "message".
> 
> So the terms would be something like "message areas" ?
> 
> Amos
> 
> 
> -------- Original message --------
> From: Mark Nottingham <mnot@mnot.net>
> Date: Sat, 24 Jul 2021, 12:34
> To: Justin Richer <jricher@mit.edu>
> Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: message-signatures: Renaming "Content Identifiers"
> I'm not fixated on any one term, but 'elements' gets a lot of use in adjacent spaces like HTML and XML.
> 
> Cheers,
> 
> 
> > On 24 Jul 2021, at 4:34 am, Justin Richer <jricher@mit.edu> wrote:
> > 
> > I’m personally not super keen on “Values” because there are too many parts that already have an internal idea of a “value”, especially fields. 
> > 
> > I like “Covered Components”, and if it’s not stepping on anything else in the HTTP space already that might be our best option. “Protocol Elements” was also suggested at one point, which would lead to “Element Identifiers” as the indicator portion.
> > 
> > — Justin
> > 
> >> On Jul 16, 2021, at 8:41 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >> 
> >> I suspect you're going to need to invent something.
> >> 
> >> Perhaps 'Covered Values' and 'Value Identifiers'? 
> >> 
> >> or 'Covered Components' and 'Component Identifiers'?
> >> 
> >> Cheers,
> >> 
> >> 
> >>> On 17 Jul 2021, at 2:59 am, Richard Backman, Annabelle <richanna@amazon.com> wrote:
> >>> 
> >>> Hello HTTP Working Group,
> >>> 
> >>> As discussed during the previous interim meeting, the way that the draft-ietf-http-message-signatures draft uses the term "content" is not consistent with the meaning of "content" as defined elsewhere in HTTP. That raises the question: what term should we use?
> >>> 
> >>> As a refresher (or for those who haven't been following this particular thread thus far), Message Signatures uses the term "Covered Content" to refer to the different pieces of an HTTP message that are covered by a message signature. It also uses the term "Content Identifier" to refer to the identifiers used to indicate which pieces of an HTTP message are included within the Covered Content. The draft currently defines Content Identifiers for the following pieces of information:
> >>> • Header fields
> >>> • Specific members within the value of a dictionary structured field
> >>> • Signature metadata (e.g., algorithm and key identifiers, creation time, expiration)
> >>> • The request target, target URI, and method, as defined in draft-ietf-httpbis-semantics
> >>> • The response status, as defined in draft-ietf-httpbis-semantics
> >>> • Specific portions of a request message's target URL: scheme, authority, path, query
> >>> • Specific query parameters from the query portion of a request message's target URL
> >>> 
> >>> Additionally, there are use cases (albeit hotly contested, in some cases) for adding Content Identifiers for the following:
> >>> • Footer fields
> >>> • Specific cookies included in a request message
> >>> • Ranges of items within a comma-delimited unstructured field (e.g., a proxy signing the first N items in the "Via" header field, allowing for further proxies to add additional items)
> >>> • Ranges of elements within a list structured field
> >>> 
> >>> Are there any existing terms in the HTTP space that fit this use case? Or a combination of terms that isn't too much of a mouthful? Or do we need to invent something?
> >>> 
> >>> —
> >>> Annabelle Backman (she/her)
> >>> richanna@amazon.com
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >> 
> >> 
> > 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
>