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

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.

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.

#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 ;)

- This is abominably long;-)