Media Resource Control Protocol Version 2 (MRCPv2)
draft-ietf-speechsc-mrcpv2-28

[Ballot comment]
Thanks for addressing the essential issues. I'll leave the remaining stuff here for the record.

I agree with Stephen (and likely everyone else) that this document is abominably long. It could have reasonably been broken up into multiple documents, which would have made readability much better. I have a sneaking suspicion that it will be impossible to implement a completely independent interoperable implementation just from this spec. I also have a sneaking suspicion that this will never advance beyond Proposed Standard. I understand that this document suffers from being the result of a long process, but incremental publication and experience (instead of dumping everything into a grand unified document the first time out of the gate) would have made for better output. Still, I'm not willing to stop the document at this point. The work seems important, and you need a record of what everyone is doing.

Section 9.6.3.4: It's too bad that you are using ISO 8601 instead of RFC 3339. A more limited set would be better.

ABNF. Overall, you should re-use elements whenever possible from other canonical texts if you can avoid re-inventing them for yourself. So:

Why use UTF8-NONASCII instead of the productions in RFC 3629 (UTF8-2 / UTF8-3 / UTF8-4)?

Is there nowhere to pull the URI definition from? Re-creating ABNF for this stuff seems fraught.

quoted-string doesn't seem to be needed in completion-reason; *UTFCHAR could have worked.

[Ballot comment]
Updated 2011-12-12

After reading the thread at http://www.ietf.org/mail-archive/web/gen-art/current/msg06865.html,
I cleared my Discuss.

Others have raised issues with the ABNF, so I have removed
my Comment.

Minor editorial suggestion: the term "channel identifier" is first
used in section 3, constrained there to be "unambiguous", then defined
(twice) in section 4 and referenced again (along with the
"unambiguous" contraint) in section 6.  For clarity, I suggest giving
the definition once, preferable at first use of the term.

Even more minor editorial suggestion: the term "CRLF" is used several
times and then finally defined in section 6.2.11.  Might be better to
define at the first use of the term.

[Ballot comment]
The Abstract and then section 4.1 mention that MRCP 

> relies on other protocols, such as
  Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and
  servers and manage sessions between them, and the Session Description
  Protocol (SDP) to describe, discover and exchange capabilities

But then the rest of the document only describes the interaction of MRCPv2 with SIP and SDP. My question is whether the 'such as' is really justified or should be just dropped from the two places.

[Ballot discuss]
1. There is no indication whatsoever in the document about how this protocol is managed. I do not know to what extent MRCPv1 was deployed, but assuming it was there should be some operational experience about the operational model, how performance is measured, how problems are detected and signalled to the operators and debugged. This needs not necessarily be part of the same document (this one is already one of the largest we have reviewed in the IESG in the last few years), but I would like to have some clarity and information about these issues, and understand if these will be dealt with maybe in future work before I can approve the document.

2. In the Introduction section:

> MRCPv2 is based on the
  earlier Media Resource Control Protocol (MRCP) [RFC4463]

Should not this document update RFC 4463? Would not a log of changes between MRCPv2 and MRCP be useful? Are there any backwards compatibility or migration issues that need to be taken into consideration by operators?

[Ballot discuss]
I'm trying to extract the ABNF and compile it, but I'm getting errors and at least some of them seem like real errors. I did have to do some hand-editing to make the extract work, though.

Here are some of the errors that I'm getting:

stdin(140:0): error: Rule set-cookie was already defined on line 128 of stdin
128:

stdin(614:0): warning: rule Abort-verification previously referred to as abort-verification

stdin(288:0): error: Rule positive-speech-length was already defined on line 214 of stdin
214:

Ask me for the input file and the full errors list if you need it. But I do think that the document's ABNF should compile cleanly before we can approve it. Of course, I could have missed something when I did my hand-editing.

Finally, there are no errors if I parse the appendix that has the ABNF but there are errors if I parse the extracted ABNF. And there seems to be real differences, such as duplication of rules between many sections. E.g., 8.4.1 and 8.4.15 both define positive-speech-length. Please demonstrate that the two sets of ABNF are equivalent.

[Ballot comment]
I agree with Stephen (and likely everyone else) that this document is abominably long. It could have reasonably been broken up into multiple documents, which would have made readability much better. I have a sneaking suspicion that it will be impossible to implement a completely independent interoperable implementation just from this spec. I also have a sneaking suspicion that this will never advance beyond Proposed Standard. I understand that this document suffers from being the result of a long process, but incremental publication and experience (instead of dumping everything into a grand unified document the first time out of the gate) would have made for better output. Still, I'm not willing to stop the document at this point. The work seems important, and you need a record of what everyone is doing.

One question off the top:

Shouldn't this document be obsoleting RFC 4463?

So, on to some actionable fixes:

Section 4.2:

  If the client specifies a value of "existing", the server MUST respond
  with a value of "existing" if it prefers to share an existing
  connection or with a value of "new" if not.
 
That should be a MAY, not a MUST: "If the client specifies a value of "existing", the server MAY respond with a value of "existing" if it prefers to share an existing connection or with a value of "new" if not."

Section 4.4:

  An MRCPv2 implementation MUST either multiplex or mix unless
  it cannot correctly do either, in which case the server MUST disallow
  the client from associating multiple such resources to a single audio
  stream by rejecting the SDP offer with a SIP 488 "Not Acceptable"
  error.
 
The first MUST is superfluous. Instead: "If an MRCPv2 implementation neither multiplexes nor mixes, it MUST disallow the client..."
 
  Note that there is a large installed base that will return a
  SIP 501 "Not Implemented" error in this case.  To facilitate
  interoperability with this installed base, new implementations SHOULD
  consider adding configuration to treat a 501 in this context as a 488
  when it is received from an element known to be a legacy
  implementation.

s/SHOULD consider adding configuration to/SHOULD

"Considering" is not something that gets 2119 language. Treating a particular SIP error in a particular way is.


Section 5:

  However, to assist in compact representations,
  MRCPv2 also allows message bodies to be represented in other
  character sets such as ISO 8859-1 [ISO.8859-1.1987].  This may be
  useful for languages such as Chinese where the default character set
  for most documents is not UTF-8.

No reason to cite 8859-1 since that's not what Chinese would use. If you want to site BIG5 or another character set used for Chinese as an example, that might make sense. But I suspect that UTF-8 is probably used by most of these languages now and, given the compressibility, this is no longer really needed. If it needs to be here for backward compatibility, so be it, but I don't think you can really defend the need for other than UTF-8 at this point for any other reason.

Some questions:

Section 9.6.3.4: Do you really need ISO 8601, or can you use RFC 3339 instead? A more limited set would be better.

ABNF. Overall, you should re-use elements whenever possible from other canonical texts if you can avoid re-inventing them for yourself. So:

Why did you create LWS instead of using the RFC 5234 LWSP? They're identical.

Why use UTF8-NONASCII instead of the productions in RFC 3629 (UTF8-2 / UTF8-3 / UTF8-4)?

Is there nowhere to pull the URI definition from? Re-creating ABNF for this stuff seems fraught.

Other issues:

Why is weight-value needed? It's not reused and FLOAT could go in its place.

Why is quoted-string needed in completion-reason? Why not just *UTFCHAR?

[Ballot comment]
I agree with Stephen (and likely everyone else) that this document is abominably long. It could have reasonably been broken up into multiple documents, which would have made readability much better. I have a sneaking suspicion that it will be impossible to implement a completely independent interoperable implementation just from this spec. I also have a sneaking suspicion that this will never advance beyond Proposed Standard. I understand that this document suffers from being the result of a long process, but incremental publication and experience (instead of dumping everything into a grand unified document the first time out of the gate) would have made for better output. Still, I'm not willing to stop the document at this point. The work seems important, and you need a record of what everyone is doing.

