Re: [apps-discuss] Appdir Review of draft-ietf-httpbis-cice-01

[Pete Resnick <[e-mail]>]

On 1 Aug 2015, at 1:06, Julian Reschke wrote:

> 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?)

And if they read it on datatracker.ietf.org. Or if they use the 
rfc-editor.org info pages.

Eventually, I’d hope that this new RFC format work that’s being done 
leads to the ability to point to a particular section that has been 
updated, maybe even highlighting the appropriate section in the file if 
you view it in HTML format. But leaving a general marker now would be a 
nice thing.

>> 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.
>
> Agreed.

In this case, though, it is clear that this document wants to change 
base behavior. We no longer want it to be purely OPTIONAL to use 415; we 
want it to be a SHOULD, and used in a particular way.

The world doesn’t end either way, but I think “updates” is correct 
in this case.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]