Re: Moving 2817 to Historic

Ah, that rings a bell - thanks.

Cheers,


> On 14 Feb 2019, at 2:05 am, Michael Sweet <msweet@apple.com> wrote:
> 
> Mark,
> 
> HTTP Upgrade is used by IPP/1.1 [STD92] and IPP/2.0 [PWG Standard 5100.12] for opportunistic TLS and has been supported and used by CUPS for about 20 years.  I would NOT be in favor of marking it historic.
> 
> The problematic part of HTTP Upgrade has always been proxy support, which killed it for general web browser use but not for local network services.
> 
> 
>> On Feb 12, 2019, at 11:22 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> During BIS, we had an issue to move RFC2817 to Historic:
>> https://trac.ietf.org/trac/httpbis/ticket/254
>> which we incorporated text for in -16:
>> https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-16
>> 
>> However, later on we addressed an earlier issue that Paul raised to make sure we updated 2817:
>> https://trac.ietf.org/trac/httpbis/ticket/128
>> ... with the result that we moved from changing it to Historic to just Updating in -22:
>> https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22
>> 
>> AIUI the reason for that issue was to assure that the attribution for the HTTPS URI Scheme was properly noted; however, the registry already references 7230 for that purpose. CONNECT is now completely defined in 7230 (and thus core-messaging).
>> 
>> Is there any other reason to keep 2817 around? AIUI it isn't implemented by any browser, nor used anywhere, and isn't considered good practice any more. Am I forgetting something from that discussion?
>> 
>> From https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/ -- 
>> 
>>> A document is labelled Historic when what it describes is no longer considered current: no longer recommended for use. 
>> 
>> If people still agree that Historic is the appropriate status, we can create a status-change document to kick that process off.
>> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 13 February 2019 20:22:16 UTC