4.  MRCPv2 Basics

   MRCPv2 requires a connection-oriented transport-layer protocol such
   as TCP to guarantee reliable sequencing and delivery of MRCPv2
   control messages between the client and the server.  In order to meet
   the requirements for security enumerated in SPEECHSC requirements
   [RFC4313], clients and servers MUST implement TLS as well.  One or
   more connections between the client and the server can be shared
   among different MRCPv2 channels to the server.  The individual
   messages carry the channel identifier to differentiate messages on
   different channels.  MRCPv2 encoding is text based with mechanisms to
   carry embedded binary data.  This allows arbitrary data like
   recognition grammars, recognition results, synthesizer speech markup,
   etc., to be carried in MRCPv2 messages.  For information on message
   framing, see Section 5.

4.1.  Connecting to the Server

   MRCPv2 employs SIP, in conjunction with SDP, as the session
   establishment and management protocol.  The client reaches an MRCPv2
   server using conventional INVITE and other SIP requests for
   establishing, maintaining, and terminating SIP dialogs.  The SDP
   offer/answer exchange model over SIP is used to establish a resource
   control channel for each resource.  The SDP offer/answer exchange is
   also used to establish media sessions between the server and the
   source or sink of audio.

4.2.  Managing Resource Control Channels

   The client needs a separate MRCPv2 resource control channel to
   control each media processing resource under the SIP dialog.  A
   unique channel identifier string identifies these resource control
   channels.  The channel identifier is a difficult-to-guess,
   unambiguous string followed by an "@", then by a string token
   specifying the type of resource.  The server generates the channel
   identifier and MUST make sure it does not clash with the identifier
   of any other MRCP channel currently allocated by that server.  MRCPv2
   defines the following IANA-registered types of media processing

   resources.  Additional resource types and their associated methods/
   events and state machines may be added as described below in
   Section 13.

          +---------------+----------------------+--------------+
          | Resource Type | Resource Description | Described in |
          +---------------+----------------------+--------------+
          | speechrecog   | Speech Recognizer    | Section 9    |
          | dtmfrecog     | DTMF Recognizer      | Section 9    |
          | speechsynth   | Speech Synthesizer   | Section 8    |
          | basicsynth    | Basic Synthesizer    | Section 8    |
          | speakverify   | Speaker Verification | Section 11   |
          | recorder      | Speech Recorder      | Section 10   |
          +---------------+----------------------+--------------+

                          Table 1: Resource Types

   The SIP INVITE or re-INVITE transaction and the SDP offer/answer
   exchange it carries contain "m=" lines describing the resource
   control channel to be allocated.  There MUST be one SDP "m=" line for
   each MRCPv2 resource to be used in the session.  This "m=" line MUST
   have a media type field of "application" and a transport type field
   of either "TCP/MRCPv2" or "TCP/TLS/MRCPv2".  The port number field of
   the "m=" line MUST contain the "discard" port of the transport
   protocol (port 9 for TCP) in the SDP offer from the client and MUST
   contain the TCP listen port on the server in the SDP answer.  The
   client may then either set up a TCP or TLS connection to that server
   port or share an already established connection to that port.  Since
   MRCPv2 allows multiple sessions to share the same TCP connection,
   multiple "m=" lines in a single SDP document MAY share the same port
   field value; MRCPv2 servers MUST NOT assume any relationship between
   resources using the same port other than the sharing of the
   communication channel.

   MRCPv2 resources do not use the port or format field of the "m=" line
   to distinguish themselves from other resources using the same
   channel.  The client MUST specify the resource type identifier in the
   resource attribute associated with the control "m=" line of the SDP
   offer.  The server MUST respond with the full Channel-Identifier
   (which includes the resource type identifier and a difficult-to-
   guess, unambiguous string) in the "channel" attribute associated with
   the control "m=" line of the SDP answer.  To remain backwards
   compatible with conventional SDP usage, the format field of the "m="
   line MUST have the arbitrarily selected value of "1".

   When the client wants to add a media processing resource to the
   session, it issues a new SDP offer, according to the procedures of
   RFC 3264 [RFC3264], in a SIP re-INVITE request.  The SDP offer/answer

   exchange carried by this SIP transaction contains one or more
   additional control "m=" lines for the new resources to be allocated
   to the session.  The server, on seeing the new "m=" line, allocates
   the resources (if they are available) and responds with a
   corresponding control "m=" line in the SDP answer carried in the SIP
   response.  If the new resources are not available, the re-INVITE
   receives an error message, and existing media processing going on
   before the re-INVITE will continue as it was before.  It is not
   possible to allocate more than one resource of each type.  If a
   client requests more than one resource of any type, the server MUST
   behave as if the resources of that type (beyond the first one) are
   not available.

   MRCPv2 clients and servers using TCP as a transport protocol MUST use
   the procedures specified in RFC 4145 [RFC4145] for setting up the TCP
   connection, with the considerations described hereby.  Similarly,
   MRCPv2 clients and servers using TCP/TLS as a transport protocol MUST
   use the procedures specified in RFC 4572 [RFC4572] for setting up the
   TLS connection, with the considerations described hereby.  The
   a=setup attribute, as described in RFC 4145 [RFC4145], MUST be
   "active" for the offer from the client and MUST be "passive" for the
   answer from the MRCPv2 server.  The a=connection attribute MUST have
   a value of "new" on the very first control "m=" line offer from the
   client to an MRCPv2 server.  Subsequent control "m=" line offers from
   the client to the MRCP server MAY contain "new" or "existing",
   depending on whether the client wants to set up a new connection or
   share an existing connection, respectively.  If the client specifies
   a value of "new", the server MUST respond with a value of "new".  If
   the client specifies a value of "existing", the server MUST respond.
   The legal values in the response are "existing" if the server prefers
   to share an existing connection or "new" if not.  In the latter case,
   the client MUST initiate a new transport connection.

   When the client wants to deallocate the resource from this session,
   it issues a new SDP offer, according to RFC 3264 [RFC3264], where the
   control "m=" line port MUST be set to 0.  This SDP offer is sent in a
   SIP re-INVITE request.  This deallocates the associated MRCPv2
   identifier and resource.  The server MUST NOT close the TCP or TLS
   connection if it is currently being shared among multiple MRCP
   channels.  When all MRCP channels that may be sharing the connection
   are released and/or the associated SIP dialog is terminated, the
   client or server terminates the connection.

   When the client wants to tear down the whole session and all its
   resources, it MUST issue a SIP BYE request to close the SIP session.
   This will deallocate all the control channels and resources allocated
   under the session.

   All servers MUST support TLS.  Servers MAY use TCP without TLS in
   controlled environments (e.g., not in the public Internet) where both
   nodes are inside a protected perimeter, for example, preventing
   access to the MRCP server from remote nodes outside the controlled
   perimeter.  It is up to the client, through the SDP offer, to choose
   which transport it wants to use for an MRCPv2 session.  Aside from
   the exceptions given above, when using TCP, the "m=" lines MUST
   conform to RFC4145 [RFC4145], which describes the usage of SDP for
   connection-oriented transport.  When using TLS, the SDP "m=" line for
   the control stream MUST conform to Connection-Oriented Media
   (COMEDIA) over TLS [RFC4572], which specifies the usage of SDP for
   establishing a secure connection-oriented transport over TLS.