So, some actionable fixes:

Section 4.2:

  If the client specifies a value of "existing", the server MUST respond
  with a value of "existing" if it prefers to share an existing
  connection or with a value of "new" if not.
 
That should be a MAY, not a MUST: "If the client specifies a value of "existing", the server MAY respond with a value of "existing" if it prefers to share an existing connection or with a value of "new" if not."

Section 4.4:

  An MRCPv2 implementation MUST either multiplex or mix unless
  it cannot correctly do either, in which case the server MUST disallow
  the client from associating multiple such resources to a single audio
  stream by rejecting the SDP offer with a SIP 488 "Not Acceptable"
  error.
 
The first MUST is superfluous. Instead: "If an MRCPv2 implementation neither multiplexes nor mixes, it MUST disallow the client..."
 
  Note that there is a large installed base that will return a
  SIP 501 "Not Implemented" error in this case.  To facilitate
  interoperability with this installed base, new implementations SHOULD
  consider adding configuration to treat a 501 in this context as a 488
  when it is received from an element known to be a legacy
  implementation.

s/SHOULD consider adding configuration to/SHOULD

"Considering" is not something that gets 2119 language. Treating a particular SIP error in a particular way is.


Section 5:

  However, to assist in compact representations,
  MRCPv2 also allows message bodies to be represented in other
  character sets such as ISO 8859-1 [ISO.8859-1.1987].  This may be
  useful for languages such as Chinese where the default character set
  for most documents is not UTF-8.

No reason to cite 8859-1 since that's not what Chinese would use. If you want to site BIG5 or another character set used for Chinese as an example, that might make sense. But I suspect that UTF-8 is probably used by most of these languages now and, given the compressibility, this is no longer really needed. If it needs to be here for backward compatibility, so be it, but I don't think you can really defend the need for other than UTF-8 at this point for any other reason.

Some questions:

Section 9.6.3.4: Do you really need ISO 8601, or can you use RFC 3339 instead? A more limited set would be better.

ABNF. Overall, you should re-use elements whenever possible from other canonical texts if you can avoid re-inventing them for yourself. So:

Why did you create LWS instead of using the RFC 5234 LWSP? They're identical.

Why use UTF8-NONASCII instead of the productions in RFC 3629 (UTF8-2 / UTF8-3 / UTF8-4)?

Is there nowhere to pull the URI definition from? Re-creating ABNF for this stuff seems fraught.

Other issues:

Why is weight-value needed? It's not reused and FLOAT could go in its place.

Why is quoted-string needed in completion-reason? Why not just *UTFCHAR?

[Ballot discuss]
Section 5:

  MRCPv2 messages are textual using the ISO 10646 character set in the
  UTF-8 encoding (RFC3629 [RFC3629]) to allow many different languages
  to be represented.

This sentence does not appear to be true, given that later you refer to message bodies containing binary data made up of octets. I am left to wonder what this is supposed to mean.

  The MRCPv2 protocol headers (the
  first line of an MRCP message) and header field names use only the
  US-ASCII subset of UTF-8.  Internationalization only applies to
  certain fields like grammar, results, speech markup etc, and not to
  MRCPv2 as a whole.

The first sentence is probably OK, but I have no idea what the second sentence means. I suspect you're talking about *localization*, not *internationalization* (for example, that header fields names and contents are not subject to localization because they are protocol elements), but to be honest, I'm not really sure. Something is wrong in those two sentences.

Please see if you can straighten this out.

[Ballot comment]
#1) I support Stephen's discusses.

#2) s1, s4, s.4.3, s4.3, and s4.5: It's interesting that s1 says that mapping to SCTP isn't covered in this document but through there's still statements about SCTP:

s4: MRCPv2 requires a connection-oriented transport layer protocol
    such as TCP or SCTP to ...

s4.2: (The usage of SCTP with
  MRCPv2 may be addressed in a future specification).

s4.2: The server MUST NOT close the TCP, SCTP or
      TLS connection if it is currently being
      shared among multiple MRCP
      channels.

s4.3: The MRCPv2 messages defined in this document
      are transported over a
      TCP, TLS or SCTP (in the future)

s4.5: Multiple resource control channels between a client and
  a server that belong to different SIP dialogs can share one or more
  TLS, TCP or SCTP connections between them; the server and client MUST
  support this mode of operation.

The statements in s4.2 and s4.5 are made with normative requirements so is this document really not saying anything about SCTP?  It's probably best to just remove all references to SCTP after s1.

#3) s3: Not trying to be to penny ante here but should the architecture diagram also include TLS?

#4) s3.2: Always trying to promote security in examples maybe add:

  sips:mrcpv2@example.net

#5) s4.2 and 6.2.1: Along the same lines as Stephen's discuss: I was expecting this section to say how the channel identifier is made unambiguous.

#6) s4.5: Clients and servers MUST use the
  MRCPv2 channel identifier, carried in the Channel-Identifier header
  field in individual MRCPv2 messages, to differentiate MRCPv2 messages
  from different resource channels (see Section 6.2.1 for details).

#7) s5.3: otherwise, it must … otherwise it MUST ?

#8) s8.13: The request-state field must have … The request-state field MUST have?

#9) s9.4.26: is this

  recognition-mode        =  "Recognition-Mode" ":"
                              normal-value / hotword-value CRLF
  normal-value            =  "normal"
  hotword-value            =  "hotword"

the same as:

  recognition-mode        =  "Recognition-Mode" ":"
                              "normal" / "hotword" CRLF

normal-value and hotword-value aren't used anywhere else.

#10) s9.4.6, 9.4.7, 9.4.8, 9.4.15, 9.4.16, 9.4.17, 9.4.18, 9.4.28, 9.4.29: Similar question to Stephen's about positive-speech-length.

#11) s10.4.7:  Contains:

  Implementations MUST support 'http', 'https' [RFC2616], 'file'
  [RFC3986], and 'cid' [RFC2392] schemes in the URI.  Note that
  implementations already exist that support other schemes.

I think it's supposed to be:

  Implementations MUST support 'http' [RFC2616], 'https' [RFC2818], 'file'
  [RFC3986], and 'cid' [RFC2392] schemes in the URI.  Note that
  implementations already exist that support other schemes.

Also, in lots of other places it just says support for http and https and now file and cid get thrown in.  Is this consistent throughout the draft?

#2^19) Tell me you haven't hidden the meaning of life in this document or an offer for free beer and I missed it ;)

[Ballot discuss]
This ought to be easy enough to address:

s6.2.15: What is the "Age" attribute used for?  It's not clear to me what it's supposed to indicate.

[Ballot discuss]
IANA has questions about the XML ns and schema registrations requested
by draft-ietf-speechsc-mrcpv2-27.txt.

QUESTION: the URIs for the ns and schema registrations are listed as
"http://www.ietf.org/xml/schema/nlsml" and
"http://www.ietf.org/xml/ns/mrcpv2". Is this correct? Aside from the
fact that those links don't work, every other ns and schema registration
has a URI in the form "urn:ietf:params:xml:schema:example" and
"urn:ietf:params:xml:ns:example". See
http://www.iana.org/assignments/xml-registry-index.html

IANA has questions about the XML ns and schema registrations requested
by draft-ietf-speechsc-mrcpv2-27.txt.

QUESTION: the URIs for the ns and schema registrations are listed as
"http://www.ietf.org/xml/schema/nlsml" and
"http://www.ietf.org/xml/ns/mrcpv2". Is this correct? Aside from the
fact that those links don't work, every other ns and schema registration
has a URI in the form "urn:ietf:params:xml:schema:example" and
"urn:ietf:params:xml:ns:example". See
http://www.iana.org/assignments/xml-registry-index.html

Upon approval of this document, IANA will perform the following actions:

ACTION 1:

In the new page created for MRCPv2, IANA will create a new
registry called "MRCPv2 resource types." The registration procedure is
"Standards Action." Initial registrations:

Resource type Resource description Reference
------------- -------------------- ---------
speechrecog Speech Recognizer [RFC-to-be]
dtmfrecog DTMF Recognizer [RFC-to-be]
speechsynth Speech Synthesizer [RFC-to-be]
basicsynth Basic Synthesizer [RFC-to-be]
speakverify Speaker Verifier [RFC-to-be]
recorder Speech Recorder [RFC-to-be]


ACTION 2:

IANA will create the following registry:

Name: MRCPv2 methods and events
Registration Procedure: Standards Action

Name Resource type Method/Event Reference
---- ------------- ------------ ---------
SET-PARAMS Generic Method [RFCXXXX]
GET-PARAMS Generic Method [RFCXXXX]
SPEAK Synthesizer Method [RFCXXXX]
STOP Synthesizer Method [RFCXXXX]
PAUSE Synthesizer Method [RFCXXXX]
RESUME Synthesizer Method [RFCXXXX]
BARGE-IN-OCCURRED Synthesizer Method [RFCXXXX]
CONTROL Synthesizer Method [RFCXXXX]
DEFINE-LEXICON Synthesizer Method [RFCXXXX]
DEFINE-GRAMMAR Recognizer Method [RFCXXXX]
RECOGNIZE Recognizer Method [RFCXXXX]
INTERPRET Recognizer Method [RFCXXXX]
GET-RESULT Recognizer Method [RFCXXXX]
START-INPUT-TIMERS Recognizer Method [RFCXXXX]
STOP Recognizer Method [RFCXXXX]
START-PHRASE-ENROLLMENT Recognizer Method [RFCXXXX]
ENROLLMENT-ROLLBACK Recognizer Method [RFCXXXX]
END-PHRASE-ENROLLMENT Recognizer Method [RFCXXXX]
MODIFY-PHRASE Recognizer Method [RFCXXXX]
DELETE-PHRASE Recognizer Method [RFCXXXX]
RECORD Recorder Method [RFCXXXX]
STOP Recorder Method [RFCXXXX]
START-INPUT-TIMERS Recorder Method [RFCXXXX]
START-SESSION Verifier Method [RFCXXXX]
END-SESSION Verifier Method [RFCXXXX]
QUERY-VOICEPRINT Verifier Method [RFCXXXX]
DELETE-VOICEPRINT Verifier Method [RFCXXXX]
VERIFY Verifier Method [RFCXXXX]
VERIFY-FROM-BUFFER Verifier Method [RFCXXXX]
VERIFY-ROLLBACK Verifier Method [RFCXXXX]
STOP Verifier Method [RFCXXXX]
START-INPUT-TIMERS Verifier Method [RFCXXXX]
GET-INTERMEDIATE-RESULT Verifier Method [RFCXXXX]
SPEECH-MARKER Synthesizer Event [RFCXXXX]
SPEAK-COMPLETE Synthesizer Event [RFCXXXX]
START-OF-INPUT Recognizer Event [RFCXXXX]
RECOGNITION-COMPLETE Recognizer Event [RFCXXXX]
INTERPRETATION-COMPLETE Recognizer Event [RFCXXXX]
START-OF-INPUT Recorder Event [RFCXXXX]
RECORD-COMPLETE Recorder Event [RFCXXXX]
VERIFICATION-COMPLETE Verifier Event [RFCXXXX]
START-OF-INPUT Verifier Event [RFCXXXX]


ACTION 3:

IANA will create the following registry:

Name: MRCPv2 header fields
Registration Procedure: Standards Action

Name Resource type Reference
---- ------------- ---------
Channel-Identifier Generic [RFCXXXX]
Accept Generic [RFC2616]
Active-Request-Id-List Generic [RFCXXXX]
Proxy-Sync-Id Generic [RFCXXXX]
Accept-Charset Generic [RFC2616]
Content-Type Generic [RFCXXXX]
Content-ID Generic [RFC2392, RFC2046, and RFC5322]
Content-Base Generic [RFCXXXX]
Content-Encoding Generic [RFCXXXX]
Content-Location Generic [RFCXXXX]
Content-Length Generic [RFCXXXX]
Fetch-Timeout Generic [RFCXXXX]
Cache-Control Generic [RFCXXXX]
Logging-Tag Generic [RFCXXXX]
Set-Cookie Generic [RFCXXXX]
Vendor-Specific Generic [RFCXXXX]
Jump-Size Synthesizer [RFCXXXX]
Kill-On-Barge-In Synthesizer [RFCXXXX]
Speaker-Profile Synthesizer [RFCXXXX]
Completion-Cause Synthesizer [RFCXXXX]
Completion-Reason Synthesizer [RFCXXXX]
Voice-Parameter Synthesizer [RFCXXXX]
Prosody-Parameter Synthesizer [RFCXXXX]
Speech-Marker Synthesizer [RFCXXXX]
Speech-Language Synthesizer [RFCXXXX]
Fetch-Hint Synthesizer [RFCXXXX]
Audio-Fetch-Hint Synthesizer [RFCXXXX]
Failed-URI Synthesizer [RFCXXXX]
Failed-URI-Cause Synthesizer [RFCXXXX]
Speak-Restart Synthesizer [RFCXXXX]
Speak-Length Synthesizer [RFCXXXX]
Load-Lexicon Synthesizer [RFCXXXX]
Lexicon-Search-Order Synthesizer [RFCXXXX]
Confidence-Threshold Recognizer [RFCXXXX]
Sensitivity-Level Recognizer [RFCXXXX]
Speed-Vs-Accuracy Recognizer [RFCXXXX]
N-Best-List-Length Recognizer [RFCXXXX]
Input-Type Recognizer [RFCXXXX]
No-Input-Timeout Recognizer [RFCXXXX]
Recognition-Timeout Recognizer [RFCXXXX]
Waveform-URI Recognizer [RFCXXXX]
Input-Waveform-URI Recognizer [RFCXXXX]
Completion-Cause Recognizer [RFCXXXX]
Completion-Reason Recognizer [RFCXXXX]
Recognizer-Context-Block Recognizer [RFCXXXX]
Start-Input-Timers Recognizer [RFCXXXX]
Speech-Complete-Timeout Recognizer [RFCXXXX]
Speech-Incomplete-Timeout Recognizer [RFCXXXX]
Dtmf-Interdigit-Timeout Recognizer [RFCXXXX]
Dtmf-Term-Timeout Recognizer [RFCXXXX]
Dtmf-Term-Char Recognizer [RFCXXXX]
Failed-URI Recognizer [RFCXXXX]
Failed-URI-Cause Recognizer [RFCXXXX]
Save-Waveform Recognizer [RFCXXXX]
Media-Type Recognizer [RFCXXXX]
New-Audio-Channel Recognizer [RFCXXXX]
Speech-Language Recognizer [RFCXXXX]
Ver-Buffer-Utterance Recognizer [RFCXXXX]
Recognition-Mode Recognizer [RFCXXXX]
Cancel-If-Queue Recognizer [RFCXXXX]
Hotword-Max-Duration Recognizer [RFCXXXX]
Hotword-Min-Duration Recognizer [RFCXXXX]
Interpret-Text Recognizer [RFCXXXX]
Dtmf-Buffer-Time Recognizer [RFCXXXX]
Clear-Dtmf-Buffer Recognizer [RFCXXXX]
Early-No-Match Recognizer [RFCXXXX]
Num-Min-Consistent-Pronunciations Recognizer [RFCXXXX]
Consistency-Threshold Recognizer [RFCXXXX]
Clash-Threshold Recognizer [RFCXXXX]
Personal-Grammar-URI Recognizer [RFCXXXX]
Enroll-Utterance Recognizer [RFCXXXX]
Phrase-ID Recognizer [RFCXXXX]
Phrase-NL Recognizer [RFCXXXX]
Weight Recognizer [RFCXXXX]
Save-Best-Waveform Recognizer [RFCXXXX]
New-Phrase-ID Recognizer [RFCXXXX]
Confusable-Phrases-URI Recognizer [RFCXXXX]
Abort-Phrase-Enrollment Recognizer [RFCXXXX]
Sensitivity-Level Recorder [RFCXXXX]
No-Input-Timeout Recorder [RFCXXXX]
Completion-Cause Recorder [RFCXXXX]
Completion-Reason Recorder [RFCXXXX]
Failed-URI Recorder [RFCXXXX]
Failed-URI-Cause Recorder [RFCXXXX]
Record-URI Recorder [RFCXXXX]
Media-Type Recorder [RFCXXXX]
Max-Time Recorder [RFCXXXX]
Trim-Length Recorder [RFCXXXX]
Final-Silence Recorder [RFCXXXX]
Capture-On-Speech Recorder [RFCXXXX]
Ver-Buffer-Utterance Recorder [RFCXXXX]
Start-Input-Timers Recorder [RFCXXXX]
New-Audio-Channel Recorder [RFCXXXX]
Repository-URI Verifier [RFCXXXX]
Voiceprint-Identifier Verifier [RFCXXXX]
Verification-Mode Verifier [RFCXXXX]
Adapt-Model Verifier [RFCXXXX]
Abort-Model Verifier [RFCXXXX]
Min-Verification-Score Verifier [RFCXXXX]
Num-Min-Verification-Phrases Verifier [RFCXXXX]
Num-Max-Verification-Phrases Verifier [RFCXXXX]
No-Input-Timeout Verifier [RFCXXXX]
Save-Waveform Verifier [RFCXXXX]
Media-Type Verifier [RFCXXXX]
Waveform-URI Verifier [RFCXXXX]
Voiceprint-Exists Verifier [RFCXXXX]
Ver-Buffer-Utterance Verifier [RFCXXXX]
Input-Waveform-URI Verifier [RFCXXXX]
Completion-Cause Verifier [RFCXXXX]
Completion-Reason Verifier [RFCXXXX]
Speech-Complete-Timeout Verifier [RFCXXXX]
New-Audio-Channel Verifier [RFCXXXX]
Abort-Verification Verifier [RFCXXXX]
Start-Input-Timers Verifier [RFCXXXX]
Input-Type Verifier [RFCXXXX]


