Subject: 425 (Too Early)

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Aug 2017 11:18:56 +1000

Mark and I had a little disagreement about what status code to use.
That's why the draft says 4NN.

But now it seems that people want to use this sooner rather than later
and for that we need a number.

Would anyone object to us camping on 425?  It doesn't appear to be taken.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Aug 2017 04:03:12 +0200

> Would anyone object to us camping on 425?  It doesn't appear to be taken.

no pb here.

Thanks,
willy

---

From: Ted Hardie <[email-masked]>
Date: Fri, 4 Aug 2017 09:11:03 -0700

> Would anyone object to us camping on 425?  It doesn't appear to be taken.

Why not ask IANA for an early allocation and see what they assign?

Ted

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 4 Aug 2017 17:24:25 +0100

On 04/08/2017 17:11, Ted Hardie wrote:

> On Thu, Aug 3, 2017 at 6:18 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
+1. I can request early allocation.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Aug 2017 18:40:04 +0200

> +1. I can request early allocation.

Any reason not to pick 419?

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Aug 2017 10:38:54 +1000

> On 4 Aug 2017, at 11:18 am, Martin Thomson <[email-masked]> wrote:
> 

Well, we did, but the reason we went to 4NN is explained here:

"""
Proposals for new status codes that are not yet widely deployed ought to avoid allocating a specific number for the code until there is clear consensus that it will be registered; instead, early drafts can use a notation such as "4NN", or "3N0" .. "3N9", to indicate the class of the proposed status code(s) without consuming a number prematurely.
"""
- <http://httpwg.org/specs/rfc7231.html#considerations.for.new.status.codes>

Personally, I think a reasonable time to nail down the status code is at WG adoption, which 

(chair hat on) should be very soon. Looking at the minutes, I think we can do a CfA now-ish and incorporate a code in the WG -00, after a bit of discussion.

> Would anyone object to us camping on 425?  It doesn't appear to be taken.

The first unassigned 4NN status code in <https://www.iana.org/assignments/http-status-codes/> is 418.

Cheers,

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

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 5 Aug 2017 11:26:35 +1000

> The first unassigned 4NN status code in <https://www.iana.org/assignments/http-status-codes/> is 418.

Nooo, not the teapot!

</paint>

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 5 Aug 2017 15:20:55 +1200

>> The first unassigned 4NN status code in <https://www.iana.org/assignments/http-status-codes/> is 418.

Seconded for preserving the 418 teapot.

FWIW; I have seen it used in a number of real-world contexts. Wikipedia 
may not be the best reference, but its page on 418 [1] links to several 
instances of actual use if you want running code to justify an IANA 
registration for the status, methods, scheme, headers and media-type's 
outlined in the two teapot RFC's.

[1] <https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol>

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Aug 2017 13:55:31 +1000

HTCPCP was a joke protocol to point out all of the bad ways that people try to reuse HTTP, so there's a certain amount of irony here. I don't think a couple of deployments of a joke is enough to justify consuming a code point in such a constrained name space.

IIRC we discussed this as part of BIS and explicitly decided not to reserve 418. 

Now, we could make an argument to skip over it now and use it when we've exhausted other 4NN code points, but personally my inclination is to do it now; if we don't want it to ossify, the earlier the better.

Cheers,

> On 5 Aug 2017, at 1:20 pm, Amos Jeffries <[email-masked]> wrote:
> 
> FWIW; I have seen it used in a number of real-world contexts. Wikipedia may not be the best reference, but its page on 418 [1] links to several instances of actual use if you want running code to justify an IANA registration for the status, methods, scheme, headers and media-type's outlined in the two teapot RFC's.
>

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 5 Aug 2017 16:03:06 +1000

> Now, we could make an argument to skip over it now and use it when we've exhausted other 4NN code points, but personally my inclination is to do it now; if we don't want it to ossify, the earlier t…

