Media Resource Control Protocol Version 2 (MRCPv2)
RFC 6787

Note: This ballot was opened for revision 27 and is now closed.

(Jari Arkko) Discuss

Discuss (2011-12-01 for -)
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

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

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.

(Dan Romascanu) Discuss

Discuss (2011-12-01 for -)
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? 
Comment (2011-12-01 for -)
No email
send info
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. 

(Robert Sparks) (was Discuss, Yes) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2011-11-29 for -27)
No email
send info
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.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-08-28)
No email
send info
- This is abominably long;-)

(Russ Housley) No Objection

(Pete Resnick) (was Discuss) No Objection

Comment (2012-08-31)
No email
send info
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 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.

(Peter Saint-Andre) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-11-30)
No email
send info
#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

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:

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