ACTION 4:

IANA will create the following registry:

Name: MRCPv2 status codes
Registration Procedure: Specification Required

show quoted text
+------------+--------------------------------------------------+
show quoted text


ACTION 5:

IANA will create the following registry:

Name: Grammar Reference List Parameters
Registration Procedure: Specification Required

Name Reference
---- -------------
weight [RFCXXXX]


ACTION 6:

IANA will create the following registry with no initial contents:

Name: MRCPv2 vendor-specific parameters
Registration Procedure: First Come First Served


ACTION 7:

IANA will register the following Application media type at
http://www.iana.org/assignments/media-types/application/index.html

nlsml+xml [RFC-to-be]


ACTION 8:

IANA will register nlsml in the IETF XML schema registry at
http://www.iana.org/assignments/xml-registry/schema.html. However, we
believe the URI should actually be urn:ietf:params:xml:schema:nlsml.
Please let us know.


ACTION 9:

IANA will register mrcpv2 in the IETF XML schema registry at
http://www.iana.org/assignments/xml-registry/schema.html. However, we
believe the URI should actually be urn:ietf:params:xml:ns:mrcpv2. Please
let us know.


ACTION 10:

IANA will register the following Text media type at
http://www.iana.org/assignments/media-types/text/index.html

grammar-ref-list [RFC-to-be]


ACTION 11:

IANA will register the following permanent URI scheme at
http://www.iana.org/assignments/uri-schemes.html

URI Scheme: session
Description: MRCPv2
Reference: [RFC-to-be]


ACTION 12:

IANA will register the following in the SDP proto registry at
http://www.iana.org/assignments/sdp-parameters

TCP/MRCPv2 [RFC-to-be]
TCP/TLS/MRCPv2 [RFC-to-be]


ACTION 13:

IANA will register the following in the att-field (media-level) registry at
http://www.iana.org/assignments/sdp-parameters

resource [RFC-to-be]
channel [RFC-to-be]
cmid [RFC-to-be]

[Ballot comment]
Editorial suggestion: I haven't checked the ABNF snippets in the body
of the document against the ABNF Normative Definition in section 15.
If it's important to include the ABNF snippets in the body of the
document, in my opinion it would be prudent to add a sentence to
section 15 explicitly identifying the ABNF Normative Definition as
definitive (and, as labeled, normative) relative to the snippets in
the body of the document.

Minor editorial suggestion: the term "channel identifier" is first
used in section 3, constrained there to be "unambiguous", then defined
(twice) in section 4 and referenced again (along with the
"unambiguous" contraint) in section 6.  For clarity, I suggest giving
the definition once, preferable at first use of the term.

Even more minor editorial suggestion: the term "CRLF" is used several
times and then finally defined in section 6.2.11.  Might be better to
define at the first use of the term.

[Ballot discuss]
I have one Discuss issue that should be easy to resolve.  I have a
concern that the name of the "vendor-specific parameters" is somewhat
misleading, and the purpose and details of the "MRCPv2 vendor-specific
parameters" registry are not well-defined.  However, I need to get
some clarification before I can make my Discuss actionable.

As I understand the syntax of "vendor-specific parameters", such a
parameter is identified by a Domain Name (in reverse order), followed
by the name of the parameter.

I also understand the registration policy for the "MRCPv2
vendor-specific parameters" to be FCFS, with a recommendation that the
"assignment requests adhere to the existing allocations of Internet
domain names to organizations, institutions, corporations, etc."

Do I have it right that there is no attempt to determine if the
submitter of a request has authority to add a registration to the
registry under a given Domain Name?  E.g., Alice, an employee of
organization A, could submit a request to register com.b.new-parameter
and there would be no checking that Alice has authority to register
com.b.new-parameter.

I don't see any description of the value types, ranges or semantics
associated with the registered vendor-specific options.  Is it the
intention of the registry to list the known vendor-specific parameters
without any additional information?

[Ballot comment]
- This is abominably long;-)

- p9, "based on" MRCP is a bit vague, be nice to know what kinds
of change was planned, done etc. and what kinds of
(in)compatibilities exist between this and that.

- p9, "break the RTSP protocol" seems a bit dramatic, some details
would be better, but maybe being coy is the best that can be done
without opening cans of worms.

- p15, ist sentence of 4.1 is odd, "such as SIP" is supposed to
mean what exactly? Is there an alternative?

- p17, (last para, and p24 last para) isn't it just a
conflict to say servers MUST support TLS, but yet servers MAY not
support TLS? You can't have it both ways. I think maybe
s/support/use/ might fix it, i.e. saying "MAY use TCP without
TLS in controlled environments."

- p23, (and elsewhere) wheere are "recvonly" etc. defined? Don't
you need a reference or to defined those?

- p26, what does "This field MAY be printed..." mean? Printed?

- p40, can the fetch-timeout be handed to a server by a client? If
so, could it be the basis for a DoS on the server? If so, then that
should be noted in the security considerations and (given the
length of the document) also in 6.2.12.

- p41, as for p40 - can client's cause servers to cache stuff for
long periods as a DoS attempt?

- p169, saying you SHOULD "employ" TLS seems to imply that TLS
is mandatory to implement. It'd be good to be explicit about
that.

- p169/170, says "If appropriate...SRTP...is RECOMMENDED" When
is SRTP "appropriate"? If its not appropriate, then what else
can be done?

