Subject: Fwd: New Version Notification for draft-nottingham-httpbis-origin-frame-00.txt

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2015 10:06:33 +0200

FYI. If people are interested and we have time, can discuss at the end of the WG meeting, or in the hallways.

Cheers,

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-httpbis-origin-frame-00.txt
> Date: 20 July 2015 10:04:11 am GMT+2
> To: "Mark Nottingham" <[email-masked]>, "Erik Nygren" <[email-masked]>, "Erik Nygren" <[email-masked]>, "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-httpbis-origin-frame-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-httpbis-origin-frame
> Revision:	00
> Title:		The ORIGIN HTTP/2 Frame
> Document date:	2015-07-20
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-nottingham-httpbis-origin-frame-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-httpbis-origin-frame/
> Htmlized:       https://tools.ietf.org/html/draft-nottingham-httpbis-origin-frame-00
> 
> 
> Abstract:
>   This document specifies the ORIGIN frame for HTTP/2, to indicate what
>   origins are available on a given connection.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 20 Jul 2015 10:49:44 +0200

Ok, sounds easy to do and helpful for clients.

Nit-picking: 

- if a server wants to indicate that it does not offer/allow any 
  other origin on the current connection, can it send an empty frame or does
  it always have to include the SNI from the TLS connection?
- clients need to be prepared to get a 421 anyway (robustness)
- on a h2c connection, this could advise clients to re-use connections
  only for a set of origins. maybe a server preference for load balancing.
  (yeah, which clients?)

//Stefan

> Am 20.07.2015 um 10:06 schrieb Mark Nottingham <[email-masked]>:
> 

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Jul 2015 02:06:55 -0700

q: how do you know when a peer is finished sending?  One of the most
important questions I'd want to answer with this is "does the peer
consider this connection valid for origin X?"  but it doesn't seem to
be able to answer that question.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2015 11:08:22 +0200

The peers always have to be able to deal with 421, so I'm not sure what adding a final flag adds. Thoughts?

> On 20 Jul 2015, at 11:06 am, Martin Thomson <[email-masked]> wrote:
>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 20 Jul 2015 09:09:48 +0000

Two random thoughts on a quick read-through:

Is there value in the client being able to also send the frame, to inform the server what origins it thinks are valid on the connection based on the cert?  The server has the option to NACK by sending back a sub-set, rather than waiting until the client makes a request and gets a 421.  Easy way to fail fast.  Of course, the server can probably presume that the client would send everything in the cert, so it may be moot.

The client probably considers the server authoritative for an undefined set based on wildcards in the TLS cert.  Depending on the server config, the server may also not have a list of possible wildcard values.  The reference to RFC 6454 doesn't permit wildcards, but they seem like they're a necessary value for this use-case.

-----Original Message-----
From: Stefan Eissing [mailto:[email-masked]] 
Sent: Monday, July 20, 2015 10:50 AM
To: Mark Nottingham <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-nottingham-httpbis-origin-frame-00.txt

Nit-picking: 

//Stefan

>> Subject: New Version Notification for 
>> draft-nottingham-httpbis-origin-frame-00.txt
>> To: "Mark Nottingham" <[email-masked]>, "Erik Nygren" 
>> <[email-masked]>, "Erik Nygren" <[email-masked]>, "Mark 
>> Nottingham" <[email-masked]>
>> 
>> 
>>  This document specifies the ORIGIN frame for HTTP/2, to indicate 
>> what  origins are available on a given connection.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
> 
> --

<green/>bytes GmbH

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Jul 2015 04:47:08 -0700

> The peers always have to be able to deal with 421, so I'm not sure what adding a final flag adds. Thoughts?

If the set is never declared final, then there is uncertainty.  If the
intent is to avoid ever seeing 421, then that's not great.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2015 13:51:17 +0200

So, to be clear, the current design is that an ORIGIN frame *is* final; if you see a second origin frame, it effectively clears any previous ones.

Are you worried that a host will have so many origins as to require more than one frame?

> On 20 Jul 2015, at 1:47 pm, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Jul 2015 06:30:24 -0700

> So, to be clear, the current design is that an ORIGIN frame *is* final; if you see a second origin frame, it effectively clears any previous ones.

Sorry, I misinterpreted.  There doesn't appear to be any way to carry
multiple origins in the frame, so I kinda assumed that this was how it
operated.

---

From: Erik Nygren <[email-masked]>
Date: Mon, 20 Jul 2015 15:39:43 +0200

>From the doc:

     > [The frame] can contain one or more Origin-Len/Origin pairs.

On Mon, Jul 20, 2015 at 3:30 PM, Martin Thomson <[email-masked]>
wrote:

> > So, to be clear, the current design is that an ORIGIN frame *is* final;
> if you see a second origin frame, it effectively clears any previous ones.
>
>