Subject: Fwd: New Version Notification for draft-nottingham-http-structure-retrofit-00.txt

From: Mark Nottingham <[email-masked]>
Date: Thu, 7 Oct 2021 10:07:20 +1100

FYI. 

This was previously hidden in the binary structured fields draft, but it seems potentially useful for other purposes -- e.g., exposing more fields in a structure-oriented API for HTTP (e.g., Fetch), canonicalising fields (e.g., for Signatures), etc.

Cheers,

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-http-structure-retrofit-00.txt
> Date: 7 October 2021 at 10:05:19 am AEDT
> To: "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-http-structure-retrofit-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-http-structure-retrofit
> Revision:	00
> Title:		Retrofit Structured Fields for HTTP
> Document date:	2021-10-07
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/archive/id/draft-nottingham-http-structure-retrofit-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-http-structure-retrofit/
> Html:           https://www.ietf.org/archive/id/draft-nottingham-http-structure-retrofit-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-http-structure-retrofit
> 
> 
> Abstract:
>   This specification defines how a selection of existing HTTP fields
>   can be handled as Structured Fields.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 7 Oct 2021 00:48:24 +0100

Interesting!

Question: is the intent that this is a one-shot pass or do you intend to
set a methodology for how other headers can be mapped? For instance, we
could keep the digest field in ABNF and use a similar methodology to define
SF-digest alongside it in the digest spec.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 7 Oct 2021 10:55:09 +1100

On 7 Oct 2021, at 10:48 am, Lucas Pardue <[email-masked]> wrote:
> 
> Interesting!
> 
> Question: is the intent that this is a one-shot pass or do you intend to set a methodology for how other headers can be mapped? For instance, we could keep the digest field in ABNF and use a similar methodology to define SF-digest alongside it in the digest spec.

That's a good question, and I'm punting on covering it in-spec for now.

One approach is to assume that new headers will be defined as SF, so there's no need. As long as this spec carves off the top n% (n~80-90), it's adequate for most purposes.

Another is to allow further specs to retrofit additional headers in the same fashion.

Another is to let specs retrofit themselves, as you suggest for Digest.

Cheers,

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 7 Oct 2021 01:06:46 +0100

> That's a good question, and I'm punting on covering it in-spec for now.

Make sense.

One approach is to assume that new headers will be defined as SF, so
> there's no need. As long as this spec carves off the top n% (n~80-90), it's
> adequate for most purposes.
>

My question was also loaded towards the segment of people that use HTTP and
never put it in an open spec because they have no need for broad interop.
For example, if x-custom-thing was used between internal services then
there could be benefit in trying to align all header handling towards
structured headers without having to go and think hard about writing a spec
about it. Trying to define some generic framework for those folks is likely
going to fail so the I-D does right to avoid that trap. But a clear
statement along the lines of "the approaches in this document could be
applied to other HTTP fields" might stop a team bickering about the
practicalities of such a switch.

Cheers
Lucas

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 7 Oct 2021 11:41:12 +1100

> On 7 Oct 2021, at 11:06 am, Lucas Pardue <[email-masked]> wrote:
> 
> My question was also loaded towards the segment of people that use HTTP and never put it in an open spec because they have no need for broad interop. For example, if x-custom-thing was used between internal services then there could be benefit in trying to align all header handling towards structured headers without having to go and think hard about writing a spec about it. Trying to define some generic framework for those folks is likely going to fail so the I-D does right to avoid that trap. But a clear statement along the lines of "the approaches in this document could be applied to other HTTP fields" might stop a team bickering about the practicalities of such a switch.

I think it depends very much on what they want to use it for. 

For example, my primary use case is binary encoding of headers, but that has an explicit fallback mechanism to use if the field doesn't parse as SF successfully. So it's effectively transparent.

Likewise for a Fetch extension that allowed some headers to be manipulated as SF; as long as the string-based API were still available, nothing should break just because the SF API is introduced and used for some fields.

If OTOH someone with, say, a HTTP API exposed to customers suddenly starts treating an incoming field as SF when it was previously defined more loosely, some things are likely to break.

With that context, I agree. I'll try to expand the doc along these lines, sort of an applicability statement.

Thanks!

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 07 Oct 2021 11:12:39 +0000

--------
Mark Nottingham writes:

> FYI. 
>
> This was previously hidden in the binary structured fields draft, but it 
> seems potentially useful for other purposes -- e.g., exposing more 
> fields in a structure-oriented API for HTTP (e.g., Fetch), 
> canonicalising fields (e.g., for Signatures), etc.