4.3.  SIP Session Example

   This first example shows the power of using SIP to route to the
   appropriate resource.  In the example, note the use of a request to a
   domain's speech server service in the INVITE to
   mresources@example.com.  The SIP routing machinery in the domain
   locates the actual server, mresources@server.example.com, which gets
   returned in the 200 OK.  Note that "cmid" is defined in Section 4.4.

   This example exchange adds a resource control channel for a
   synthesizer.  Since a synthesizer also generates an audio stream,
   this interaction also creates a receive-only Real-Time Protocol (RTP)
   [RFC3550] media session for the server to send audio to.  The SIP
   dialog with the media source/sink is independent of MRCP and is not
   shown.

   C->S:  INVITE sip:mresources@example.com SIP/2.0
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf1
          Max-Forwards:6
          To:MediaServer <sip:mresources@example.com>
          From:sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314161 INVITE
          Contact:<sip:sarvi@client.example.com>
          Content-Type:application/sdp
          Content-Length:...

          v=0
          o=sarvi 2890844526 2890844526 IN IP4 192.0.2.12
          s=-
          c=IN IP4 192.0.2.12
          t=0 0
          m=application 9 TCP/MRCPv2 1
          a=setup:active

          a=connection:new
          a=resource:speechsynth
          a=cmid:1
          m=audio 49170 RTP/AVP 0
          a=rtpmap:0 pcmu/8000
          a=recvonly
          a=mid:1


   S->C:  SIP/2.0 200 OK
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf1;received=192.0.32.10
          To:MediaServer <sip:mresources@example.com>;tag=62784
          From:sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314161 INVITE
          Contact:<sip:mresources@server.example.com>
          Content-Type:application/sdp
          Content-Length:...

          v=0
          o=- 2890842808 2890842808 IN IP4 192.0.2.11
          s=-
          c=IN IP4 192.0.2.11
          t=0 0
          m=application 32416 TCP/MRCPv2 1
          a=setup:passive
          a=connection:new
          a=channel:32AECB234338@speechsynth
          a=cmid:1
          m=audio 48260 RTP/AVP 0
          a=rtpmap:0 pcmu/8000
          a=sendonly
          a=mid:1


   C->S:  ACK sip:mresources@server.example.com SIP/2.0
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf2
          Max-Forwards:6
          To:MediaServer <sip:mresources@example.com>;tag=62784
          From:Sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314161 ACK
          Content-Length:0

                 Example: Add Synthesizer Control Channel

   This example exchange continues from the previous figure and
   allocates an additional resource control channel for a recognizer.
   Since a recognizer would need to receive an audio stream for
   recognition, this interaction also updates the audio stream to
   sendrecv, making it a two-way RTP media session.

   C->S:  INVITE sip:mresources@server.example.com SIP/2.0
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf3
          Max-Forwards:6
          To:MediaServer <sip:mresources@example.com>;tag=62784
          From:sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314162 INVITE
          Contact:<sip:sarvi@client.example.com>
          Content-Type:application/sdp
          Content-Length:...

          v=0
          o=sarvi 2890844526 2890844527 IN IP4 192.0.2.12
          s=-
          c=IN IP4 192.0.2.12
          t=0 0
          m=application 9 TCP/MRCPv2 1
          a=setup:active
          a=connection:existing
          a=resource:speechsynth
          a=cmid:1
          m=audio 49170 RTP/AVP 0 96
          a=rtpmap:0 pcmu/8000
          a=rtpmap:96 telephone-event/8000
          a=fmtp:96 0-15
          a=sendrecv
          a=mid:1
          m=application 9 TCP/MRCPv2 1
          a=setup:active
          a=connection:existing
          a=resource:speechrecog
          a=cmid:1


   S->C:  SIP/2.0 200 OK
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf3;received=192.0.32.10
          To:MediaServer <sip:mresources@example.com>;tag=62784
          From:sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314162 INVITE

          Contact:<sip:mresources@server.example.com>
          Content-Type:application/sdp
          Content-Length:...

          v=0
          o=- 2890842808 2890842809 IN IP4 192.0.2.11
          s=-
          c=IN IP4 192.0.2.11
          t=0 0
          m=application 32416 TCP/MRCPv2 1
          a=setup:passive
          a=connection:existing
          a=channel:32AECB234338@speechsynth
          a=cmid:1
          m=audio 48260 RTP/AVP 0 96
          a=rtpmap:0 pcmu/8000
          a=rtpmap:96 telephone-event/8000
          a=fmtp:96 0-15
          a=sendrecv
          a=mid:1
          m=application 32416 TCP/MRCPv2 1
          a=setup:passive
          a=connection:existing
          a=channel:32AECB234338@speechrecog
          a=cmid:1


   C->S:  ACK sip:mresources@server.example.com SIP/2.0
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf4
          Max-Forwards:6
          To:MediaServer <sip:mresources@example.com>;tag=62784
          From:Sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314162 ACK
          Content-Length:0

                          Example: Add Recognizer

   This example exchange continues from the previous figure and
   deallocates the recognizer channel.  Since a recognizer no longer
   needs to receive an audio stream, this interaction also updates the
   RTP media session to recvonly.

   C->S:  INVITE sip:mresources@server.example.com SIP/2.0
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf5
          Max-Forwards:6

          To:MediaServer <sip:mresources@example.com>;tag=62784
          From:sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314163 INVITE
          Contact:<sip:sarvi@client.example.com>
          Content-Type:application/sdp
          Content-Length:...

          v=0
          o=sarvi 2890844526 2890844528 IN IP4 192.0.2.12
          s=-
          c=IN IP4 192.0.2.12
          t=0 0
          m=application 9 TCP/MRCPv2 1
          a=resource:speechsynth
          a=cmid:1
          m=audio 49170 RTP/AVP 0
          a=rtpmap:0 pcmu/8000
          a=recvonly
          a=mid:1
          m=application 0 TCP/MRCPv2 1
          a=resource:speechrecog
          a=cmid:1


   S->C:  SIP/2.0 200 OK
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf5;received=192.0.32.10
          To:MediaServer <sip:mresources@example.com>;tag=62784
          From:sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314163 INVITE
          Contact:<sip:mresources@server.example.com>
          Content-Type:application/sdp
          Content-Length:...

          v=0
          o=- 2890842808 2890842810 IN IP4 192.0.2.11
          s=-
          c=IN IP4 192.0.2.11
          t=0 0
          m=application 32416 TCP/MRCPv2 1
          a=channel:32AECB234338@speechsynth
          a=cmid:1
          m=audio 48260 RTP/AVP 0
          a=rtpmap:0 pcmu/8000
          a=sendonly
          a=mid:1

          m=application 0 TCP/MRCPv2 1
          a=channel:32AECB234338@speechrecog
          a=cmid:1

   C->S:  ACK sip:mresources@server.example.com SIP/2.0
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
           branch=z9hG4bK74bf6
          Max-Forwards:6
          To:MediaServer <sip:mresources@example.com>;tag=62784
          From:Sarvi <sip:sarvi@example.com>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314163 ACK
          Content-Length:0

                      Example: Deallocate Recognizer

