- From: Barry Leiba <barryleiba@computer.org>
- Date: Sat, 1 Aug 2015 03:59:11 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- 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>
>>>> If you are going to change the MAY to a SHOULD, I’m guessing this >>>> document would end up updating 7231. Again, I don’t suggest you do that. >>> >>> This spec already updates the entry for "Content-Encoding"; one could >>> argue we need to update the one for 415 as well. Feedback appreciated. >> >> Barry should weigh in on this, but here’s my take: IANA registries are >> not meant to impose protocol requirements; IANA registry entries are >> just meant to define code points. If there’s a requirement that the > > To define them, but also to have a way to find the current definition of > that protocol point. 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? 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. Barry
Received on Saturday, 1 August 2015 01:59:40 UTC