The only time I ever used a 418 response it was for some sort of
detectable chalk-and-cheese mismatch, specifics of which I can't
remember now, but it felt better at the time to misuse the teapot code
than to mint a new application-specific 4xx, or to use a combination
of 400+payload.

It feels a bit off ditching a status code that doesn't have a similar,
more-official version (like 420 Enhance Your Calm vs 429 Too Many
Requests).  That said, I'm not sure if I've read RFC 2324 the wrong
way;  maybe it would have been more correct for me to signal the error
in the content-type rather than the status code.

Anyway, off-topic for the discussion at hand.

Cheers

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 5 Aug 2017 08:08:45 +0200

On Sat, Aug 05, 2017 at 01:55:31PM +1000, Mark Nottingham wrote:
> Now, we could make an argument to skip over it now and use it when we've
> exhausted other 4NN code points, but personally my inclination is to do it
> now; if we don't want it to ossify, the earlier the better.

I have an argument for skipping it, which is that it's part of a
contiguous range of 3 codes and that we need only one. There are
isolated holes likes 425 and 427 and I'd rather fill these holes
when we need a single code, and use larger areas when we need
contiguous series.

Cheers,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 5 Aug 2017 20:32:46 +1200

On 05/08/17 15:55, Mark Nottingham wrote:
> HTCPCP was a joke protocol to point out all of the bad ways that
> people try to reuse HTTP, so there's a certain amount of irony here.
> I don't think a couple of deployments of a joke is enough to justify
> consuming a code point in such a constrained name space.
> 
> Now, we could make an argument to skip over it now and use it when
> we've exhausted other 4NN code points, but personally my inclination
> is to do it now; if we don't want it to ossify, the earlier the
> better.
It seems to me that it would be best for any formal definition of 418 at 
least be consistent with the well-known meaning from the joke - then 
people running across the wrong RFC for it will not be too confused. 
There are many non-joke things that are rejected already; 406, 414, 426, 
501, 505 etc. so something serious rejecting the clients choice of 
protocol is not exactly out of place.

"418 Protocol Unsupported" with a definition between 426 (but not 
requiring Upgrade) and 505 (but covering the whole choice of protocol, 
not just its version) would be of some benefit to most middleware and 
servers I imagine.

For example Squid cannot use 426 due to Upgrade, but we still have to 
deal with multiple weird protocols arriving on port 80 and 443. Today we 
400 them simply for lack of anything more specific and helpful.

Amos

---

From: Eitan Adler <[email-masked]>
Date: Sat, 5 Aug 2017 08:49:50 -0700

> when we need a single code, and use larger areas when we need

Is there any existing use case for contiguous error codes within the
hundred ranges?

FTR I agree with Amos Jeffries: any formal definition of 418 at least
be consistent with the well-known meaning from the joke.

-- 
Eitan Adler

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 5 Aug 2017 18:02:12 +0200

> Is there any existing use case for contiguous error codes within the

There could be. Look at the number of 30x we have. We could imagine
supporting multiple retry codes later with different causes or actions
for example. It serves no purpose to puch holes while it can be useful
to maintain continuity.

> be consistent with the well-known meaning from the joke.

Yes I agree as well. I don't like the status of this code which is
neither allocated nor safe to use for certain purposes due to having
been heavily abused :-/

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 6 Aug 2017 06:55:19 +0200

Hi Mark,

> now; if we don't want it to ossify, the earlier the better.

I'm in fact worried by the possible lack of transparency we could meet
on certain intermediaries or web anti-viruses causing 0-RTT to become as
unreliable as pipelining once was for HTTP/1.1. Here we need a "clean"
status code with no particular history because it will act a bit like a
redirect and will induce some automated processing from the user agent.
Thus I'm not happy at all with using an already known code for this draft
even if the code was known for wrong reasons.

For most status codes we only need something informative reported to the
user (like was the case for 451) and that would have been fine, but here
I think we may regret it.

Thus better use 425 (or even 419 if you want to take the first unused
code), and all agree here that the next 4xx status code not inducing
automated processing will be 418.

Thanks,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 Aug 2017 19:46:18 +1000

I think that's a reasonable argument; since the intended use triggers automated behaviour, we want to be conservative as possible.

Next time we have a more informational 4xx proposed, 418 should be the strongly preferred option, right?

Cheers,

P.S. I'm doing some work to eradicate 418 from existing implementations. :)

> On 6 Aug 2017, at 2:55 pm, Willy Tarreau <[email-masked]> wrote:
> 
> Hi Mark,
>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 6 Aug 2017 22:17:14 +0200

On Sun, Aug 06, 2017 at 07:46:18PM +1000, Mark Nottingham wrote:
> I think that's a reasonable argument; since the intended use triggers
> automated behaviour, we want to be conservative as possible.

Thank you :-)

> strongly preferred option, right?

I'm fine with this.

> P.S. I'm doing some work to eradicate 418 from existing implementations. :)

Great! It must first disappear from all docs all over the net :-/

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Aug 2017 08:05:23 -0700

So, I poked a couple of implementations to see if they'd remove 418's "teapot" semantics, and there was a reaction (to put it mildly).

I think we need to reserve 418 to make it clear it can't be used for the foreseeable future; when we did BIS, it was asserted that it wasn't necessary to do so, but we were either seriously misinformed, or there's been a lot of implementation of HTCPCP in the meantime.

That means we need to instruct IANA to change its status to "Reserved" , e.g.:
  https://tools.ietf.org/html/draft-nottingham-thanks-larry-00

... although it'd be MUCH easier if we could just instruct IANA directly. Alexey, the registry is "IETF Review" -- is there any way we can make this kind of update without publishing an RFC?

> On 6 Aug 2017, at 1:17 pm, Willy Tarreau <[email-masked]> wrote:
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Aug 2017 16:41:45 +0100

> ... although it'd be MUCH easier if we could just instruct IANA directly. Alexey, the registry is "IETF Review" -- is there any way we can make this kind of update without publishing an RFC?
This probably can be done with an IESG action. But you already wrote a 
draft, I can just AD sponsor it. If IESG says "don't publish as an RFC", 
we can skip publishing it.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Aug 2017 08:45:31 -0700

That works, thanks. Note that if they do it by IESG action, the reference should NOT point to 2324, since that would cause yet more confusion about whether HTCPCP is "part" of HTTP.

If they really want it as an RFC, we could also wait until HTTPtre.

Thanks,

> On 11 Aug 2017, at 8:41 am, Alexey Melnikov <[email-masked]> wrote:
> 
> This probably can be done with an IESG action. But you already wrote a draft, I can just AD sponsor it. If IESG says "don't publish as an RFC", we can skip publishing it.
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Aug 2017 09:01:37 -0700

Everyone,

See thread below -- Alexey is going to AD-sponsor and do an IETF LC on:
  https://tools.ietf.org/html/draft-nottingham-thanks-larry-00

(And, hopefully, the IESG will just do an action, rather than actually publishing it)

If folks have concerns about this path forward from a WG perspective, please say so now.

> On 11 Aug 2017, at 8:45 am, Mark Nottingham <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 12 Aug 2017 20:00:56 +1000

See also https://martinthomson.github.io/teapot/draft-thomson-teapot.html

I thought better of publishing it, but it seems apropos to mention.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 12 Aug 2017 09:45:01 -0700

Ah, dammit; I was talking about Russell's teapot just the other day, and failed to make the connection.

Happy to take a PR if you want to.

> On 12 Aug 2017, at 3:00 am, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Aug 2017 09:45:16 +1000

> Happy to take a PR if you want to.

Not sure what form that would take...

IESG action would be my preferred approach here.  This doesn't need
yet another RFC.  The number of citations of 2324 is already
disproportionately high.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 13 Aug 2017 16:49:26 -0700

That's the plan. Alexey said the iesg might want their pound of spec, tho. 

Sent from my iPhone

> On 13 Aug 2017, at 4:45 pm, Martin Thomson <[email-masked]> wrote:
>