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

From: Baggia Paolo <[email-masked]>
Date: Wed, 19 Oct 2005 13:54:06 +0200

Eric,
 
I'd like to answer first to the precise question you raised
below.
 
The use case is real, but the matter is between NLSML
and EMMA, but between a raw result and a detailed result.
I can see very well an application that uses a certain level
of information in all the normal ASR turns, but in some
specific one the detail need to be more precise. So the
client might ask to return results in a different format
then the normal one.
 
Other people are working to give a more thorough answer
on the whole concern.
 
Paolo
     -----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?)
        
     ++++ 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.

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 19 Oct 2005 14:06:08 -0400

We may all agree.

SDP is the wrong place for this.

However, SIP is the right place for such negotiations.

I would offer, in comment to one of the suggestions below, that the
client cannot determine server capabilities from a URI.

-----Original Message-----
From: Dave Burke [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2005 8:50 AM
To: Eric Burger; Brett Gavagni
Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan
Subject: Re: Question on negotiating EMMA (was RE: [Speechsc]
EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?)

I have to side with Brett here.

The reality is that there are plenty of things that the client may find
out 
about the server "too late". Here are the ones that will undoubtedly
happen 
in practice:
    - a given language not supported
    - a given semantic interpretation format within the SRGS <tag>s not 
supported
    - speech enrollment not supported

In practice, a client will know the vendor of the speech resource
servers 
identified by a SIP URI and will know what to expect; network
administrators 
will know not to load balance / failover a hetergeonous vendor set.

It seems much cleaner to use Accept on the RECOGNIZE request so the
server 
knows the format(s) to use for the RECOGNITION-COMPLETE final response. 
SET-OPTIONs/GET-OPTIONs can be used for stickyness.

Dave

----- Original Message ----- 
From: "Brett Gavagni" <[email-masked]>
To: "Eric Burger" <[email-masked]>
Cc: "IETF SPEECHSC (E-mail)" <[email-masked]>; "Shanmugham,
Saravanan" 
<[email-masked]>
Sent: Wednesday, October 19, 2005 11:31 AM
Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] 
EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?)

>I not too thrilled with the implication of leaking more MRCP
Application
> parameters into SDP,  which could be possibly considered outside the
scope
> of resource session establishment,. This could potentially end up
> complicating interoperability scenarios.
>
> Thanks,
>
> Brett Gavagni
> WebSphere Voice Server Development
> http://www-306.ibm.com/software/pervasive/voice_server/
> [email-masked]
>
>
>
>
> "Eric Burger" <[email-masked]>
> 10/18/2005 10:48 PM
>
> To
> "Shanmugham, Saravanan" <[email-masked]>, Brett Gavagni/West Palm
> Beach/IBM@IBMUS
> cc
> "IETF SPEECHSC \(E-mail\)" <[email-masked]>
> Subject
> RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:
> ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
>
>
>
>
>
>
> Fine with me, so long as server can reject and client can handle
situation
> where I ask for only NLSML in SIP negotiation and then I ask for EMMA
and
> the server doesn't handle it.
>
> From:   Shanmugham, Saravanan [mailto:[email-masked]]
> Sent:   Tue Oct 18 20:57:20 2005
> To:     Eric Burger; Brett Gavagni
> Subject:        RE: Question on negotiating EMMA (was RE: [Speechsc]
EMMA:
> ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
>
> 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
>     From: Eric Burger [mailto:[email-masked]]
>     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 ++++
>     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
>
>          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)

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 19 Oct 2005 14:10:24 -0400

With this input, I would offer that if we support this feature, it needs to be specifiable on a per-method basis.

________________________________________
From: Baggia Paolo [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2005 7:54 AM
To: Eric Burger; Shanmugham, Saravanan; Brett Gavagni
Cc: IETF SPEECHSC (E-mail); Baggia Paolo
Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?)

Eric,

 
 
Paolo
     -----Original Message-----
        
     ++++ THE QUESTION ++++