[Ballot discuss]
A few things to check and maybe tweak but actually the security
considerations and references already do a pretty good job for
such a big spec.

#1, p12, What is an "unambiguous channel identifier"?  Security
questions might revolve around collision probabilities etc.  This
intro section seems to assume that its ok if the server allocates
separate ids, but bad clients might guess others' ids.  Clarifying
"unambiguous" would probably fix this if you said that those ids
also need to be hard to guess.

#2, p42, What do you mean by "identifying information" in 6.2.14?
If its *personally* identifying information (PII) such as a user's
name or (possibly) IP address then the RECOMMENDATION may be wrong.
If not PII then what's meant here? If you just meant identifying
the client UA or something that'd probably be fine but it'd be better
to be clear about that.

#3, p42, What set of client cookies MUST be sent to the server? I'm
just checking that its not supposed to be a browser's full set of
cookies.

#4, p57, Can I really ask a server to say something for 10^19
seconds? "Say Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhh..." for
115740740740740 days seems like a fine DoS to me. Suggest you
RECOMMEND some sanity checking of input on that or maybe I'm
reading it wrong? (Would the same apply to any of the other
constructs with 19DIGIT in their abnf?)

#5, p94 and elsewhere, all messages that contain URLs that the other
party might de-reference SHOULD come with a health warning - they
can be abused in various ways. 12.4 doesn't really cover that and
would seem like a fine place to warn about blindly following URLs.
Can't think of an RFC with good text for that right now, but I'd
say there might be one if you poke about.

#6, p140, speaker verification - have none of the caveats for when
its considered safe to use this changed since 2005? (When RFC 4313
was published.) That seems a bit unlikely. Has someone looked to
see what's the current state of the art wrt cheating on systems
like this?

#7,p160, surely the DELETE-VOICEPRINT method and others imply a
need for authorization. Where's that covered? I didn't see it in
section 12. Am I missing something?

#8, p170 says that one-time URIs might be useful. I think that
needs to say that if used, it MUST be infeasible to guess them.
Should be a simple enough change.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard


The IESG has received a request from the Speech Services Control WG
(speechsc) to consider the following document:
- 'Media Resource Control Protocol Version 2 (MRCPv2)'
  as a Proposed Standard

This is a second IETF LC to verify the changes to the policy used
for the vendor-specific parameters IANA registry, and the use of the
set-cookie headers made in response to earlier last call comments
and external review, and to verify the current normative
reference (downref) to RFC 2483, an Experimental RFC.

From the shepherd report:
All normative references are standards track RFCs except for nominal
DOWNREF is to RFC 2483; that reference is to the text/uri-list definition.
MRCPv2 uses the same definition of text/uri-list as found in the IANA
media types registry. We could make this reference Informative or be
silent on the reference, as the MRCPv2 reference is to the IANA registry.
However, the work group believes it to be useful to have a pointer to the
definition of text/uri-list for implementers to follow.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The MRCPv2 protocol allows client hosts to control media service
  resources such as speech synthesizers, recognizers, verifiers and
  identifiers residing in servers on the network.  MRCPv2 is not a
  "stand-alone" protocol - it relies on other protocols, such as
  Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and
  servers and manage sessions between them, and the Session Description
  Protocol (SDP) to describe, discover and exchange capabilities.  It
  also depends on SIP and SDP to establish the media sessions and
  associated parameters between the media source or sink and the media
  server.  Once this is done, the MRCPv2 protocol exchange operates
  over the control session established above, allowing the client to
  control the media processing resources on the speech resource server.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/


No IPR declarations have been submitted directly on this I-D.

UPDATED SHEPHERD WRITEUP:

Document:
Media Resource Control Protocol Version 2 (MRCPv2)
draft-ietf-speechsc-mrcpv2-26
(Standards Track)

(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Eric Burger is the document shepherd. I have personally reviewed this version of the document. This document is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had reviews by key WG members, as well as expert review from MMUSIC (Magnus Westerlund), GENART (Vijay Gurbani, Miguel Garcia), applications (Ted Hardie, Peter St. Andre, and Larry Massinter), RAI (Paul Kyzivat), and AVT (Roni Evan), areas.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

Reviews listed above, as well as IANA, URL, and MIME types review. The document incorporates and addresses all suggestions from Peter, Vijay, Miguel, Ted, Paul, and other IESG members, as well as expert review and comments incorporated from Roni Evan. We took most of the comments from Larry, but some where philosophical and deemed out of scope.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The largest concern the Document Shepherd has is the ITU-T is waiting on the issuance of an RFC number for this document. They are holding the publication of an H.248 document that depends on this document. There is a real risk that since MRCPv2 has been fielded and proven for two years that the ITU-T will convince the MRCP community to publish MRCPv2 as an ITU-T document. This would set a very bad precedent.

Some people unfamiliar with the history of MRCPv2 may question the use of SIP for locating speech servers, asking why we do not use RTSP, BEEP, or the MEDIACTRL Framework.  RFC 4313, Speech Services Control Requirements, not surprisingly, enumerates the protocol requirements for MRCP.  Some of these requirements include server location and avoiding layer violations.  SIP and RTSP meet the server location requirements. However, the original MRCP experience demonstrated severe protocol layering problems with RTSP.  Thus, the industry demonstrated RTSP is not appropriate for use as a MRCPv2 location or substrate protocol. With respect to MEDIACTRL, MRCPv2 pre-dates the effort by almost four years.  In fact, the basis of the MEDIACTRL Framework is, in fact, MRCPv2.  At this time, given the years of implementation experience with MRCPv2, the industry is unlikely to accept major changes to the MRCPv2 protocol, unless there are clear benefits to those changes.

There was some discussion about whether MRCPv2 should fully specify SRTP key exchange for SIP. Consensus in the work group and with the individual who brought that up (Vijay Gurbani) was to leave that to a SIP-related work group.

Another issue is MRCPv2 uses set-cookie (RFC 2109) and set-cookie2 (RFC 2965).  RFC 2965 obsoletes RFC 2109, but does not define set-cookie. After three years of implementation experience, the work group prefers to go with a DOWNREF to RFC 2109 rather than change all extant implementations.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is strong consensus with no dissent whatsoever in the work group to publish. In addition, there are literally dozens of client, server, open source and API implementations available.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

None.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Checked with idnits 2.12.12. There are warnings about what idnits thinks is a FQDN but is really a reverse-order parameter registry (com.example.mumble).

Four references need to be updated. The RFC Editor can make them. There are:

** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965)
** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265)

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document identifies normative versus informative documents. All normative references are standards track RFCs except for nominal DOWNREF is to RFC 2483; that reference is to the text/uri-list definition. MRCPv2 uses the same definition of text/uri-list as found in the IANA media types registry. We could make this reference Informative or be silent on the reference, as the MRCPv2 reference is to the IANA registry. However, the work group believes it to be useful to have a pointer to the definition of text/uri-list for implementers to follow.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section meets the above requirements. We would like the RFC Editor to update the last paragraph in section 13.1.6, "MRCPv2 vendor-specific parameters, " to read

OLD
The registry contains a list of vendor-registered parameters, where
each defined parameter is associated with a reference to an RFC
defining it.  The registry is initially empty.

NEW
The registry contains a list of vendor-registered parameters, where each defined parameter is associated with a contact person and includes an optional reference to the definition of the parameter, preferably an RFC.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes. ABNF checked with Bill Fenner’s tool. XML checked with XMLmind.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

        Technical Summary
The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network.  MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery.  It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server.  Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server.


        Working Group Summary
Nothing out of the ordinary happened in the WG to note.

        Document Quality
There are over 20 interoperable implementations of clients, servers, open source, and APIs based on this document.