4.4.  Media Streams and RTP Ports

   Since MRCPv2 resources either generate or consume media streams, the
   client or the server needs to associate media sessions with their
   corresponding resource or resources.  More than one resource could be
   associated with a single media session or each resource could be
   assigned a separate media session.  Also, note that more than one
   media session can be associated with a single resource if need be,
   but this scenario is not useful for the current set of resources.
   For example, a synthesizer and a recognizer could be associated to
   the same media session (m=audio line), if it is opened in "sendrecv"
   mode.  Alternatively, the recognizer could have its own "sendonly"
   audio session, and the synthesizer could have its own "recvonly"
   audio session.

   The association between control channels and their corresponding
   media sessions is established using a new "resource channel media
   identifier" media-level attribute ("cmid").  Valid values of this
   attribute are the values of the "mid" attribute defined in RFC 5888
   [RFC5888].  If there is more than one audio "m=" line, then each
   audio "m=" line MUST have a "mid" attribute.  Each control "m=" line
   MAY have one or more "cmid" attributes that match the resource
   control channel to the "mid" attributes of the audio "m=" lines it is
   associated with.  Note that if a control "m=" line does not have a
   "cmid" attribute it will not be associated with any media.  The
   operations on such a resource will hence be limited.  For example, if
   it was a recognizer resource, the RECOGNIZE method requires an
   associated media to process while the INTERPRET method does not.  The
   formatting of the "cmid" attribute is described by the following
   ABNF:

   cmid-attribute     = "a=cmid:" identification-tag
   identification-tag = token

   To allow this flexible mapping of media sessions to MRCPv2 control
   channels, a single audio "m=" line can be associated with multiple
   resources, or each resource can have its own audio "m=" line.  For
   example, if the client wants to allocate a recognizer and a
   synthesizer and associate them with a single two-way audio stream,
   the SDP offer would contain two control "m=" lines and a single audio
   "m=" line with an attribute of "sendrecv".  Each of the control "m="
   lines would have a "cmid" attribute whose value matches the "mid" of
   the audio "m=" line.  If, on the other hand, the client wants to
   allocate a recognizer and a synthesizer each with its own separate
   audio stream, the SDP offer would carry two control "m=" lines (one
   for the recognizer and another for the synthesizer) and two audio
   "m=" lines (one with the attribute "sendonly" and another with
   attribute "recvonly").  The "cmid" attribute of the recognizer
   control "m=" line would match the "mid" value of the "sendonly" audio
   "m=" line, and the "cmid" attribute of the synthesizer control "m="
   line would match the "mid" attribute of the "recvonly" "m=" line.

   When a server receives media (e.g., audio) on a media session that is
   associated with more than one media processing resource, it is the
   responsibility of the server to receive and fork the media to the
   resources that need to consume it.  If multiple resources in an
   MRCPv2 session are generating audio (or other media) to be sent on a
   single associated media session, it is the responsibility of the
   server either to multiplex the multiple streams onto the single RTP
   session or to contain an embedded RTP mixer (see RFC 3550 [RFC3550])
   to combine the multiple streams into one.  In the former case, the
   media stream will contain RTP packets generated by different sources,
   and hence the packets will have different Synchronization Source
   Identifiers (SSRCs).  In the latter case, the RTP packets will
   contain multiple Contributing Source Identifiers (CSRCs)
   corresponding to the original streams before being combined by the
   mixer.  If an MRCPv2 server implementation neither multiplexes nor
   mixes, it 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.  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 treat a 501 in this context as a 488 when it
   is received from an element known to be a legacy implementation.

4.5.  MRCPv2 Message Transport

   The MRCPv2 messages defined in this document are transported over a
   TCP or TLS connection between the client and the server.  The method
   for setting up this transport connection and the resource control
   channel is discussed in Sections 4.1 and 4.2.  Multiple resource
   control channels between a client and a server that belong to
   different SIP dialogs can share one or more TLS or TCP connections
   between them; the server and client MUST support this mode of
   operation.  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).  All
   MRCPv2 servers MUST support TLS.  Servers MAY use TCP without TLS in
   controlled environments (e.g., not in the public Internet) where both
   nodes are inside a protected perimeter, for example, preventing
   access to the MRCP server from remote nodes outside the controlled
   perimeter.  It is up to the client to choose which mode of transport
   it wants to use for an MRCPv2 session.

   Most examples from here on show only the MRCPv2 messages and do not
   show the SIP messages that may have been used to establish the MRCPv2
   control channel.

4.6.  MRCPv2 Session Termination

   If an MRCP client notices that the underlying connection has been
   closed for one of its MRCP channels, and it has not previously
   initiated a re-INVITE to close that channel, it MUST send a BYE to
   close down the SIP dialog and all other MRCP channels.  If an MRCP
   server notices that the underlying connection has been closed for one
   of its MRCP channels, and it has not previously received and accepted
   a re-INVITE closing that channel, then it MUST send a BYE to close
   down the SIP dialog and all other MRCP channels.

5.  MRCPv2 Specification

   Except as otherwise indicated, MRCPv2 messages are Unicode encoded in
   UTF-8 (RFC 3629 [RFC3629]) to allow many different languages to be
   represented.  DEFINE-GRAMMAR (Section 9.8), for example, is one such
   exception, since its body can contain arbitrary XML in arbitrary (but
   specified via XML) encodings.  MRCPv2 also allows message bodies to
   be represented in other character sets (for example, ISO 8859-1
   [ISO.8859-1.1987]) because, in some locales, other character sets are
   already in widespread use.  The MRCPv2 headers (the first line of an
   MRCP message) and header field names use only the US-ASCII subset of
   UTF-8.

   Lines are terminated by CRLF (carriage return, then line feed).
   Also, some parameters in the message may contain binary data or a
   record spanning multiple lines.  Such fields have a length value
   associated with the parameter, which indicates the number of octets
   immediately following the parameter.

5.1.  Common Protocol Elements

   The MRCPv2 message set consists of requests from the client to the
   server, responses from the server to the client, and asynchronous
   events from the server to the client.  All these messages consist of
   a start-line, one or more header fields, an empty line (i.e., a line
   with nothing preceding the CRLF) indicating the end of the header
   fields, and an optional message body.

generic-message  =    start-line
                      message-header
                      CRLF
                      [ message-body ]

message-body     =    *OCTET

start-line       =    request-line / response-line / event-line

message-header   =  1*(generic-header / resource-header / generic-field)

