Subject: Additional status codes in HTTP/1.1

From: Willy Tarreau <[email-masked]>
Date: Thu, 25 Jul 2013 07:24:53 +0200

Hi,

A user notified me that status codes 428, 429, 431, 511 introduced in
RFC6585 by Mark & Roy are not mentionned at all in the current 1.1 draft.
 
Shouldn't we copy them there, or at least add a reference to RFC6585 so
that implementers know that these codes exist ?

Thanks,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Jul 2013 08:18:51 +0200

> that implementers know that these codes exist ?

No, that would send the wrong message.

The list in the spec is not exhaustive; there's an IANA registry for a 
reason.

Best regards, Julian

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 25 Jul 2013 09:51:05 +0200

> The list in the spec is not exhaustive; there's an IANA registry for a

But is there any good reason not to consolidate the codes that were known
at the time?

-- 
Nicolas Mailhot

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 25 Jul 2013 09:53:47 +0200

> But is there any good reason not to consolidate the codes that were known

I was thinking the same, maybe just a pointer to the respective RFCs,
especially if we know that some of them are already in use.

Best regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Jul 2013 10:24:37 +0200

> But is there any good reason not to consolidate the codes that were known

As I said: it sends the wrong message. What's relevant is the IANA registry.

If you have a specific proposal to make *that* clearer in the spec, 
please go ahead.

Best regards, Julian

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 25 Jul 2013 10:39:18 +0200

> As I said: it sends the wrong message. What's relevant is the IANA

Then why are the other codes documented at all? They should be in the IANA
registry! Some are so obsolete they're almost never used in the wild
nowadays.

Even though the ietf process allows creation of new rfcs to extend past
ones, the common practice has been to simplify implementor's lives and
merge extensions when the extended rfc is revised. Is this process
suddenly frowned upon?

-- 
Nicolas Mailhot

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Jul 2013 10:52:29 +0200

On 2013-07-25 10:39, Nicolas Mailhot wrote:
> ...
> ...

The registry is a set of pointers to specs. Each status code needs to be 
in *some* spec.

If you think we should drop some specific codes, then please be more 
specific about which, and why that would make the spec better.

> merge extensions when the extended rfc is revised. Is this process

The common practice *IMHO* is not to have to extend specs, but to have 
proper extension points, plus registries. That's how HTTP works.

Best regards, Julian

---

From: "Markus Lanthaler" <[email-masked]>
Date: Thu, 25 Jul 2013 11:05:11 +0200

On Thursday, July 25, 2013 10:25 AM, Julian Reschke wrote:
> >>> Shouldn't we copy them there, or at least add a reference to
> >>> RFC6585 so that implementers know that these codes exist ?
[...]
> > But is there any good reason not to consolidate the codes that were
> > known at the time?
> 

What about just changing

   Note that this list is not exhaustive -- it does not include
   extension status codes defined in other specifications.

in http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-6.1 to something like

   Note that this list is not exhaustive -- it does not include
   extension status codes defined in other specifications. IANA
   maintains a registry of all standardized status codes at [???]

Unfortunately, AFAIK, the URLs of those registries are not stable so I'm not sure how to reference it properly.

Cheers,
Markus

--
Markus Lanthaler
@markuslanthaler

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 25 Jul 2013 11:06:36 +0200

Hi Julian,

> The registry is a set of pointers to specs. Each status code needs to be 

I'm perfectly fine with this, I think that what is missing is just a
pointer at the place the reader would find it when looking at existing
status codes.

I would propose to amend the following sentence in 6.1 :

Like this :

   Note that this list is not exhaustive -- it does not include
   extension status codes defined in other specifications. The
   complete list of status codes is maintained by the IANA. See
   section 8.2 for details.

Would that be OK for you ?

Thanks,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Jul 2013 11:14:04 +0200

> Unfortunately, AFAIK, the URLs of those registries are not stable so I'm not sure how to reference it properly.

Well, they really really should be stable :-)

Best regards, Julian

---

From: "Markus Lanthaler" <[email-masked]>
Date: Thu, 25 Jul 2013 11:34:48 +0200

On Thursday, July 25, 2013 11:14 AM, Julian Reschke wrote:
> > Unfortunately, AFAIK, the URLs of those registries are not stable so
> I'm not sure how to reference it properly.
> > ...
> 

Well, then just include a link to http://www.iana.org/assignments/http-status-codes

--
Markus Lanthaler
@markuslanthaler

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Jul 2013 18:55:47 +0200

> Would that be OK for you ?

Si.

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2310>

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 25 Jul 2013 19:16:16 +0200

> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2310>

Thank you :-)

Willy