I have been wondering when you were going to drag that out in the open :-)

Yes, I absolutely think we should do this, because this was pretty much
precisely why (and how!) I came up with SF to begin with.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 08 Oct 2021 15:08:07 +1100

Hi Mark,

I was just reading Mike's draft and was reminded of the shape of Alt-Svc:

  alt-value     = alternative *( OWS ";" OWS parameter )
  alternative   = protocol-id "=" alt-authority

That doesn't fit the dictionary syntax in RFC 8941.  Dictionaries can't have a value and parameters at the same time:

  dict-member    = member-key ( parameters / ( "=" member-value ))

I conclude that SF-Alt-Svc is necessary to make this fit.  I don't know how to do that exactly, but it seems like you could fix the ALPN issue at the same time.  Having a restriction on what ALPN we can use for future HTTP versions doesn't seem like it would be a big burden, so maybe ``SF-Alt-Svc: h3-9000;h="authority.example:443";ma=12345'' isn't so bad.

On Thu, Oct 7, 2021, at 10:07, Mark Nottingham wrote:
> FYI. 
>
> This was previously hidden in the binary structured fields draft, but 
> it seems potentially useful for other purposes -- e.g., exposing more 
>> *From: [email-masked]
>> *Subject: **New Version Notification for draft-nottingham-http-structure-retrofit-00.txt*
>> *Date: *7 October 2021 at 10:05:19 am AEDT
>> *To: *"Mark Nottingham" <[email-masked]>
>> 
>>

---

From: Matty K <[email-masked]>
Date: Fri, 08 Oct 2021 15:14:35 +1000

On 2021-10-08 14:08, Martin Thomson wrote:
> That doesn't fit the dictionary syntax in RFC 8941.  Dictionaries
> can't have a value and parameters at the same time:
> 

Ah, it's a gotcha:

~~~
member-value   = sf-item / inner-list
sf-item   = bare-item parameters
~~~

(In section 3.3)

Cheers
-- 
Matty K

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 08 Oct 2021 16:59:00 +1100

> Ah, it's a gotcha:

Ugh.  Too clever by half.  Never mind then.

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Oct 2021 12:18:51 -0400

I think this is a great idea and we should push this work forward. In the Signatures draft, we’d love to be able to point to a separate document for information about canonicalizing fields wherever possible. We can already do that with things that are native structured fields, and this would allow us to point to a list that lets  you say “you can treat it as a native structured field even if it’s not defined as one”. 

 — Justin

> On Oct 6, 2021, at 7:07 PM, Mark Nottingham <[email-masked]> wrote:
> 
> FYI. 
> 
>> From: [email-masked] <mailto:[email-masked]>
>> To: "Mark Nottingham" <[email-masked] <mailto:[email-masked]>>
>> 
>> 
>> URL:            https://www.ietf.org/archive/id/draft-nottingham-http-structure-retrofit-00.txt <https://www.ietf.org/archive/id/draft-nottingham-http-structure-retrofit-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-nottingham-http-structure-retrofit/ <https://datatracker.ietf.org/doc/draft-nottingham-http-structure-retrofit/>
>> Html:           https://www.ietf.org/archive/id/draft-nottingham-http-structure-retrofit-00.html <https://www.ietf.org/archive/id/draft-nottingham-http-structure-retrofit-00.html>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-http-structure-retrofit <https://datatracker.ietf.org/doc/html/draft-nottingham-http-structure-retrofit>
>> 
>> 
>> Abstract:
> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 15 Oct 2021 19:08:37 +0000

I love the idea of retroactively applying Structured Fields to existing header fields that fit its syntax. I'm not sure I grok the intent of the SF- representations though. Is the expectation that a message might contain both the "legacy" and structured field representation of a header field, e.g., have both `Date` and `SF-Date`? If we allow messages to contain multiple representations of the same value, there is an opportunity for nasty bugs when different parts of an application stack look at different representations without validating that they actually represent the same value.

—
Annabelle Backman (she/her)
[email-masked]<mailto:[email-masked]>

On Oct 12, 2021, at 9:18 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> 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.

 — Justin

On Oct 6, 2021, at 7:07 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:

FYI.

Cheers,

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-nottingham-http-structure-retrofit-00.txt
Date: 7 October 2021 at 10:05:19 am AEDT
To: "Mark Nottingham" <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat