Re: ORIGIN - suggested changes

[Martin Thomson <[e-mail]>]

These seem like good changes in principle.  I've left a few comments
on the PR that say much the same as below...

On 1 February 2017 at 17:50, Mark Nottingham <[e-mail]> wrote:
>   - Removes the requirement for a supporting client to check DNS to determine if the server is authoritative, when ORIGIN is received

You should do something about http:// resources.  This means that this
is a perfect http:// hijacking mechanism.  I don't think that was the
intent.  I would prefer if this were limited to HTTPS, which at least
leaves certificate validation.

>   - Redefines the initial Origin Set as whatever SNI included (if anything).

If you do support this feature, the second change leads to having no
valid origins initially if you don't use SNI.  It also could be read
to prohibit coalescing as we do today.  Presumably the set is whatever
we have today until you see an ORIGIN frame.  You should probably say
something about that.

> Some people have also been talking about simplifying ORIGIN, e.g., by removing some of the set operations. I think we should talk about that on list first.

Let me put my stake in the ground.

The current design is just a little too complicated.  The ability to
clear the set and remove from the set is where a lot of that
complexity comes from.

Let's say that if you want to start over, then you really start over:
make a new connection in that case.  The need to remove is greatly
diminished by starting with a very small set.  If you do need to
cleave off an origin after previously advertising it, then ALTSVC is
available and much more graceful than anything this provides.  Removal
- as specified - is still subject to races and therefore violence,
since there is no acknowledgment.

That just leaves the frame being able to add origins to the set that a
client might consider using.  That's pretty easy to manage.  Anything
you have ever seen in an ORIGIN frame is a candidate.  Servers can add
to the set any time they like (likely in response to serving content
that references other origins), and clients can choose to forget
origins if the list ever gets too long for them to manage.

As a discretionary mechanism in this way, this could be a lightweight
feature that nicely complements ALTSVC.