IANA has questions about the IANA Actions required upon approval of this
document.

IANA understands that, upon approval of this document, there are
fourteen IANA Actions that need to be completed. IANA also understands
that MRCPv2 is effectively a new version of RFC4463 which had no IANA
registration requirements. As a result, IANA will create a new, full
registry and IANA Matrix entry for MRCPv2.

First, in the new registry created for MRCPv2, IANA will create a new
subregistry called "MRCPv2 resource types". New registrations in this
new registry will be done through "Standards Action" as defined by RFC
5226. The initial contents of the registry are as follows:

Resource type Resource description Reference
------------- -------------------- ---------
speechrecog Speech Recognizer [RFC-to-be]
dtmfrecog DTMF Recognizer [RFC-to-be]
speechsynth Speech Synthesizer [RFC-to-be]
basicsynth Basic Synthesizer [RFC-to-be]
speakverify Speaker Verifier [RFC-to-be]
recorder Speech Recorder [RFC-to-be]

Second, in the new registry created for MRCPv2, IANA will create a new
subregistry called "MRCPv2 methods and events". New registrations in
this new registry will be done through "Standards Action" as defined by
RFC 5226. The initial contents of the registry are as follows:

Name Resource type Method/Event Reference
---- ------------- ------------ ---------
SET-PARAMS Generic Method [RFC-to-be]
GET-PARAMS Generic Method [RFC-to-be]
SPEAK Synthesizer Method [RFC-to-be]
STOP Synthesizer Method [RFC-to-be]
PAUSE Synthesizer Method [RFC-to-be]
RESUME Synthesizer Method [RFC-to-be]
BARGE-IN-OCCURRED Synthesizer Method [RFC-to-be]
CONTROL Synthesizer Method [RFC-to-be]
DEFINE-LEXICON Synthesizer Method [RFC-to-be]
DEFINE-GRAMMAR Recognizer Method [RFC-to-be]
RECOGNIZE Recognizer Method [RFC-to-be]
INTERPRET Recognizer Method [RFC-to-be]
GET-RESULT Recognizer Method [RFC-to-be]
START-INPUT-TIMERS Recognizer Method [RFC-to-be]
STOP Recognizer Method [RFC-to-be]
START-PHRASE-ENROLLMENT Recognizer Method [RFC-to-be]
ENROLLMENT-ROLLBACK Recognizer Method [RFC-to-be]
END-PHRASE-ENROLLMENT Recognizer Method [RFC-to-be]
MODIFY-PHRASE Recognizer Method [RFC-to-be]
DELETE-PHRASE Recognizer Method [RFC-to-be]
RECORD Recorder Method [RFC-to-be]
STOP Recorder Method [RFC-to-be]
START-INPUT-TIMERS Recorder Method [RFC-to-be]
START-SESSION Verifier Method [RFC-to-be]
END-SESSION Verifier Method [RFC-to-be]
QUERY-VOICEPRINT Verifier Method [RFC-to-be]
DELETE-VOICEPRINT Verifier Method [RFC-to-be]
VERIFY Verifier Method [RFC-to-be]
VERIFY-FROM-BUFFER Verifier Method [RFC-to-be]
VERIFY-ROLLBACK Verifier Method [RFC-to-be]
STOP Verifier Method [RFC-to-be]
START-INPUT-TIMERS Verifier Method [RFC-to-be]
GET-INTERMEDIATE-RESULT Verifier Method [RFC-to-be]
SPEECH-MARKER Synthesizer Event [RFC-to-be]
SPEAK-COMPLETE Synthesizer Event [RFC-to-be]
START-OF-INPUT Recognizer Event [RFC-to-be]
RECOGNITION-COMPLETE Recognizer Event [RFC-to-be]
INTERPRETATION-COMPLETE Recognizer Event [RFC-to-be]
START-OF-INPUT Recorder Event [RFC-to-be]
RECORD-COMPLETE Recorder Event [RFC-to-be]
VERIFICATION-COMPLETE Verifier Event [RFC-to-be]
START-OF-INPUT Verifier Event [RFC-to-be]

Third, in the new registry created for MRCPv2, IANA will create a new
subregistry called "MRCPv2 header fields". New registrations in this
new registry will be done through "Standards Action" as defined by RFC
5226. The initial contents of the registry are as follows:

Name Resource type Reference
---- ------------- ---------
channel-identifier Generic [RFC-to-be]
accept Generic [RFC2616]
active-request-id-list Generic [RFC-to-be]
proxy-sync-id Generic [RFC-to-be]
accept-charset Generic [RFC2616]
content-type Generic [RFC-to-be]
content-id Generic [RFC2392, RFC2046, and
RFC5322]
content-base Generic [RFC-to-be]
content-encoding Generic [RFC-to-be]
content-location Generic [RFC-to-be]
content-length Generic [RFC-to-be]
fetch-timeout Generic [RFC-to-be]
cache-control Generic [RFC-to-be]
logging-tag Generic [RFC-to-be]
set-cookie Generic [RFC-to-be]
set-cookie2 Generic [RFC-to-be]
vendor-specific Generic [RFC-to-be]
jump-size Synthesizer [RFC-to-be]
kill-on-barge-in Synthesizer [RFC-to-be]
speaker-profile Synthesizer [RFC-to-be]
completion-cause Synthesizer [RFC-to-be]
completion-reason Synthesizer [RFC-to-be]
voice-parameter Synthesizer [RFC-to-be]
prosody-parameter Synthesizer [RFC-to-be]
speech-marker Synthesizer [RFC-to-be]
speech-language Synthesizer [RFC-to-be]
fetch-hint Synthesizer [RFC-to-be]
audio-fetch-hint Synthesizer [RFC-to-be]
failed-uri Synthesizer [RFC-to-be]
failed-uri-cause Synthesizer [RFC-to-be]
speak-restart Synthesizer [RFC-to-be]
speak-length Synthesizer [RFC-to-be]
load-lexicon Synthesizer [RFC-to-be]
lexicon-search-order Synthesizer [RFC-to-be]
confidence-threshold Recognizer [RFC-to-be]
sensitivity-level Recognizer [RFC-to-be]
speed-vs-accuracy Recognizer [RFC-to-be]
n-best-list-length Recognizer [RFC-to-be]
input-type Recognizer [RFC-to-be]
no-input-timeout Recognizer [RFC-to-be]
recognition-timeout Recognizer [RFC-to-be]
waveform-uri Recognizer [RFC-to-be]
input-waveform-uri Recognizer [RFC-to-be]
completion-cause Recognizer [RFC-to-be]
completion-reason Recognizer [RFC-to-be]
recognizer-context-block Recognizer [RFC-to-be]
start-input-timers Recognizer [RFC-to-be]
speech-complete-timeout Recognizer [RFC-to-be]
speech-incomplete-timeout Recognizer [RFC-to-be]
dtmf-interdigit-timeout Recognizer [RFC-to-be]
dtmf-term-timeout Recognizer [RFC-to-be]
dtmf-term-char Recognizer [RFC-to-be]
failed-uri Recognizer [RFC-to-be]
failed-uri-cause Recognizer [RFC-to-be]
save-waveform Recognizer [RFC-to-be]
media-type Recognizer [RFC-to-be]
new-audio-channel Recognizer [RFC-to-be]
speech-language Recognizer [RFC-to-be]
ver-buffer-utterance Recognizer [RFC-to-be]
recognition-mode Recognizer [RFC-to-be]
cancel-if-queue Recognizer [RFC-to-be]
hotword-max-duration Recognizer [RFC-to-be]
hotword-min-duration Recognizer [RFC-to-be]
interpret-text Recognizer [RFC-to-be]
dtmf-buffer-time Recognizer [RFC-to-be]
clear-dtmf-buffer Recognizer [RFC-to-be]
early-no-match Recognizer [RFC-to-be]
num-min-consistent-pronunciations Recognizer [RFC-to-be]
consistency-threshold Recognizer [RFC-to-be]
clash-threshold Recognizer [RFC-to-be]
personal-grammar-uri Recognizer [RFC-to-be]
enroll-utterance Recognizer [RFC-to-be]
phrase-id Recognizer [RFC-to-be]
phrase-nl Recognizer [RFC-to-be]
weight Recognizer [RFC-to-be]
save-best-waveform Recognizer [RFC-to-be]
new-phrase-id Recognizer [RFC-to-be]
confusable-phrases-uri Recognizer [RFC-to-be]
abort-phrase-enrollment Recognizer [RFC-to-be]
sensitivity-level Recorder [RFC-to-be]
no-input-timeout Recorder [RFC-to-be]
completion-cause Recorder [RFC-to-be]
completion-reason Recorder [RFC-to-be]
failed-uri Recorder [RFC-to-be]
failed-uri-cause Recorder [RFC-to-be]
record-uri Recorder [RFC-to-be]
media-type Recorder [RFC-to-be]
max-time Recorder [RFC-to-be]
trim-length Recorder [RFC-to-be]
final-silence Recorder [RFC-to-be]
capture-on-speech Recorder [RFC-to-be]
ver-buffer-utterance Recorder [RFC-to-be]
start-input-timers Recorder [RFC-to-be]
new-audio-channel Recorder [RFC-to-be]
repository-uri Verifier [RFC-to-be]
voiceprint-identifier Verifier [RFC-to-be]
verification-mode Verifier [RFC-to-be]
adapt-model Verifier [RFC-to-be]
abort-model Verifier [RFC-to-be]
min-verification-score Verifier [RFC-to-be]
num-min-verification-phrases Verifier [RFC-to-be]
num-max-verification-phrases Verifier [RFC-to-be]
no-input-timeout Verifier [RFC-to-be]
save-waveform Verifier [RFC-to-be]
media-type Verifier [RFC-to-be]
waveform-uri Verifier [RFC-to-be]
voiceprint-exists Verifier [RFC-to-be]
ver-buffer-utterance Verifier [RFC-to-be]
input-waveform-uri Verifier [RFC-to-be]
completion-cause Verifier [RFC-to-be]
completion-reason Verifier [RFC-to-be]
speech-complete-timeout Verifier [RFC-to-be]
new-audio-channel Verifier [RFC-to-be]
abort-verification Verifier [RFC-to-be]
start-input-timers Verifier [RFC-to-be]
input-type Verifier [RFC-to-be]

