Subject: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?)

From: "Eric Burger" <[email-masked]>
Date: Mon, 17 Oct 2005 16:51:37 -0400

My logic, which may be flawed, is that we want to be able to achieve
these objectives.
  o  Ensure the trivial ability to negotiate other result
     formats, such as EMMA.
  o  Ensure the server knows what format the client wants.
  o  Ensure the client knows the server supports the format
     the client wants, before it is "too late".

I would offer that using SET-PARAMS is "too late", in that the client
and server has already spent the effort to establish the RTP sessions.
It would be a pity to then tear it all down when the client finds out
the server does not support the format of choice.

One can negotiating the format at session establishment time with SDP
(a=resultformat:application/emma-xml) or with SIP (Allow/Accept).  I
would offer that it is easier to implement, and makes MRCPv2 (SIP)
proxies easier if we do the negotiation at the SIP level.  For example,
if a client wants results in EMMA, a MRCPv2 proxy can route the request
to a server that supports EMMA by inspecting the SIP headers, rather
than having to dive in to the SDP.

While the preceding paragraph indicates my preference for using the SIP
negotiation mechanism, there still is the case where both the client and
server support NLSML and EMMA.

++++ THE QUESTION ++++
Is there a realistic use case where the client, in any given session,
would want to use multiple result formats?  That is, something like,
"RECOGNIZE this and give me the result in EMMA" and then later issue
something like, "RECOGNIZE that and give me the result in NLSML"?

If so, then we would *also* need a per-recognition / SET-PARAMS header
for the result type.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shanmugham, Saravanan
Sent: Wednesday, September 28, 2005 2:36 PM
To: Brett Gavagni; Jerry Carter
Cc: IETF SPEECHSC (E-mail); [email-masked]; Baggia Paolo
Subject: RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotation
markuplanguagesupport?

Would something like the HTTP "Accept" header address these and other
similar concerns.
The RECOGNIZE request can then carry this header in it to specify an
alternative to NLSML.

Sarvi 

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of Brett Gavagni
     Sent: Saturday, September 24, 2005 7:51 AM
     To: Jerry Carter
     Cc: IETF SPEECHSC (E-mail); [email-masked]; Baggia Paolo
     Subject: Re: [Speechsc] EMMA: Extensible 
     MultiModalAnnotation markuplanguagesupport?
     
     Hi,
     
     I agree that the ability for a client to request the 
     format of the recognizer result data content would be useful.
     
     I would prefer to see this function defined in a 
     consistent manner with the current draft specification; by 
     a client request to enable a session parameter via a 
     header (ie. "Result-Data-Type") in a SET-PARAMS or 
     RECOGNIZE request, rather than an attribute used for 
     RECOGNIZER session negotiation/update. The server should 
     then respond with an accept or reject response as it does 
     today for other client requested parameter values. 
     Currently, the draft specification doesn't expose the MRCP 
     resource configurable parameters in the SDP.
     
     I don't think that enabling platform-specific formats 
     facilitates the adoption of a standard specification for 
     speech resources. I  believe that the specification should 
     continue to address the required supported formats and 
     require new draft iterations including the updated 
     specifications. The updated draft iterations would 
     continue to assist with potential client/server 
     interoperability issues.
     
     Thanks,
     
     Brett Gavagni
     WebSphere Voice Server Development
     http://www-306.ibm.com/software/pervasive/voice_server/
     [email-masked]

     
     Jerry Carter <[email-masked]>
     Sent by: [email-masked]
     09/23/2005 11:42 PM
     
     To
     Baggia Paolo <[email-masked]> cc "IETF SPEECHSC 
     \(E-mail\)" <[email-masked]> Subject
     Re: [Speechsc] EMMA: Extensible MultiModal Annotation 
     markuplanguagesupport?

     
     I agree that minor changes made today will prevent the need for an 
     amended document in the very near future.  Providing for content 
     negotiation solves both the EMMA issue and allows for future or 
     platform-specific return formats without requiring that the 
     specification be iterated.
     
     Of the two suggestions, I prefer the SDP extension as the 
     return format 
     is analogous to other SIP media type negotiations.

     On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote:
     > the last answers and discussions in this thread seems to confirm
     > that the direction of MRCPv2 is to allow the use of EMMA when
     > it will become a W3C Recommendation. Some text should be added
     > in the future release to say that.
     > This is fine from us point of view, but a mechanism for asking
     > a different result format is not present in the current draft.
     >
     > We think to add that mechanism will allow a smooth transition
     > from the current situation: always result in 
     "application/nlsml+xml",
     > to a future one with results in EMMA.
     >
     > Would it be possible to consider this "negotiation" of the output
     > result in the next draft?
     >
     > There are different options to implement it:
     > a) to extend SDP to leave taht outside of MRCPv2 core protocol
     > E.g.
     > a=recogResultFormat:application/nlsml+xml
     > if present it sets the recognition result for a whole MRCP
     > session.
     >
     > b) to add a new recognizer header to set the result format
     >    for that specific recognition turn.
     >
     > What do you think?
     >
     > We are aware the draft is near to be closed, but we think this
     > will help the passage from NLSML to EMMA.
     >
     > Regards,
     > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo)

     _______________________________________________
     Speechsc mailing list
     [email-masked]
     https://www1.ietf.org/mailman/listinfo/speechsc

     _______________________________________________
     Speechsc mailing list
     [email-masked]
     https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 18 Oct 2005 17:57:13 -0700

I suggest that we do both. 
The SIP Alow/Accept header during MRCP session setup for server
discovery and routing.
We then add support for the Accept header in MRCPv2 messages. I suspect
this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS.
And can be used in the case where the client or the server can do both.

What do you think.

Sarvi 

     -----Original Message-----
     From: Eric Burger [mailto:[email-masked]] 
     Sent: Monday, October 17, 2005 1:52 PM
     To: Shanmugham, Saravanan; Brett Gavagni
     Cc: IETF SPEECHSC (E-mail)
     Subject: Question on negotiating EMMA (was RE: [Speechsc] 
     EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
     
     My logic, which may be flawed, is that we want to be able 
     to achieve these objectives.
       o  Ensure the trivial ability to negotiate other result
          formats, such as EMMA.
       o  Ensure the server knows what format the client wants.
       o  Ensure the client knows the server supports the format
          the client wants, before it is "too late".
     
     I would offer that using SET-PARAMS is "too late", in that 
     the client and server has already spent the effort to 
     establish the RTP sessions.
     It would be a pity to then tear it all down when the 
     client finds out the server does not support the format of choice.
     
     One can negotiating the format at session establishment 
     time with SDP
     (a=resultformat:application/emma-xml) or with SIP 
     (Allow/Accept).  I would offer that it is easier to 
     implement, and makes MRCPv2 (SIP) proxies easier if we do 
     the negotiation at the SIP level.  For example, if a 
     client wants results in EMMA, a MRCPv2 proxy can route the 
     request to a server that supports EMMA by inspecting the 
     SIP headers, rather than having to dive in to the SDP.
     
     While the preceding paragraph indicates my preference for 
     using the SIP negotiation mechanism, there still is the 
     case where both the client and server support NLSML and EMMA.
     
     ++++ THE QUESTION ++++
     Is there a realistic use case where the client, in any 
     given session, would want to use multiple result formats?  
     That is, something like, "RECOGNIZE this and give me the 
     result in EMMA" and then later issue something like, 
     "RECOGNIZE that and give me the result in NLSML"?
     
     If so, then we would *also* need a per-recognition / 
     SET-PARAMS header for the result type.
     
     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of 
     Shanmugham, Saravanan
     Sent: Wednesday, September 28, 2005 2:36 PM
     To: Brett Gavagni; Jerry Carter
     Cc: IETF SPEECHSC (E-mail); [email-masked]; Baggia Paolo
     Subject: RE: [Speechsc] EMMA: 
     ExtensibleMultiModalAnnotation markuplanguagesupport?
     
     Would something like the HTTP "Accept" header address 
     these and other similar concerns.
     The RECOGNIZE request can then carry this header in it to 
     specify an alternative to NLSML.
     
     Sarvi 
     
          -----Original Message-----
          From: [email-masked] 
          [mailto:[email-masked]] On Behalf Of Brett Gavagni
          Sent: Saturday, September 24, 2005 7:51 AM
          To: Jerry Carter
          Cc: IETF SPEECHSC (E-mail); 
     [email-masked]; Baggia Paolo
          Subject: Re: [Speechsc] EMMA: Extensible 
          MultiModalAnnotation markuplanguagesupport?
          
          Hi,

          
          
          Thanks,
          
          Brett Gavagni

          
          
          To

          
          I agree that minor changes made today will prevent 
     the need for an 
          amended document in the very near future.  Providing 
     for content 
          negotiation solves both the EMMA issue and allows for 
     future or 
          platform-specific return formats without requiring that the 
          specification be iterated.

          "application/nlsml+xml",