Subject: Re: Additional status codes in HTTP/1.1

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

Hi Markus,

On Thu, Jul 25, 2013 at 11:05:11AM +0200, Markus Lanthaler wrote:
> 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 ?
> [...]
> > >>
> > >> No, that would send the wrong message.
> > >>
> > >> The list in the spec is not exhaustive; there's an IANA registry for a
> > >> reason.
> > >
> > > But is there any good reason not to consolidate the codes that were
> > > known at the time?
> > 
> > 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.
> 
> 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.

There's already the pointer in section 8.2 which is dediated to this,
so I think it's better to just refer to this section from 6.1 so that
readers know that there are additional details.

Regards,
Willy

---

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

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

I would prefer to have a direct link. I see no need for another level of
indirection IMO.. adding a sentence like "for additional details, see
section 8.2" would of course be fine.

--
Markus Lanthaler
@markuslanthaler