Fourth, in the new registry created for MRCPv2, IANA will create a new
subregistry called "MRCPv2 status codes". New registrations in this new
registry will be done through "Specification Required with Expert
Review" as defined by RFC 5226. The initial contents of the registry
are as follows:

Code Meaning Reference
200 Success [RFC-to-be]
201 Success with some optional header fields ignored [RFC-to-be]
401 Method not allowed [RFC-to-be]
402 Method not valid in this state [RFC-to-be]
403 Unsupported header field [RFC-to-be]
404 Illegal value for header field. This is the error [RFC-to-be]
for a syntax violation. [RFC-to-be]
405 Resource not allocated for this session or does not [RFC-to-be]
exist [RFC-to-be]
406 Mandatory Header Field Missing [RFC-to-be]
407 Method or Operation Failed (e.g., Grammar [RFC-to-be]
compilation failed in the recognizer. Detailed [RFC-to-be]
cause codes MAY BE available through a resource [RFC-to-be]
specific header.) [RFC-to-be]
408 Unrecognized or unsupported message entity [RFC-to-be]
409 Unsupported Header Field Value. This is a value [RFC-to-be]
that is syntactically legal but exceeds the [RFC-to-be]
implementation's capabilities or expectations. [RFC-to-be]
410 Non-Monotonic or Out of order sequence number in [RFC-to-be]
request. [RFC-to-be]
411-420 Reserved for future assignment [RFC-to-be]
501 Server Internal Error [RFC-to-be]
502 Protocol Version not supported [RFC-to-be]
503 Reserved for future assignment [RFC-to-be]
504 Message too large [RFC-to-be]

Fifth, in the new registry created for MRCPv2, IANA will create a new
namespace called "Grammar Reference List Parameters". New registrations
in this new registry will be done through "Specification Required with
Expert Review" as defined by RFC 5226.

IANA QUESTION --> What should the namespace/registry look like? What
information should be in the registry? IANA understands that there is
only one initial parameter, but is unclear on how it should be
represented in the namespace.

Sixth, in the new registry created for MRCPv2, IANA will create a new
namespace called "MRCPv2 vendor-specific parameters". The registration
policy for this registry will be done according to "Hierarchical
ALlocation" as defined by RFC 5226.

Each name (corresponding to the "vendor-av-pair-name" ABNF production)
MUST satisfy the syntax requirements of Internet Domain Names as
described in section 2.3.1 of RFC1035 [RFC1035] (and as updated or
obsoleted by successive RFCs), with one exception, the order of the
domain names is reversed.

For example, a vendor-specific parameter "foo" by example.com would have
the form "com.example.foo".

The first, or top-level domain, is restricted to exactly the set of
Top-Level Internet Domains defined by IANA and will be updated by IANA
when and only when that set changes. The second-level and all
subdomains within the parameter name MUST be allocated according to the
"Expert Review" policy. The Designated Expert MAY advise IANA to allow
delegation of subdomains to the requester.
As a general guideline, the Designated Expert is encouraged to manage
the allocation of corporate, organizational, or institutional names and
delegate all subdomains accordingly. For example, the Designated Expert
MAY allocate "com.example" and delegate all subdomains of that name to
the organization represented by the Internet domain name "example.com".
For simplicity, the Designated Expert is encouraged to perform
allocations according to the existing allocations of Internet domain
names to organizations, institutions, corporations, etc.

The registry contains a list of vendor-registered parameters, where each
defined parameter is associated with a reference to an RFC defining it.
The registry is initially empty.

Seventh, in the application Media Types regestry located at:

http://www.iana.org/assignments/media-types/application/index.html

a new Application Media Type will be registered as follows:

Media type: nlsml+xml
Reference: [RFC-to-be]

Eighth, in the schema registry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

the authors appear to want to register a schema. However, the
instructions in section 13.3 do not provide sufficient information to
register the schema and the URI provided does not resolve.

IANA QUESTION --> Could the authors provide the information needed to
register the NLSML XML Schema registration? We would expect to see a URI
with the following format: urn:ietf:params:xml:schema:example

Ninth, in the namespaces registry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

the authors appear to want to register a new XML namespace. However,
the instructions in section 13.4 of the document do not provide
sufficient information to register the namespace and URI provided does
not resolve.

IANA QUESTION --> Could the authors provide the information needed to
register the MRCPv2 XML Namespace registration?

Tenth, in the text Media Types regestry located at:

http://www.iana.org/assignments/media-types/text/index.html

a new Text Media Type will be registered as follows:

Media type: text/grammar-ref-list
Reference: [RFC-to-be]

Eleventh, in the Uniform Resource Identifer (URI) Schemes registry
located at:

http://www.iana.org/assignments/uri-schemes.html

a new, Permanent URI Scheme is to be registered as follows:

URI Scheme: session
Description: MRCPv2
Reference: [RFC-to-be]

Twelveth, in the SDP Parameters for type proto in the Session
Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters

a new registration will be made as follows:

SDP Name: TCP/MRCPv2
Reference: [RFC-to-be]

Thirteenth, in the SDP Parameters for type att-field (session-level) in
the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters

a new registration will be made as follows:

SDP Name: resource
Reference: [RFC-to-be]

Fourteenth, in the SDP Parameters for type att-field (media-level) in
the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters

a new registration will be made as follows:

SDP Name: cmid
Reference: [RFC-to-be]

IANA understands that these are the only actions that are required to be
completed upon approval of the document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard


The IESG has received a request from the Speech Services Control WG
(speechsc) to consider the following document:
- 'Media Resource Control Protocol Version 2 (MRCPv2)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-04-13. (This allows an additional two
weeks for review since the document is large and the review period overlaps
the Prague IETF meeting). Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
Dan indicates there's probably a version problem with this update. I'm putting this back into Revised-ID needed while he sorts that out.

(1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Eric Burger is the document shepherd. I have personally reviewed this version of the document. This document is ready for forwarding to the IESG for publication.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has had reviews by key WG members, as well as expert review from MMUSIC (Magnus Westerlund), GENART (Vijay Gurbani), applications (Ted Hardie and Peter St. Andre), RAI (Paul Kyzivat), and AVT (Roni Evan), areas.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

Reviews listed above, as well as IANA, URL, and MIME types review. The document incorporates and addresses all suggestions from Peter, Vijay, Ted, Paul, and other IESG members, as well as expert review and comments incorporated from Roni Evan.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

Some people unfamiliar with the history of MRCPv2 may question the use of SIP for locating speech servers, asking why we do not use RTSP, BEEP, or the MEDIACTRL Framework.  RFC 4313, Speech Services Control Requirements, not surprisingly, enumerates the protocol requirements for MRCP.  Some of these requirements include server location and avoiding layer violations.  SIP and RTSP meet the server location requirements.  However, the original MRCP experience demonstrated severe protocol layering problems with RTSP.  Thus, the industry demonstrated RTSP is not appropriate for use as a MRCPv2 location or substrate protocol. With respect to MEDIACTRL, MRCPv2 pre-dates the effort by almost four years.  In fact, the basis of the MEDIACTRL Framework is, in fact, MRCPv2.  At this time, given the years of implementation experience with MRCPv2, the industry is unlikely to accept major changes to the MRCPv2 protocol, unless there are clear benefits to those changes.

There was some discussion about whether MRCPv2 should fully specify SRTP key exchange for SIP. Consensus in the work group and with the individual who brought that up (Vijay Gurbani) was to leave that to a SIP-related work group.

Another issue is MRCPv2 uses set-cookie (RFC 2109) and set-cookie2 (RFC 2965).  RFC 2965 obsoletes RFC 2109, but does not define set-cookie. After three years of implementation experience, the work group prefers to go with a DOWNREF to RFC 2109 rather than change all extant implementations.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is strong consensus with no dissent whatsoever in the work group to publish. In addition, there are literally dozens of client, server, open source and API implementations available.

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

None.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Checked with idnits 2.12.05. There are warnings about what idnits thinks is a FQDN but is really a reverse-order parameter registry (com.example.mumble).

Four references need to be updated. The RFC Editor can make them. There are:

  ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888)
  ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965)
  ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646)
  ** Obsolete informational reference (is this intentional?): RFC 2234
    (Obsoleted by RFC 4234)

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document identifies normative versus informative documents. All normative references are RFCs. One DOWNREF is to RFC 2109 (see above). Another nominal DOWNREF is to RFC 2483; that reference is to the text/uri-list definition. MRCPv2 uses the same definition of text/uri-list as found in the IANA media types registry. We could make this reference Informative or be silent on the reference, as the MRCPv2 reference is to the IANA registry. However, the work group believes it to be useful to have a pointer to the definition of text/uri-list for implementers to follow.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section meets the above requirements.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes. ABNF checked with Bill Fenner’s tool. XML checked with XMLmind.

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary
The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network.  MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery.  It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server.  Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server.


          Working Group Summary
Nothing out of the ordinary happened in the WG to note.

          Document Quality
There are over 20 interoperable implementations of clients, servers, open source, and APIs based on this document.

Document:
Media Resource Control Protocol Version 2 (MRCPv2)
draft-ietf-speechsc-mrcpv2-19
(Standards Track)

(1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Eric Burger is the document shepherd. I have personally reviewed this 
version of the document. This doeucment is ready for forwarding to the 
IESG for publication.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has had reviews by key WG members, as well as expert 
review from GENART (Vijay Gurbani), applications (Ted Hardie), RAI 
(Paul Kyzivat), and security (Vijay Gurbani), areas.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

Reviews listed above, as well as IANA, URL, and MIME types review. The 
document incorporates and addresses all suggestions from Vijay, Ted, 
Paul, and other IESG members.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, 
or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

Some people unfamiliar with the history of MRCPv2 may question the use 
of SIP for locating speech servers, asking why we do not use RTSP, 
BEEP, or the MEDIACTRL Framework.  RFC 4313, Speech Services Control 
Requirements, not surprisingly, enumerates the protocol requirements 
for MRCP.  Some of these requirements include server location and 
avoiding layer violations.  SIP and RTSP meet the server location 
requirements.  However, the original MRCP experience demonstrated 
severe protocol layering problems with RTSP.  Thus, the industry 
demonstrated RTSP is not appropriate for use as a MRCPv2 location or 
substrate protocol. With respect to MEDIACTRL, MRCPv2 pre-dates the 
effort by almost four years.  In fact, the basis of the MEDIACTRL 
Framework is, in fact, MRCPv2.  At this time, given the years of 
implementation experience with MRCPv2, the industry is unlikely to 
accept major changes to the MRCPv2 protocol, unless there are clear 
benefits to those changes.

There was some discussion about whether MRCPv2 should fully specify 
SRTP key exchange for SIP. Consensus in the work group and with the 
individual who brought that up (Vijay Gurbani) was to leave that to a 
SIP-related work group.

Another issue is MRCPv2 uses set-cookie (RFC 2109) and set-cookie2 
(RFC 2965).  RFC 2965 obsoletes RFC 2109, but does not define set-
cookie. After three years of implementation experience, the work group 
prefers to go with a DOWNREF to RFC 2109 rather than change all extant 
implementations.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is strong consensus with no dissent whatsoever in the work group 
to publish. In addition, there are literally dozens of client, server, 
open source and API implementations available.

    (1.f) Has anyone threatened an appeal or otherwise indicated 
extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

None.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Checked with ID nits 2.11.11. There are warnings about what idnits 
thinks is a FQDN but is really a reverse-order parameter registry 
(com.example.mumble).

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document identifies normative versus informative documents. All 
normative references are RFCs. One DOWNREF is to RFC 2109 (see above). 
Another nominal DOWNREF is to RFC 2483; that reference is to the text/
uri-list definition. MRCPv2 uses the same definition of text/uri-list 
as found in the IANA media types registry. We could make this 
reference Informative or be silent on the reference, as the MRCPv2 
reference is to the IANA registry. However, the work group believes it 
to be useful to have a pointer to the definition of text/uri-list for 
implementers to follow.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section meets the above requirements.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes. ABNF checked with Bill Fenner’s tool. XML checked with XMLmind.

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary
The MRCPv2 protocol allows client hosts to control media service 
resources such as speech synthesizers, recognizers, verifiers and 
identifiers residing in servers on the network.  MRCPv2 is not a 
"stand-alone" protocol - it relies on a session management protocol 
such as the Session Initiation Protocol (SIP) to establish the MRCPv2 
control session between the client and the server, and for rendezvous 
and capability discovery.  It also depends on SIP and SDP to establish 
the media sessions and associated parameters between the media source 
or sink and the media server.  Once this is done, the MRCPv2 protocol 
exchange operates over the control session established above, allowing 
the client to control the media processing resources on the speech 
resource server.


          Working Group Summary
Nothing out of the ordinary happened in the WG to note.

          Document Quality
There are over 20 interoperable implementations of clients, servers, 
open source, and APIs based on this document.