draft-ietf-speechsc-mrcpv2-05.txt

MRCP V2版协议

       504       Message too large.  
     
     
 5.3. Event 
     
    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. Events have the request-id of the 
    request that is in progress and generating these events and status 
    value. The status 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 
     

  
 S Shanmugham                  IETF-Draft                       Page 20 

                            MRCPv2 Protocol              October, 2004 

    The mrcp-version used here is identical to the one used in the 
    Request/Response Line and indicates the version of MRCPv2 protocol 
    running on the server. 
     
    The request-id used in the event MUST match the one sent in the 
    request that caused this event. 
     
    The request-state indicates if the Request/Command causing this 
    event is complete or still in progress, and is the same as the one 
    mentioned in section 5.3. The final event will contain a COMPLETE 
    status indicating the completion of the request. 
     
    The event-name identifies the nature of the event generated by the 
    media resource. The set of valid event names are dependent on the 
    resource generating it, and will be addressed in later sections. 
     
      event-name       =  synthesizer-event 
                       /  recognizer-event 
                       /  recorder-event 
                       /  verifier-event 
                       /  extension-event 
     
      extension-event  =  1*(ALPHA /"-") 
     
 6.   MRCP Generic Features 
    The protocol supports a set of methods, and headers that are common 
    to all resources and are discussed in this section 
     
      generic-method      =    "SET-PARAMS" 
                          /    "GET-PARAMS" 
     
 6.1. Generic Message Headers 
     
    MRCPv2 header fields, which include general-header (section 5.5) and 
    resource-specific-header (section 7.4 and section 8.4), follow the 
    same generic format as that given in Section 3.1 of RFC 822 [8]. 
    Each header field consists of a name followed by a colon (":") and 
    the field value. Field names are case-insensitive. The field value 
    MAY be preceded by any amount of LWS, though a single SP is 
    preferred. Header fields can be extended over multiple lines by 
    preceding each extra line with at least one SP or HT. 
     
      message-header = 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: 
    linear white space occurring before the first non-whitespace 
  
 S Shanmugham                  IETF-Draft                       Page 21 

                            MRCPv2 Protocol              October, 2004 

    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. 
     
    The order in which header fields with differing field names are 
    received is not significant. However, it is "good practice" to send 
    general-header fields first, followed by request-header or response-
    header fields, and ending with the entity-header fields. 
     
    Multiple message-header fields with the same field-name MAY be 
    present in a message if and only if the entire field-value for that 
    header field is defined as a comma-separated list [i.e., #(values)]. 
     
    It MUST be possible to combine the multiple header fields into one 
    "field-name: field-value" pair, without changing the semantics of 
    the message, by appending each subsequent field-value to the first, 
    each separated by a comma. The order in which header fields with the 
    same field-name are received is therefore significant to the 
    interpretation of the combined field value, and thus a proxy MUST 
    NOT change the order of these field values when a message is 
    forwarded. 
     
      generic-header      =    channel-identifier 
                          /    active-request-id-list 
                          /    proxy-sync-id 
                          /    content-id 
                          /    content-type 
                          /    content-length 
                          /    content-base 
                          /    content-location 
                          /    content-encoding 
                          /    cache-control 
                          /    logging-tag  
                          /    set-cookie  
                          /    set-cookie2 
                          /    vendor-specific      
     
    Header field          where     s  g  A 
    __________________________________________________________ 
    Channel-Identifier      R       m  m  m 
    Channel-Identifier      r       m  m  m 
    Active-Request-Id-List  R       -  -  O 
    Active-Request-Id-List  r       -  -  O 
    Proxy-Sync-Id           R       -  -  O 
    Content-Id              R       o  o  o 
    Content-Type            R       o  o  o 
    Content-Length          R       o  o  o 
    Content-Base            R       o  o  o 
  
 S Shanmugham                  IETF-Draft                       Page 22 

                            MRCPv2 Protocol              October, 2004 

    Content-Location        R       o  o  o 
    Content-Encoding        R       o  o  o 
    Cache-Control           R       o  o  o 
    Logging-Tag             R       o  o  - 
    Set-Cookie              R       o  o  o 
    Set-Cookie2             R       o  o  o 
    Vendor-Specific         R       o  o  o 
     
    Legend:   (s) - SET-PARAMS, (g) - GET-PARAMS, (A) - Generic MRCP 
    message, (B) - BARGE-IN-OCCURED, (C) - START-OF-SPEECH, (o) - 
    Optional(Refer text for further constraints), (R) - Request, (r) - 
    Response 
     
    All headers in MRCPv2 will be case insensitive consistent with HTTP 
    and SIP protocol header definitions. 
     
 Channel-Identifier 
     
    All MRCPv2 methods, responses and events MUST contain the Channel-
    Identifier header field. The value of this field is a hexadecimal 
    string and is allocated by the server when the control channel was 
    added to the session through a SDP offer/answer exchange. This field 
    consists of 2 parts separated by the '@' symbol. The first part is a 
    32 bit hexadecimal integer that is positive, identifying the MRCP 
    session. The second part is a string token which specifies one of 
    the media processing resource types listed in Section 3.2. The 
    hexadecimal digit string MUST BE unique within the server and is 
    common to all resource channels established through a single SIP 
    session. 
     
      channel-identifier  = "Channel-Identifier" ":" channel-id CRLF 
     
      Channel-id          = 1*HEXDIG "@" 1*VCHAR 
     
 Active-Request-Id-List 
     
    In a request, this field indicates the list of request-ids that the 
    request should apply to. This is useful when there are multiple 
    Requests that are PENDING or IN-PROGRESS and you want this request 
    to apply to one or more of these specifically.  
     
    In a response, this field returns the list of request-ids that the 
    operation modified or affected. There could be one or more requests 
    that returned 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 field. 
     
    The active-request-id-list is only used in requests and responses, 
    not in events. 
  
 S Shanmugham                  IETF-Draft                       Page 23 

                            MRCPv2 Protocol              October, 2004 

     
    For example, if a STOP request with no active-request-id-list is 
    sent to a synthesizer resource(a wildcard STOP) which has one or 
    more SPEAK requests in the PENDING or IN-PROGRESS state, all SPEAK 
    requests MUST be cancelled, including the one IN-PROGRESS and the 
    response to the STOP request would contain the request-id of all the 
    SPEAK requests that were terminated in the active-request-id-list.  
    In this case, no SPEAK-COMPLETE or RECOGNITION-COMPLETE events will 
    be sent for these terminated requests. 
     
      active-request-id-list  =  "Active-Request-Id-List" ":"  
                                  request-id *("," request-id) CRLF 
     
 Proxy-Sync-Id 
     
    When any server resource generates a barge-in-able event, it will 
    generate a unique Tag and send it as a header field in an event to 
    the client. The client then acts as a proxy to the server resource 
    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, proxied by the client, to decide if 
    this event has been processed through a direct interaction of the 
    resources. 
     
      proxy-sync-id    =  "Proxy-Sync-Id" ":" 1*VCHAR CRLF    
     
 Accept-Charset 
     
    See [H14.2]. This specifies the acceptable character set for 
    entities returned in the response or events associated with this 
    request. This is useful in specifying the character set to use in 
    the NLSML results of a RECOGNITION-COMPLETE event.  
     
 Content-Type 
     
    See [H14.17]. Note that the content types suitable for MRCPv2 are 
    restricted to speech markup, grammar, recognition results etc. and 
    are specified later in this document. The multi-part content type 
    "multi-part/mixed" is supported to communicate multiple of the above 
    mentioned contents, in which case the body parts cannot contain any 
    MRCPv2 specific headers. 
     
 Content-Id 
     
    This field contains an ID or name for the content, by which it can 
    be referred to.  The definition of this field is in full compliance 
    with RFC 2111[15] and is needed in multi-part messages. In MRCPv2 
    whenever the content needs to be stored, by either the client or the 
  
 S Shanmugham                  IETF-Draft                       Page 24 

                            MRCPv2 Protocol              October, 2004 

    server, it is stored associated with this ID. Such content can be 
    referenced during the session in URI form using the session: URI 
    scheme described in a later section.  
     
 Content-Base 
     
    The content-base entity-header field may be used to specify the base 
    URI for resolving relative URLs 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 a multi-part MIME entity, which in turn can have multiple 
    entities within it. 
     
 Content-Encoding 
     
    The content-encoding entity-header field is used as a modifier to 
    the media-type. When present, its value indicates what additional 
    content coding have 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.