resource-header  =    synthesizer-header
                 /    recognizer-header
                 /    recorder-header
                 /    verifier-header

   The message-body contains resource-specific and message-specific
   data.  The actual media types used to carry the data are specified in
   the sections defining the individual messages.  Generic header fields
   are described in Section 6.2.

   If a message contains a message body, the message MUST contain
   content-headers indicating the media type and encoding of the data in
   the message body.

   Request, response and event messages (described in following
   sections) include the version of MRCP that the message conforms to.
   Version compatibility rules follow [H3.1] regarding version ordering,
   compliance requirements, and upgrading of version numbers.  The
   version information is indicated by "MRCP" (as opposed to "HTTP" in
   [H3.1]) or "MRCP/2.0" (as opposed to "HTTP/1.1" in [H3.1]).  To be
   compliant with this specification, clients and servers sending MRCPv2

   messages MUST indicate an mrcp-version of "MRCP/2.0".  ABNF
   productions using mrcp-version can be found in Sections 5.2, 5.3, and
   5.5.

   mrcp-version   =    "MRCP" "/" 1*2DIGIT "." 1*2DIGIT

   The message-length field specifies the length of the message in
   octets, including the start-line, and MUST be the second token from
   the beginning of the message.  This is to make the framing and
   parsing of the message simpler to do.  This field specifies the
   length of the message including data that may be encoded into the
   body of the message.  Note that this value MAY be given as a fixed-
   length integer that is zero-padded (with leading zeros) in order to
   eliminate or reduce inefficiency in cases where the message-length
   value would change as a result of the length of the message-length
   token itself.  This value, as with all lengths in MRCP, is to be
   interpreted as a base-10 number.  In particular, leading zeros do not
   indicate that the value is to be interpreted as a base-8 number.

   message-length =    1*19DIGIT

   The following sample MRCP exchange demonstrates proper message-length
   values.  The values for message-length have been removed from all
   other examples in the specification and replaced by '...' to reduce
   confusion in the case of minor message-length computation errors in
   those examples.

   C->S:   MRCP/2.0 877 INTERPRET 543266
           Channel-Identifier:32AECB23433801@speechrecog
           Interpret-Text:may I speak to Andre Roy
           Content-Type:application/srgs+xml
           Content-ID:<request1@form-level.store>
           Content-Length:661

           <?xml version="1.0"?>
           <!-- the default grammar language is US English -->
           <grammar xmlns="http://www.w3.org/2001/06/grammar"
                    xml:lang="en-US" version="1.0" root="request">
           <!-- single language attachment to tokens -->
               <rule id="yes">
                   <one-of>
                       <item xml:lang="fr-CA">oui</item>
                       <item xml:lang="en-US">yes</item>
                   </one-of>
               </rule>

           <!-- single language attachment to a rule expansion -->
               <rule id="request">
                   may I speak to
                   <one-of xml:lang="fr-CA">
                       <item>Michel Tremblay</item>
                       <item>Andre Roy</item>
                   </one-of>
               </rule>
           </grammar>

   S->C:   MRCP/2.0 82 543266 200 IN-PROGRESS
           Channel-Identifier:32AECB23433801@speechrecog

   S->C:   MRCP/2.0 634 INTERPRETATION-COMPLETE 543266 200 COMPLETE
           Channel-Identifier:32AECB23433801@speechrecog
           Completion-Cause:000 success
           Content-Type:application/nlsml+xml
           Content-Length:441

           <?xml version="1.0"?>
           <result xmlns="urn:ietf:params:xml:ns:mrcpv2"
                   xmlns:ex="http://www.example.com/example"
                   grammar="session:request1@form-level.store">
               <interpretation>
                   <instance name="Person">
                       <ex:Person>
                           <ex:Name> Andre Roy </ex:Name>
                       </ex:Person>
                   </instance>
                   <input>   may I speak to Andre Roy </input>
               </interpretation>
           </result>

   All MRCPv2 messages, responses and events MUST carry the Channel-
   Identifier header field so the server or client can differentiate
   messages from different control channels that may share the same
   transport connection.

   In the resource-specific header field descriptions in Sections 8-11,
   a header field is disallowed on a method (request, response, or
   event) for that resource unless specifically listed as being allowed.
   Also, the phrasing "This header field MAY occur on method X"
   indicates that the header field is allowed on that method but is not
   required to be used in every instance of that method.

5.2.  Request

   An MRCPv2 request consists of a Request line followed by the message
   header section and an optional message body containing data specific
   to the request message.

   The Request message from a client to the server includes within the
   first line the method to be applied, a method tag for that request
   and the version of the protocol in use.

   request-line   =    mrcp-version SP message-length SP method-name
                       SP request-id CRLF

   The mrcp-version field is the MRCP protocol version that is being
   used by the client.

   The message-length field specifies the length of the message,
   including the start-line.

   Details about the mrcp-version and message-length fields are given in
   Section 5.1.

   The method-name field identifies the specific request that the client
   is making to the server.  Each resource supports a subset of the
   MRCPv2 methods.  The subset for each resource is defined in the
   section of the specification for the corresponding resource.

   method-name    =    generic-method
                  /    synthesizer-method
                  /    recognizer-method
                  /    recorder-method
                  /    verifier-method

   The request-id field is a unique identifier representable as an
   unsigned 32-bit integer created by the client and sent to the server.
   Clients MUST utilize monotonically increasing request-ids for
   consecutive requests within an MRCP session.  The request-id space is
   linear (i.e., not mod(32)), so the space does not wrap, and validity
   can be checked with a simple unsigned comparison operation.  The
   client may choose any initial value for its first request, but a
   small integer is RECOMMENDED to avoid exhausting the space in long
   sessions.  If the server receives duplicate or out-of-order requests,
   the server MUST reject the request with a response code of 410.
   Since request-ids are scoped to the MRCP session, they are unique
   across all TCP connections and all resource channels in the session.

   The server resource MUST use the client-assigned identifier in its
   response to the request.  If the request does not complete

   synchronously, future asynchronous events associated with this
   request MUST carry the client-assigned request-id.

   request-id     =    1*10DIGIT

5.3.  Response

   After receiving and interpreting the request message for a method,
   the server resource responds with an MRCPv2 response message.  The
   response consists of a response line followed by the message header
   section and an optional message body containing data specific to the
   method.

   response-line  =    mrcp-version SP message-length SP request-id
                       SP status-code SP request-state CRLF

   The mrcp-version field MUST contain the version of the request if
   supported; otherwise, it MUST contain the highest version of MRCP
   supported by the server.

   The message-length field specifies the length of the message,
   including the start-line.

   Details about the mrcp-version and message-length fields are given in
   Section 5.1.

   The request-id used in the response MUST match the one sent in the
   corresponding request message.

   The status-code field is a 3-digit code representing the success or
   failure or other status of the request.

   status-code     =    3DIGIT

   The request-state field indicates if the action initiated by the
   Request is PENDING, IN-PROGRESS, or COMPLETE.  The COMPLETE status
   means that the request was processed to completion and that there
   will be no more events or other messages from that resource to the
   client with that request-id.  The PENDING status means that the
   request has been placed in a queue and will be processed in first-in-
   first-out order.  The IN-PROGRESS status means that the request is
   being processed and is not yet complete.  A PENDING or IN-PROGRESS
   status indicates that further Event messages may be delivered with
   that request-id.

   request-state    =  "COMPLETE"
                    /  "IN-PROGRESS"
                    /  "PENDING"

5.4.  Status Codes

   The status codes are classified under the Success (2xx), Client
   Failure (4xx), and Server Failure (5xx) codes.

     +------------+--------------------------------------------------+
     | Code       | Meaning                                          |
     +------------+--------------------------------------------------+
     | 200        | Success                                          |
     | 201        | Success with some optional header fields ignored |
     +------------+--------------------------------------------------+

                               Success (2xx)

   +--------+----------------------------------------------------------+
   | Code   | Meaning                                                  |
   +--------+----------------------------------------------------------+
   | 401    | Method not allowed                                       |
   | 402    | Method not valid in this state                           |
   | 403    | Unsupported header field                                 |
   | 404    | Illegal value for header field. This is the error for a  |
   |        | syntax violation.                                        |
   | 405    | Resource not allocated for this session or does not      |
   |        | exist                                                    |
   | 406    | Mandatory Header Field Missing                           |
   | 407    | Method or Operation Failed (e.g., Grammar compilation    |
   |        | failed in the recognizer. Detailed cause codes might be  |
   |        | available through a resource-specific header.)           |
   | 408    | Unrecognized or unsupported message entity               |
   | 409    | Unsupported Header Field Value. This is a value that is  |
   |        | syntactically legal but exceeds the implementation's     |
   |        | capabilities or expectations.                            |
   | 410    | Non-Monotonic or Out-of-order sequence number in request.|
   | 411-420| Reserved for future assignment                           |
   +--------+----------------------------------------------------------+

                           Client Failure (4xx)

              +------------+--------------------------------+
              | Code       | Meaning                        |
              +------------+--------------------------------+
              | 501        | Server Internal Error          |
              | 502        | Protocol Version not supported |
              | 503        | Reserved for future assignment |
              | 504        | Message too large              |
              +------------+--------------------------------+

                           Server Failure (5xx)

