Subject: Issue 271 of 5987bis - Proposed Standard or Internet Standard?

From: Patrick McManus <[email-masked]>
Date: Thu, 12 Jan 2017 17:10:30 -0500

Gentlefolk of the HTTPbis WG -

I need to direct your attention to one of just two open issues with the
5987bis document (Indicating Character Encoding and Language for HTTP
Header Field Parameters), which deals with the intended status of the
eventual RFC. The consensus of the WG is sought.

https://github.com/httpwg/http-extensions/issues/271

The intended status of this document is currently listed as "Internet
Standard" ( https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc5987bis/
)

The other practical status for standards track documents is proposed
standard  - its laid out here https://www.ietf.org/rfc/rfc2026.txt and also
in https://www.rfc-editor.org/rfc/rfc6410.txt

The basic guidance is:

      An Internet Standard is characterized by a high degree of
      technical maturity and by a generally held belief that the
      specified protocol or service provides significant benefit to the
      Internet community.

A list of the ~100 active documents currently bearing STD status can be
found here https://www.rfc-editor.org/standards#IS

I apologize to Julian for not starting this thread earlier, I
procrastinated long enough that we got into the holiday season and then I
decided to defer until everyone's attention returned to work.
Thanks for your input.
-Patrick, chair-hat on

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jan 2017 14:18:30 +1300

On 13 January 2017 at 11:10, Patrick McManus <[email-masked]> wrote:
> 5987bis document (Indicating Character Encoding and Language for HTTP Header
> Field Parameters), which deals with the intended status of the eventual RFC.

Proposed Standard would seem to be sufficient.  I would think that
being MORE mature than HTTP would be unrealistic, so that limits us to
PS.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jan 2017 07:37:14 +0100

> being MORE mature than HTTP would be unrealistic, so that limits us to

I don't care a lot - it won't matter in practice.

That said, the standards process doesn't make this requirement. If we 
ever want to get spec to "full standard", adding *additional* hurdles 
doesn't seem to be the right approach.

(And yes, we should work on getting HTTP-the-base-specs to full standard 
as well)

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Jan 2017 12:29:23 +1100

Personal hat -

I'd prefer Proposed Standard; I don't think we want to overly promote the use of this encoding in new header fields, so calling it an Internet Standard sends the wrong message. 

In particular, if we do come up with a better solution, there will be that awkward phase (perhaps years) when this one will be full standard, and the "better" one will be only Proposed.

Finally, I don't think it meets the criteria in 2026.

I'm not lie-down-in-the-road against this (they're just words, after all); just a preference.

Cheers,

> On 13 Jan 2017, at 9:10 am, Patrick McManus <[email-masked]> wrote:
> 
> I need to direct your attention to one of just two open issues with the 5987bis document (Indicating Character Encoding and Language for HTTP Header Field Parameters), which deals with the intended status of the eventual RFC. The consensus of the WG is sought.
> 
> The intended status of this document is currently listed as "Internet Standard" ( https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc5987bis/ )
> 
> The other practical status for standards track documents is proposed standard  - its laid out here https://www.ietf.org/rfc/rfc2026.txt and also in https://www.rfc-editor.org/rfc/rfc6410.txt
> 
> The basic guidance is:
> 
> A list of the ~100 active documents currently bearing STD status can be found here https://www.rfc-editor.org/standards#IS
> I apologize to Julian for not starting this thread earlier, I procrastinated long enough that we got into the holiday season and then I decided to defer until everyone's attention returned to work.
> 
> Thanks for your input.
> -Patrick, chair-hat on

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

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 16 Jan 2017 12:33:46 +0900

> I'd prefer Proposed Standard; I don't think we want to overly promote the use of this encoding in new header fields, so calling it an Internet Standard sends the wrong message.

Fully agreed!

Also, Julian mentioned that it might be additional work to move it to 
full Standard, but if this is ever necessary, it can happen as part of 
moving HTTP 1.1 to full standard, with very little overhead.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jan 2017 07:46:46 +0100

On 2017-01-16 04:33, Martin J. Dürst wrote:
>> I'd prefer Proposed Standard; I don't think we want to overly promote
>> the use of this encoding in new header fields, so calling it an
>> Internet Standard sends the wrong message.
>
> Fully agreed!
>

No, I didn't (as far as I remember).

> moving HTTP 1.1 to full standard, with very little overhead.

That's an interesting proposal; however, I'd be very surprised if those 
who don't want it to be full standard would support integration into the 
next set of base specs.

Best regards, Julian

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 16 Jan 2017 16:43:01 +0900

> No, I didn't (as far as I remember).

Sorry, I interpreted the "*additional* hurdles" in your mail that way. 
On rereading, it looks like you meant to point more to the additional 
hurdle of "not being more mature than HTTP" than to the additional 
process-wise hurdle of moving from Proposed to Standard separately.

> who don't want it to be full standard would support integration into the

There are probably three sets of people: Those who wouldn't mind 
Standard now, those who don't think going to Standard now is a good 
idea, and those who might oppose going to Standard even if HTTP 1.1 
moves up. I guess we'll see when we get there.

Regards,   Martin.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 16 Jan 2017 21:33:22 -0500

> being MORE mature than HTTP would be unrealistic, so that limits us to

Indeed... and beyond "unrealistic", at least somewhat against IETF
process.  The document has 7230 and 7231 as normative references, so
they would qualify as "downrefs" if we should try for Internet
Standard.  We do have a process -- documented in RFC 3967 -- that
allows downrefs if they are called out explicitly in last call, but
that is mostly used for referencing informational documents for
terminology and such.  3967 is pretty clear that it should *not* be
used in lieu of moving the less-mature references up in maturity
first.

We should move the HTTP 1.1 set up to IS before we start trying to
make other HTTP-related standards IS.

Barry

---

From: Patrick McManus <[email-masked]>
Date: Tue, 31 Jan 2017 09:55:39 +0100

Thanks all for the thoughtful replies.  I believe we have consensus for
moving this document forward as a Proposed Standard. I will make the change
in datatracker and leave it to the editor to make the change in the draft.
-Patrick

On Tue, Jan 17, 2017 at 3:33 AM, Barry Leiba <[email-masked]>
wrote:

> Header

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Jan 2017 10:54:46 +0100

On 2017-01-31 09:55, Patrick McManus wrote:
> moving this document forward as a Proposed Standard. I will make the
> change in datatracker and leave it to the editor to make the change in
> the draft.
> -Patrick

FWIW, the draft (as published) doesn't contain the intended status, so 
no change is needed.

Best regards, Julian

PS: yes, the *source* of the draft does, but that's a 
rfc2629.xslt-specific extension element that is stripped before posting; 
now updated.