W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Nice

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 16 Aug 2013 11:24:40 -0700
Message-ID: <CABkgnnUa=s2RObqYOctfqtXitagj6jmbkLgadnyHH6HhNPhc4w@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 16 August 2013 11:04, William Chan (陈智昌) <willchan@chromium.org> wrote:
> This Nice header proposal seems to ascribe semantic meaning to certain nice
> values. In that sense, it's very distinct from stream priorities.

This semantic meaning is very loose.  Intentionally.  The first
writeup I put together had two values: 0 and 1.  Then I was convinced
that some applications might want a tiny bit more flexibility, which
would allow them to operate without having close coordination between
the origin server and client.  Learning what means what is still
something that requires some degree of coordination, but that can be a
little less than real-time.

The key here is that the client needs to know that there is some value
in dropping the reliability of the request it is making.  That's
unavoidable.  Going from that to more than one level isn't a huge
stretch, but drawing the line is the real challenge.

The number and nature of possible values and expressions of policy is
a massive rathole, as you might appreciate.  When discussing this with
colleagues here, we came up with a range of different ways to manage
this, including bit maps, multidimensional coordinate systems, special
labeling and a few other crazy schemes including a set of URI path
regular expressions (no kidding, that was the *first* proposal
floated).  The current proposal is as it is because when I'm building
the bike shed, I get to decide the colour.
Received on Friday, 16 August 2013 18:25:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC