Re: [codec] A concrete proposal for requirements and testing

[Peter Saint-Andre <[e-mail]>]

:)

A: Because it messes up the order in which people normally read text.

Q: Why is top-posting so bad?

A: Top-posting.

Q: What is the most annoying behavior on email discussion lists?

On 4/7/11 12:49 PM, Stephen Botzko wrote:
> Early on there was consensus on the need for codec characterization.

(1) It's not clear to me that there is yet WG consensus about the need
for codec characterization. The topic is discussed in Section 3 of
draft-ietf-codec-guidelines-00 but the working group has not finalized
that document yet.

(2) Could you please explain what you mean by "codec characterization",
if it is different from what's in the guidelines document?

> I see no reason to have that discussion again, I suggest it would be
> better to get back on track and work through what a sensible test plan
> would include.

Although I think complete characterization and detailed testing might be
helpful at some point, I think the right time to do that is after the
RFC is published. This is completely consistent with how we test any
other specification we publish. At least within the Internet Standards
Process, I see no reason to set the bar higher on the specification of a
codec than on the specification of a protocol like SIP or XMPP or whatever.

Please see Section 4.1.1. of RFC 2026, which describes the expected
characteristics of specifications at the level of Proposed Standard
within the Internet Standards Process. The text, in full, is:

###

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.  However, the IESG may
   waive this requirement in order to allow a specification to advance
   to the Proposed Standard state when it is considered to be useful and
   necessary (and timely) even with known technical omissions.

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/