5.5.  Events

   The server resource may need to communicate a change in state or the
   occurrence of a certain event to the client.  These messages are used
   when a request does not complete immediately and the response returns
   a status of PENDING or IN-PROGRESS.  The intermediate results and
   events of the request are indicated to the client through the event
   message from the server.  The event message consists of an event
   header line followed by the message header section and an optional
   message body containing data specific to the event message.  The
   header line has the request-id of the corresponding request and
   status value.  The request-state value is COMPLETE if the request is
   done and this was the last event, else it is IN-PROGRESS.

   event-line       =  mrcp-version SP message-length SP event-name
                       SP request-id SP request-state CRLF

   The mrcp-version used here is identical to the one used in the
   Request/Response line and indicates the highest version of MRCP
   running on the server.

   The message-length field specifies the length of the message,
   including the start-line.

   Details about the mrcp-version and message-length fields are given in
   Section 5.1.

   The event-name identifies the nature of the event generated by the
   media resource.  The set of valid event names depends on the resource
   generating it.  See the corresponding resource-specific section of
   the document.

   event-name       =  synthesizer-event
                    /  recognizer-event
                    /  recorder-event
                    /  verifier-event

   The request-id used in the event MUST match the one sent in the
   request that caused this event.

   The request-state indicates whether the Request/Command causing this
   event is complete or still in progress and whether it is the same as
   the one mentioned in Section 5.3.  The final event for a request has
   a COMPLETE status indicating the completion of the request.

6.  MRCPv2 Generic Methods, Headers, and Result Structure

   MRCPv2 supports a set of methods and header fields that are common to
   all resources.  These are discussed here; resource-specific methods
   and header fields are discussed in the corresponding resource-
   specific section of the document.

6.1.  Generic Methods

   MRCPv2 supports two generic methods for reading and writing the state
   associated with a resource.

   generic-method      =    "SET-PARAMS"
                       /    "GET-PARAMS"

   These are described in the following subsections.

6.1.1.  SET-PARAMS

   The SET-PARAMS method, from the client to the server, tells the
   MRCPv2 resource to define parameters for the session, such as voice
   characteristics and prosody on synthesizers, recognition timers on
   recognizers, etc.  If the server accepts and sets all parameters, it
   MUST return a response status-code of 200.  If it chooses to ignore
   some optional header fields that can be safely ignored without
   affecting operation of the server, it MUST return 201.

   If one or more of the header fields being sent is incorrect, error
   403, 404, or 409 MUST be returned as follows:

   o  If one or more of the header fields being set has an illegal
      value, the server MUST reject the request with a 404 Illegal Value
      for Header Field.

   o  If one or more of the header fields being set is unsupported for
      the resource, the server MUST reject the request with a 403
      Unsupported Header Field, except as described in the next
      paragraph.

   o  If one or more of the header fields being set has an unsupported
      value, the server MUST reject the request with a 409 Unsupported
      Header Field Value, except as described in the next paragraph.

   If both error 404 and another error have occurred, only error 404
   MUST be returned.  If both errors 403 and 409 have occurred, but not
   error 404, only error 403 MUST be returned.

   If error 403, 404, or 409 is returned, the response MUST include the
   bad or unsupported header fields and their values exactly as they
   were sent from the client.  Session parameters modified using
   SET-PARAMS do not override parameters explicitly specified on
   individual requests or requests that are IN-PROGRESS.

   C->S:  MRCP/2.0 ... SET-PARAMS 543256
          Channel-Identifier:32AECB23433802@speechsynth
          Voice-gender:female
          Voice-variant:3

   S->C:  MRCP/2.0 ... 543256 200 COMPLETE
          Channel-Identifier:32AECB23433802@speechsynth

6.1.2.  GET-PARAMS

   The GET-PARAMS method, from the client to the server, asks the MRCPv2
   resource for its current session parameters, such as voice
   characteristics and prosody on synthesizers, recognition timers on
   recognizers, etc.  For every header field the client sends in the
   request without a value, the server MUST include the header field and
   its corresponding value in the response.  If no parameter header
   fields are specified by the client, then the server MUST return all
   the settable parameters and their values in the corresponding header
   section of the response, including vendor-specific parameters.  Such
   wildcard parameter requests can be very processing-intensive, since
   the number of settable parameters can be large depending on the
   implementation.  Hence, it is RECOMMENDED that the client not use the
   wildcard GET-PARAMS operation very often.  Note that GET-PARAMS
   returns header field values that apply to the whole session and not
   values that have a request-level scope.  For example, Input-Waveform-
   URI is a request-level header field and thus would not be returned by
   GET-PARAMS.

   If all of the header fields requested are supported, the server MUST
   return a response status-code of 200.  If some of the header fields
   being retrieved are unsupported for the resource, the server MUST
   reject the request with a 403 Unsupported Header Field.  Such a
   response MUST include the unsupported header fields exactly as they
   were sent from the client, without values.

   C->S:   MRCP/2.0 ... GET-PARAMS 543256
           Channel-Identifier:32AECB23433802@speechsynth
           Voice-gender:
           Voice-variant:
           Vendor-Specific-Parameters:com.example.param1;
                         com.example.param2

   S->C:   MRCP/2.0 ... 543256 200 COMPLETE
           Channel-Identifier:32AECB23433802@speechsynth
           Voice-gender:female
           Voice-variant:3
           Vendor-Specific-Parameters:com.example.param1="Company Name";
                         com.example.param2="124324234@example.com"

6.2.  Generic Message Headers

   All MRCPv2 header fields, which include both the generic-headers
   defined in the following subsections and the resource-specific header
   fields defined later, follow the same generic format as that given in
   Section 3.1 of RFC 5322 [RFC5322].  Each header field consists of a
   name followed by a colon (":") and the value.  Header field names are
   case-insensitive.  The value MAY be preceded by any amount of LWS
   (linear white space), though a single SP (space) is preferred.
   Header fields may extend over multiple lines by preceding each extra
   line with at least one SP or HT (horizontal tab).

   generic-field  = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *LWS field-content *( CRLF 1*LWS field-content)
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

   The field-content does not include any leading or trailing LWS (i.e.,
   linear white space occurring before the first non-whitespace
   character of the field-value or after the last non-whitespace
   character of the field-value).  Such leading or trailing LWS MAY be
   removed without changing the semantics of the field value.  Any LWS
   that occurs between field-content MAY be replaced with a single SP
   before interpreting the field value or forwarding the message
   downstream.

   MRCPv2 servers and clients MUST NOT depend on header field order.  It
   is RECOMMENDED to send general-header fields first, followed by
   request-header or response-header fields, and ending with the entity-
   header fields.  However, MRCPv2 servers and clients MUST be prepared
   to process the header fields in any order.  The only exception to
   this rule is when there are multiple header fields with the same name
   in a message.

   Multiple header fields with the same name MAY be present in a message
   if and only if the entire value for that header field is defined as a
   comma-separated list [i.e., #(values)].

   Since vendor-specific parameters may be order-dependent, it MUST be
   possible to combine multiple header fields of the same name into one
   "name:value" pair without changing the semantics of the message, by
   appending each subsequent value to the first, each separated by a
   comma.  The order in which header fields with the same name are
   received is therefore significant to the interpretation of the
   combined header field value, and thus an intermediary MUST NOT change
   the order of these values when a message is forwarded.

   generic-header      =    channel-identifier
                       /    accept
                       /    active-request-id-list
                       /    proxy-sync-id
                       /    accept-charset
                       /    content-type
                       /    content-id
                       /    content-base
                       /    content-encoding
                       /    content-location
                       /    content-length
                       /    fetch-timeout
                       /    cache-control
                       /    logging-tag
                       /    set-cookie
                       /    vendor-specific

6.2.1.  Channel-Identifier

   All MRCPv2 requests, responses, and events MUST contain the Channel-
   Identifier header field.  The value is allocated by the server when a
   control channel is added to the session and communicated to the
   client by the "a=channel" attribute in the SDP answer from the
   server.  The header field value consists of 2 parts separated by the
   '@' symbol.  The first part is an unambiguous string identifying the
   MRCPv2 session.  The second part is a string token that specifies one
   of the media processing resource types listed in Section 3.1.  The
   unambiguous string (first part) MUST be difficult to guess, unique
   among the resource instances managed by the server, and common to all
   resource channels with that server established through a single SIP
   dialog.

   channel-identifier  = "Channel-Identifier" ":" channel-id CRLF
   channel-id          = 1*alphanum "@" 1*alphanum

6.2.2.  Accept

   The Accept header field follows the syntax defined in [H14.1].  The
   semantics are also identical, with the exception that if no Accept
   header field is present, the server MUST assume a default value that
   is specific to the resource type that is being controlled.  This
   default value can be changed for a resource on a session by sending
   this header field in a SET-PARAMS method.  The current default value
   of this header field for a resource in a session can be found through
   a GET-PARAMS method.  This header field MAY occur on any request.

6.2.3.  Active-Request-Id-List

   In a request, this header field indicates the list of request-ids to
   which the request applies.  This is useful when there are multiple
   requests that are PENDING or IN-PROGRESS and the client wants this
   request to apply to one or more of these specifically.

   In a response, this header field returns the list of request-ids that
   the method modified or affected.  There could be one or more requests
   in a request-state of PENDING or IN-PROGRESS.  When a method
   affecting one or more PENDING or IN-PROGRESS requests is sent from
   the client to the server, the response MUST contain the list of
   request-ids that were affected or modified by this command in its
   header section.

   The Active-Request-Id-List is only used in requests and responses,
   not in events.

   For example, if a STOP request with no Active-Request-Id-List is sent
   to a synthesizer resource that has one or more SPEAK requests in the
   PENDING or IN-PROGRESS state, all SPEAK requests MUST be cancelled,
   including the one IN-PROGRESS.  The response to the STOP request
   contains in the Active-Request-Id-List value the request-ids of all
   the SPEAK requests that were terminated.  After sending the STOP
   response, the server MUST NOT send any SPEAK-COMPLETE or RECOGNITION-
   COMPLETE events for the terminated requests.

   active-request-id-list  =  "Active-Request-Id-List" ":"
                              request-id *("," request-id) CRLF

6.2.4.  Proxy-Sync-Id

   When any server resource generates a "barge-in-able" event, it also
   generates a unique tag.  The tag is sent as this header field's value
   in an event to the client.  The client then acts as an intermediary
   among the server resources and sends a BARGE-IN-OCCURRED method to
   the synthesizer server resource with the Proxy-Sync-Id it received

   from the server resource.  When the recognizer and synthesizer
   resources are part of the same session, they may choose to work
   together to achieve quicker interaction and response.  Here, the
   Proxy-Sync-Id helps the resource receiving the event, intermediated
   by the client, to decide if this event has been processed through a
   direct interaction of the resources.  This header field MAY occur
   only on events and the BARGE-IN-OCCURRED method.  The name of this
   header field contains the word 'proxy' only for historical reasons
   and does not imply that a proxy server is involved.

   proxy-sync-id    =  "Proxy-Sync-Id" ":" 1*VCHAR CRLF

6.2.5.  Accept-Charset

   See [H14.2].  This specifies the acceptable character sets for
   entities returned in the response or events associated with this
   request.  This is useful in specifying the character set to use in
   the Natural Language Semantic Markup Language (NLSML) results of a
   RECOGNITION-COMPLETE event.  This header field is only used on
   requests.

6.2.6.  Content-Type

   See [H14.17].  MRCPv2 supports a restricted set of registered media
   types for content, including speech markup, grammar, and recognition
   results.  The content types applicable to each MRCPv2 resource-type
   are specified in the corresponding section of the document and are
   registered in the MIME Media Types registry maintained by IANA.  The
   multipart content type "multipart/mixed" is supported to communicate
   multiple of the above mentioned contents, in which case the body
   parts MUST NOT contain any MRCPv2-specific header fields.  This
   header field MAY occur on all messages.

   content-type     =    "Content-Type" ":" media-type-value CRLF

   media-type-value =    type "/" subtype *( ";" parameter )

   type             =    token

   subtype          =    token

   parameter        =    attribute "=" value

   attribute        =    token

   value            =    token / quoted-string

6.2.7.  Content-ID

   This header field contains an ID or name for the content by which it
   can be referenced.  This header field operates according to the
   specification in RFC 2392 [RFC2392] and is required for content
   disambiguation in multipart messages.  In MRCPv2, whenever the
   associated content is stored by either the client or the server, it
   MUST be retrievable using this ID.  Such content can be referenced
   later in a session by addressing it with the 'session' URI scheme
   described in Section 13.6.  This header field MAY occur on all
   messages.

6.2.8.  Content-Base

   The Content-Base entity-header MAY be used to specify the base URI
   for resolving relative URIs within the entity.

   content-base      = "Content-Base" ":" absoluteURI CRLF

   Note, however, that the base URI of the contents within the entity-
   body may be redefined within that entity-body.  An example of this
   would be multipart media, which in turn can have multiple entities
   within it.  This header field MAY occur on all messages.

6.2.9.  Content-Encoding

   The Content-Encoding entity-header is used as a modifier to the
   Content-Type.  When present, its value indicates what additional
   content encoding has been applied to the entity-body, and thus what
   decoding mechanisms must be applied in order to obtain the Media Type
   referenced by the Content-Type header field.  Content-Encoding is
   primarily used to allow a document to be compressed without losing
   the identity of its underlying media type.  Note that the SIP session
   can be used to determine accepted encodings (see Section 7).  This
   header field MAY occur on all messages.

   content-encoding  = "Content-Encoding" ":"
                       *WSP content-coding
                       *(*WSP "," *WSP content-coding *WSP )
                       CRLF

   Content codings are defined in [H3.5].  An example of its use is
   Content-Encoding:gzip

   If multiple encodings have been applied to an entity, the content
   encodings MUST be listed in the order in which they were applied.

6.2.10.  Content-Location

   The Content-Location entity-header MAY be used to supply the resource
   location for the entity enclosed in the message when that entity is
   accessible from a location separate from the requested resource's
   URI.  Refer to [H14.14].

   content-location  =  "Content-Location" ":"
                        ( absoluteURI / relativeURI ) CRLF

   The Content-Location value is a statement of the location of the
   resource corresponding to this particular entity at the time of the
   request.  This header field is provided for optimization purposes
   only.  The receiver of this header field MAY assume that the entity
   being sent is identical to what would have been retrieved or might
   already have been retrieved from the Content-Location URI.

   For example, if the client provided a grammar markup inline, and it
   had previously retrieved it from a certain URI, that URI can be
   provided as part of the entity, using the Content-Location header
   field.  This allows a resource like the recognizer to look into its
   cache to see if this grammar was previously retrieved, compiled, and
   cached.  In this case, it might optimize by using the previously
   compiled grammar object.

   If the Content-Location is a relative URI, the relative URI is
   interpreted relative to the Content-Base URI.  This header field MAY
   occur on all messages.

6.2.11.  Content-Length

   This header field contains the length of the content of the message
   body (i.e., after the double CRLF following the last header field).
   Unlike in HTTP, it MUST be included in all messages that carry
   content beyond the header section.  If it is missing, a default value
   of zero is assumed.  Otherwise, it is interpreted according to
   [H14.13].  When a message having no use for a message body contains
   one, i.e., the Content-Length is non-zero, the receiver MUST ignore
   the content of the message body.  This header field MAY occur on all
   messages.

   content-length  =  "Content-Length" ":" 1*19DIGIT CRLF

6.2.12.  Fetch Timeout

   When the recognizer or synthesizer needs to fetch documents or other
   resources, this header field controls the corresponding URI access
   properties.  This defines the timeout for content that the server may

   need to fetch over the network.  The value is interpreted to be in
   milliseconds and ranges from 0 to an implementation-specific maximum
   value.  It is RECOMMENDED that servers be cautious about accepting
   long timeout values.  The default value for this header field is
   implementation specific.  This header field MAY occur in DEFINE-
   GRAMMAR, RECOGNIZE, SPEAK, SET-PARAMS, or GET-PARAMS.

   fetch-timeout       =   "Fetch-Timeout" ":" 1*19DIGIT CRLF

6.2.13.  Cache-Control

   If the server implements content caching, it MUST adhere to the cache
   correctness rules of HTTP 1.1 [RFC2616] when accessing and caching
   stored content.  In particular, the "expires" and "cache-control"
   header fields of the cached URI or document MUST be honored and take
   precedence over the Cache-Control defaults set by this header field.
   The Cache-Control directives are used to define the default caching
   algorithms on the server for the session or request.  The scope of
   the directive is based on the method it is sent on.  If the directive
   is sent on a SET-PARAMS method, it applies for all requests for
   external documents the server makes during that session, unless it is
   overridden by a Cache-Control header field on an individual request.
   If the directives are sent on any other requests, they apply only to
   external document requests the server makes for that request.  An
   empty Cache-Control header field on the GET-PARAMS method is a
   request for the server to return the current Cache-Control directives
   setting on the server.  This header field MAY occur only on requests.

   cache-control    =    "Cache-Control" ":"
                         [*WSP cache-directive
                         *( *WSP "," *WSP cache-directive *WSP )]
                         CRLF

   cache-directive     = "max-age" "=" delta-seconds
                       / "max-stale" [ "=" delta-seconds ]
                       / "min-fresh" "=" delta-seconds

   delta-seconds       = 1*19DIGIT

   Here, delta-seconds is a decimal time value specifying the number of
   seconds since the instant the message response or data was received
   by the server.

   The different cache-directive options allow the client to ask the
   server to override the default cache expiration mechanisms:

   max-age        Indicates that the client can tolerate the server
                  using content whose age is no greater than the
                  specified time in seconds.  Unless a "max-stale"
                  directive is also included, the client is not willing
                  to accept a response based on stale data.

   min-fresh      Indicates that the client is willing to accept a
                  server response with cached data whose expiration is
                  no less than its current age plus the specified time
                  in seconds.  If the server's cache time-to-live
                  exceeds the client-supplied min-fresh value, the
                  server MUST NOT utilize cached content.

   max-stale      Indicates that the client is willing to allow a server
                  to utilize cached data that has exceeded its
                  expiration time.  If "max-stale" is assigned a value,
                  then the client is willing to allow the server to use
                  cached data that has exceeded its expiration time by
                  no more than the specified number of seconds.  If no
                  value is assigned to "max-stale", then the client is
                  willing to allow the server to use stale data of any
                  age.

   If the server cache is requested to use stale response/data without
   validation, it MAY do so only if this does not conflict with any
   "MUST"-level requirements concerning cache validation (e.g., a "must-
   revalidate" Cache-Control directive in the HTTP 1.1 specification
   pertaining to the corresponding URI).

   If both the MRCPv2 Cache-Control directive and the cached entry on
   the server include "max-age" directives, then the lesser of the two
   values is used for determining the freshness of the cached entry for
   that request.

6.2.14.  Logging-Tag

   This header field MAY be sent as part of a SET-PARAMS/GET-PARAMS
   method to set or retrieve the logging tag for logs generated by the
   server.  Once set, the value persists until a new value is set or the
   session ends.  The MRCPv2 server MAY provide a mechanism to create
   subsets of its output logs so that system administrators can examine
   or extract only the log file portion during which the logging tag was
   set to a certain value.

   It is RECOMMENDED that clients include in the logging tag information
   to identify the MRCPv2 client User Agent, so that one can determine
   which MRCPv2 client request generated a given log message at the
   server.  It is also RECOMMENDED that MRCPv2 clients not log

   personally identifiable information such as credit card numbers and
   national identification numbers.

   logging-tag    = "Logging-Tag" ":" 1*UTFCHAR CRLF

6.2.15.  Set-Cookie

   Since the associated HTTP client on an MRCPv2 server fetches
   documents for processing on behalf of the MRCPv2 client, the cookie
   store in the HTTP client of the MRCPv2 server is treated as an
   extension of the cookie store in the HTTP client of the MRCPv2
   client.  This requires that the MRCPv2 client and server be able to
   synchronize their common cookie store as needed.  To enable the
   MRCPv2 client to push its stored cookies to the MRCPv2 server and get
   new cookies from the MRCPv2 server stored back to the MRCPv2 client,
   the Set-Cookie entity-header field MAY be included in MRCPv2 requests
   to update the cookie store on a server and be returned in final
   MRCPv2 responses or events to subsequently update the client's own
   cookie store.  The stored cookies on the server persist for the
   duration of the MRCPv2 session and MUST be destroyed at the end of
   the session.  To ensure support for cookies, MRCPv2 clients and
   servers MUST support the Set-Cookie entity-header field.

   Note that it is the MRCPv2 client that determines which, if any,
   cookies are sent to the server.  There is no requirement that all
   cookies be shared.  Rather, it is RECOMMENDED that MRCPv2 clients
   communicate only cookies needed by the MRCPv2 server to process its
   requests.

 set-cookie      =       "Set-Cookie:" cookies CRLF
 cookies         =       cookie *("," *LWS cookie)
 cookie          =       attribute "=" value *(";" cookie-av)
 cookie-av       =       "Comment" "=" value
                 /       "Domain" "=" value
                 /       "Max-Age" "=" value
                 /       "Path" "=" value
                 /       "Secure"
                 /       "Version" "=" 1*19DIGIT
                 /       "Age" "=" delta-seconds

 set-cookie        = "Set-Cookie:" SP set-cookie-string
 set-cookie-string = cookie-pair *( ";" SP cookie-av )
 cookie-pair       = cookie-name "=" cookie-value
 cookie-name       = token
 cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
 token             = <token, defined in [RFC2616], Section 2.2>

 cookie-av         = expires-av / max-age-av / domain-av /
                      path-av / secure-av / httponly-av /
                      extension-av / age-av
 expires-av        = "Expires=" sane-cookie-date
 sane-cookie-date  = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
 max-age-av        = "Max-Age=" non-zero-digit *DIGIT
 non-zero-digit    = %x31-39
 domain-av         = "Domain=" domain-value
 domain-value      = <subdomain>
 path-av           = "Path=" path-value
 path-value        = <any CHAR except CTLs or ";">
 secure-av         = "Secure"
 httponly-av       = "HttpOnly"
 extension-av      = <any CHAR except CTLs or ";">
 age-av            = "Age=" delta-seconds

   The Set-Cookie header field is specified in RFC 6265 [RFC6265].  The
   "Age" attribute is introduced in this specification to indicate the
   age of the cookie and is OPTIONAL.  An MRCPv2 client or server MUST
   calculate the age of the cookie according to the age calculation
   rules in the HTTP/1.1 specification [RFC2616] and append the "Age"
   attribute accordingly.  This attribute is provided because time may
   have passed since the client received the cookie from an HTTP server.
   Rather than having the client reduce Max-Age by the actual age, it
   passes Max-Age verbatim and appends the "Age" attribute, thus
   maintaining the cookie as received while still accounting for the
   fact that time has passed.

   The MRCPv2 client or server MUST supply defaults for the "Domain" and
   "Path" attributes, as specified in RFC 6265, if they are omitted by
   the HTTP origin server.  Note that there is no leading dot present in
   the "Domain" attribute value in this case.  Although an explicitly
   specified "Domain" value received via the HTTP protocol may be
   modified to include a leading dot, an MRCPv2 client or server MUST
   NOT modify the "Domain" value when received via the MRCPv2 protocol.

   An MRCPv2 client or server MAY combine multiple cookie header fields
   of the same type into a single "field-name:field-value" pair as
   described in Section 6.2.

   The Set-Cookie header field MAY be specified in any request that
   subsequently results in the server performing an HTTP access.  When a
   server receives new cookie information from an HTTP origin server,
   and assuming the cookie store is modified according to RFC 6265, the
   server MUST return the new cookie information in the MRCPv2 COMPLETE
   response or event, as appropriate, to allow the client to update its
   own cookie store.

   The SET-PARAMS request MAY specify the Set-Cookie header field to
   update the cookie store on a server.  The GET-PARAMS request MAY be
   used to return the entire cookie store of "Set-Cookie" type cookies
   to the client.

6.2.16.  Vendor-Specific Parameters

   This set of header fields allows for the client to set or retrieve
   vendor-specific parameters.

   vendor-specific          =    "Vendor-Specific-Parameters" ":"
                                 [vendor-specific-av-pair
                                 *(";" vendor-specific-av-pair)] CRLF

   vendor-specific-av-pair  = vendor-av-pair-name "="
                              value

   vendor-av-pair-name     = 1*UTFCHAR

   Header fields of this form MAY be sent in any method (request) and
   are used to manage implementation-specific parameters on the server
   side.  The vendor-av-pair-name follows the reverse Internet Domain
   Name convention (see Section 13.1.6 for syntax and registration
   information).  The value of the vendor attribute is specified after
   the "=" symbol and MAY be quoted.  For example:

   com.example.companyA.paramxyz=256
   com.example.companyA.paramabc=High
   com.example.companyB.paramxyz=Low

   When used in GET-PARAMS to get the current value of these parameters
   from the server, this header field value MAY contain a semicolon-
   separated list of implementation-specific attribute names.

6.3.  Generic Result Structure

   Result data from the server for the Recognizer and Verifier resources
   is carried as a typed media entity in the MRCPv2 message body of
   various events.  The Natural Language Semantics Markup Language
   (NLSML), an XML markup based on an early draft from the W3C, is the
   default standard for returning results back to the client.  Hence,
   all servers implementing these resource types MUST support the media
   type 'application/nlsml+xml'.  The Extensible MultiModal Annotation
   (EMMA) [W3C.REC-emma-20090210] format can be used to return results
   as well.  This can be done by negotiating the format at session
   establishment time with SDP (a=resultformat:application/emma+xml) or
   with SIP (Allow/Accept).  With SIP, for example, if a client wants

   results in EMMA, an MRCPv2 server can route the request to another
   server that supports EMMA by inspecting the SIP header fields, rather
   than having to inspect the SDP.

   MRCPv2 uses this representation to convey content among the clients
   and servers that generate and make use of the markup.  MRCPv2 uses
   NSLML specifically to convey recognition, enrollment, and
   verification results between the corresponding resource on the MRCPv2
   server and the MRCPv2 client.  Details of this result format are
   fully described in Section 6.3.1.

   Content-Type:application/nlsml+xml
   Content-Length:...

   <?xml version="1.0"?>
   <result xmlns="urn:ietf:params:xml:ns:mrcpv2"
           xmlns:ex="http://www.example.com/example"
           grammar="http://theYesNoGrammar">
       <interpretation>
           <instance>
                   <ex:response>yes</ex:response>
           </instance>
           <input>OK</input>
       </interpretation>
   </result>

                              Result Example

6.3.1.  Natural Language Semantics Markup Language

   The Natural Language Semantics Markup Language (NLSML) is an XML data
   structure with elements and attributes designed to carry result
   information from recognizer (including enrollment) and verifier
   resources.  The normative definition of NLSML is the RelaxNG schema
   in Section 16.1.  Note that the elements and attributes of this
   format are defined in the MRCPv2 namespace.  In the result structure,
   they must either be prefixed by a namespace prefix declared within
   the result or must be children of an element identified as belonging
   to the respective namespace.  For details on how to use XML
   Namespaces, see [W3C.REC-xml-names11-20040204].  Section 2 of
   [W3C.REC-xml-names11-20040204] provides details on how to declare
   namespaces and namespace prefixes.

   The root element of NLSML is <result>.  Optional child elements are
   <interpretation>, <enrollment-result>, and <verification-result>, at
   least one of which must be present.  A single <result> MAY contain
   any or all of the optional child elements.  Details of the <result>
   and <interpretation> elements and their subelements and attributes

   can be found in Section 9.6.  Details of the <enrollment-result>
   element and its subelements can be found in Section 9.7.  Details of
   the <verification-result> element and its subelements can be found in
   Section 11.5.2.