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

Re: Appdir Review of draft-ietf-httpbis-cice-01

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 1 Aug 2015 08:06:11 +0200
To: Barry Leiba <barryleiba@computer.org>
Cc: Pete Resnick <presnick@qti.qualcomm.com>, draft-ietf-httpbis-cice.all@ietf.org, IESG <iesg@ietf.org>, Apps Discuss <apps-discuss@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <55BC61D3.4060600@gmx.de>
On 2015-08-01 03:59, Barry Leiba wrote:
> ...
> Right.  The best way to handle this particular situation isn't to make
> this "update" 7231, but to add this to [RFC7231] in the reference
> field for status code 415 in the registry.
> On the other hand, let me probe Pete's point a bit:
> Someone reads 7231 and sees the definition for 415.  That someone
> doesn't read this, perhaps because she doesn't know about it.  She
> also doesn't look at the registry entry, and thus doesn't see the
> reference, because, after all, it's clear that 7231 defines 415, so
> why would one need to look at the registry entry for 415?
> ...

That is true. But would that person actually *find* the document 
updating RFC 7231 in the first place? It's not like we're changing the 
RFC 7231, we'd just be changing the RFC database.

(And yes, if the user would read 7231 through tools.ietf.com or 
greenbytes.de, that information would actually appear on the RFC; but 
how good does this scale once we have 10 documents "updating" 7231?)

> In a case such as that, "updates" could be useful.  I'm ambivalent
> about whether we should do that, though -- we are trying to avoid
> using "updates" for optional extensions.


Best regards, Julian
Received on Saturday, 1 August 2015 06:06:43 UTC

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