Subject: [Speechsc] Finishing in Our Lifetime

From: "Burger, Eric" <[email-masked]>
Date: Tue, 18 Apr 2006 18:13:32 -0400

We are at an interesting time in the SPEECHSC work group.  The MRCPv2
spec has matured nicely and has been relatively stable for a while.  We
are starting to get real implementation experience, which has been
invaluable in pointing out holes or where we need clarifications in the
specification.

This does bring us to a cross-road.  Namely, we need to decide when we
are "done enough" for publication.

For review, I would urge folks not familiar with the IETF to review BCP
9, a.k.a. RFC 2026: <ftp://ftp.rfc-editor.org/in-notes/bcp/bcp9.txt>.
In particular, note that there are various levels of maturity in a
standards-track RFC.  They are (roughly):

Internet Draft:
Something people are thinking about; no weight as a standard.

Proposed Standard:
Something that looks like it just might work.  Let's try it and see how
it goes.

Draft Standard:
Something that is rather stable.  There is some real implementation
experience.  All of the normative references are at Draft Standard
level, and there are at least two pairs of independent (different source
code base), interoperating implementations of the protocol.

Internet Standard:
Well... There are all of 66 Internet Standards, compared to a couple of
hundred Proposed Standards.  I.e., an Internet Standard is pretty rare.

That said, we are really, really, really close to having MRCPv2 at a
Proposed Standard state.  Said differently, if you want to make a small
tweak, let's get what we have out there and we can address it when
MRCPv2 goes to Draft.

With this guideline in mind, the chairs have directed the editors to use
the following priorities for classifying and processing new requests.

Priority 1: Show Stopper
MRCPv2 will just not work without the change.  If the change is for a
corner case, the request can still hit Priority 1 if it would require a
major rework of the protocol in the future.

Priority 2: Clarifications and Editorial Comments
We will do our best to incorporate as much of this as we can.  The
rationale for allowing such changes is they hopefully make the
specification clearer so that interoperability is easier.  That said, do
be aware that we can publish errata (look at the RFC Editor web site),
so we are not "stuck" with "buggy" descriptions.

Priority 3: Missing features, methods, headers, etc.
We appear to be getting a few requests that are to make MRCPv2 support
full VoiceXML 2.1.  On the one hand, VoiceXML is a big consumer of
MRCPv2, so we want to make sure we address the market as best we can.
On the other hand, there are a bunch of existence proofs that MRCPv2 can
support VoiceXML browsers, in that there are a bunch of VoiceXML
browsers claiming support for MRCP, which is a less functional protocol
with known Priority 1 problems.  Things that fall into the Priority 3
category will most likely NOT make it into the Proposed version of
MRCPv2.  However, the intention is for people to start work immediately
on drafts to extend MRCPv2 with the needed functionality.  This allows
us to address the market and at the same time get MRCPv2 out the door.

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc