Subject: Re: [Speechsc] Updated version (v0.2) for speechsc WG Internet Draft submission protocol evaluation document

From: "Stephane H. Maes" <[email-masked]>
Date: Mon, 4 Nov 2002 12:38:06 -0800

Sarvi,

I will comment in more details later.

I believe that different protocol proposals have to be considered 
differently whne mapped on the requirements.

The web service proposal is at a different level than Sip or Beep for 
example to which it could be bound.

Such fuzziness of the boundary may be frustrating; but it is inherent to 
the nature of SPEECHSC that is also fuzzy between low and more app level 
(engine APIs).

As such, web services have indeed this inherent capability to provide 
any API, support combination and composition etc and to be essentially 
bound to any underlying transport.

Yes syntax is to be defined; but that remains the only major work that 
needs to be done ...
All this remains within the confines of the web service framework.  Can 
you do the same with SIP or BEEP? Yes; but you need to produce a new 
release of the spec or carry lots of info with mechaniss designed only 
for limited extensions.

And by the way, of course web service have no sythax to control speech 
engines. So we could have given failed across the board. But that's not 
the point of the excercise; at least I hope so... Web services is a 
framework that can be applied unchanged (+/-) to support speechsc... And 
yes syntax has to be defined. Honnestky that' comon practice and the 
work of a few months at the level of a standard working group.

With MRCP, I do no know how to position it either. It is a syntax on top 
of another protocol. As defined it does not meet the requirements. But I 
understand that the argument that maybe only syntax needs to be defined 
to satisfy this. So you are rigth to make these updates as MRCP is 
anyway a draft and can therefore support that.

Again the evaluation based on the requirementas is may not yet be enough 
to decide and pick an approach. Other design points may have to be taken 
into account to progress.

I agree with you that whatever is the point of view taken; it is 
frustrating when considered from another angle. We will have to decide 
what would best help progress.

Thanks

Stephane

On Mon, 4 Nov 2002 3:03PM -0500, Sarvi Shanmugham wrote:
> some comments/questions on the document.
>
> Comment 1:
> My evaluations of MRCP were for the most part, how the protocol already 
> met the
> requirements.  And hence when it came to dealing with issues like 
> SI/SV, they were
> classified as not supported.
>
> After reading some of the evaluations(such as web services), which 
> pretty much does not
> directly  meet most of the requirements. But seems to discuss mostly 
> about how it can
> evolve with the additon of  a NEW set of messaging to meet the 
> requirements.
>
> If this is indeed to basis of protocol evaluation and considering MRCP 
> was originally
> designed to be extensible for these exact needs.  Even preliminary 
> methods and formats
> for these resources were defined but not refined/implemented/tested due 
> to priorities.
> The MRCP protocol evaluation would be (T) in most of the SI/SV 
> requirements.
>
> Other comments:
> Based on the above, the following sections will change in meeting the 
> requirments.
> In all the following sections, texts already provided, addresses how 
> MRCP could be
> evolved to meet the needs in FULL, if it does' not already meet it in 
> full.
>
> 7.2.4. Protocol efficiency [5.4]  - would become T
>
> 7.2.8. Multiple media sessions [5.8]  - would become T
>
> 7.4.3. Grammar Specification [7.3.1] - would become T
>
> 7.4.4. Explicit Indication of Grammar Format [7.3.2]  - should be T 
> already without any
> needed changes.
>
> 7.4.5. Grammar Sharing [7.3.3] - This again would be T. since the 
> DEFINE-GRAMMAR method
> could be extended to define grammars that cna be shared across 
> sessions, and URI
> mechanism used to identify, define and refer to such grammars.
>
> 7.5. Analysis of Speaker Identification and Verification Requirements - 
> This whole
> section would then be T, since this can be achieved by additon new 
> methods to address
> these needs, and since MRCP was designed with these future extensions 
> in mind.
>
> 7.6.3. Multiple services in parallel [9.1.2]  - T if 7.5 is extensions 
> are added.
>
> thx,
> Sarvi
>
>
>
> Brian Wyld wrote:
>
>>  Hi,
>>
>>  Sorry, but attached is an UPDATE to the draft I just submitted to 
>> take
>>  account of last minute additions. This draft is v0.2. I have also 
>> re-created
>>  the .txt to be in US Letter size format as per most IETF docs....
>>
>>  I hope this version can be the legitimate Internet Draft for speechsc
>>  protocol evaluation. Please ignore the previous version.
>>
>>  Thanks
>>
>>  Brian
>>
>>  [Brian Wyld] [[email-masked]]
>>  [Directeur General R&D]
>>  [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
>>  [advanced solutions for telecoms and IT services]
>>
>>    
>> ------------------------------------------------------------------------
>>                                             Name: 
>> draft-speechsc-protocol-eval-v02.txt
>>     draft-speechsc-protocol-eval-v02.txt    Type: Plain Text 
>> (text/plain)
>>                                         Encoding: quoted-printable

___
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Oracle Corporation.
Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-203-798-6948
e-mail: [email-masked]
IM: shmaes (AIM) or [email-masked] (MSN)
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Sarvi Shanmugham <[email-masked]>
Date: Mon, 04 Nov 2002 12:55:20 -0800

Hi Stephane,
     I was in no way claiming that your analysis of web services is wrong.

But like you mention, since my evaluation of MRCP is based on the notion that
the current MRCP spec will be extended in one of the 3 ways proposed, I think
the following changes are appropriate.

So I was just making these changes to make the evaluation consistent with the
Webservices evalution.

Sarvi

---

From: "Stephane H. Maes" <[email-masked]>
Date: Mon, 4 Nov 2002 13:01:08 -0800

I did not assume that you were... Don't worry. I think that you pointed 
out a challenge in using this to make any type of progress.

Thanks

Stephane

___
Stephane H. Maes, PhD,