W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2002

RE: Personal comments on Speech Recognition Grammar Spec last call

From: Martin Duerst <duerst@w3.org>
Date: Tue, 02 Apr 2002 12:20:31 +0900
Message-Id: <4.2.0.58.J.20020402121033.028d4250@localhost>
To: Al Gilman <asgilman@iamdigex.net>, <andrew.hunt@speechworks.com>, <www-voice@w3.org>
Hello Al,

After taking quite some time to think about it again,
I think I can very much agree with your position.

I very much hope that the Speech Recognition Grammar Spec
can be changed in that way, and would otherwise not be
satisfied with the resolution.

It took me quite a while to think about potential security
issues (there have been several recent security problems
where (mime) typing was involved). At the moment, my guess
is that there is not too much of a problem. The first point
would be that speech grammars are not security-relevant
(maybe a grammar with some recursive rules could create
an infinite loop and therefore a denial of service attack
on a bad implementation). But maybe I'm wrong here and
some components of the grammar could lead to execution
of some code. The second point is of course that a speach
grammar will be used when a speech grammar is referenced.
There is no general link functionality such as: When you
get here, display the referenced document.
So I think it should be okay.

Regards,    Martin.

At 16:16 02/03/21 -0500, Al Gilman wrote:
>Sorry to be a space cadet, but I want to reverse what I said a bit.
>
>Rather than say "the type indicated in the reference rules, when present" 
>better to say "In the case that the actual resource recovered bears an 
>indication of a type not suitable for processing, the type indicated in 
>the reference may be used to attempt a recovery from this error."
>
>[more below]
>
>At 08:47 PM 2002-03-20 , Martin Duerst wrote:
> >Hello Andrew,
> >
> >I'm sorry to bother you again. Based on Al's comments, I had a look
> >at your mail again, and found some very basic unclarity.
> >
> >At 14:03 02/03/18 -0500, Andrew Hunt wrote:
> >>Martin,
> >>
> >>As of the last email there were three outstanding issues.  Here is
> >>a summary of status/disposition.
> >
> >>20) It is a bad idea to have the media type specified
> >>     with the reference overwrite the media type determined from the
> >>     actual referenced resource
> >>
> >>After your most recent email the working group revisited the issue.
> >>We do plan any change to the specification.
> >
> >Do you plan some change, or do you not plan any change?
> >
> >At the minimum, I would like to see an explanation of the problems
> >with using the type attribute on the link (a very clear example would
> >be that somebody has some linked speech grammar files in ABNF, and
> >converts them to the XML notation. All the type attributes in the
> >links to that grammar fragment will have to be updated, which may
> >be a real pain), and a commitment of the WG to (some of) the
> >proposals for getting things improved on the server side.
> >
> >Regards,   Martin.
> >
> >
> >>Here is our analysis of
> >>the issue and the reason for remaining with the status quo.
> >>
> >>Your point that neither a resource specified by a URI, nor the bytes
> >>returned when resolving the URI, has a unique type, is well-taken.  This
> >>means for example that a server is perfectly justified to return an HTTP
> >>header indicating a type of, say, text/plain, when the bytes are in fact
> >>also a valid W3C grammar.  In such a case it's perfectly reasonable for
> >>the consumer of the resource to interpret those bytes (in a kind of
> >>casting operation) as some other type than the type indicated by the
> >>server, when the consumer of the resource has some "out-of-band" source
> >>of knowledge about the resource.  The "type" attribute provides a way
> >>for an application developer to provide this "out-of-band" knowledge to
> >>the consumer (voice browser in this case).
> >>
> >>This is useful in the common case where the VoiceXML application
> >>developer is also in control of the bytes that the URI resolves to, but
> >>may not be in control of the type information returned by the server.
> >>This is especially important for new types, where experience shows web
> >>servers are frequently not configured to return the most useful or most
> >>specific type information for resources that conform to the new type.
> >>
>
>AG::
>
>In the case of a conflict between the type that the application expects 
>from reading the referring grammar and the type that the transport asserts 
>for the entity transported, the processor does not have to go with just 
>one or the other.  Either one could be wrong.
>
>If one type reflects a potential success and the other type reflects a 
>sure failure, then the processor could take the optimistic route, 
>interpret the recovered resource representation in accordance with that 
>type and if the recognition process (parse, etc.) succeeds, go with it.
>
>
>For SGRS we have the added complexity that applicable grammars come in two 
>equivalent forms which are expected to have different MIME types.  Making 
>the type indication in the reference override the actual type of the 
>grammar sent will force errors when the type indication in the reference 
>is ABNF and the data returned are in XML, for example.  Should this be an 
>error?
>
>Would it possible for the processor to make the determination as to 
>whether XML or ABNF grammars are acceptable at this point and not the 
>referring grammar document?
>
>Al
>
> >>There is also precedent in recent W3C recommendations for such a "type"
> >>attribute:  from the SMIL 2.0 Recommendation, Chapter 7
> >>(http://www.w3.org/TR/smil20/extended-media-object.html):
> >>
> >>The
> >><http://www.w3.org/TR/smil20/extended-media-object.html#adef-media-type>
> >>type attribute value takes precedence over other possible sources of the
> >>media type (for instance, the "Content-type" field in an HTTP exchange,
> >>or the file extension).
> >>
> >>
> >>Please let us know if you have further comments on these issues.
> >>
> >>Regards,
> >>   Andrew Hunt
> >>   Co-editor SRGS
> >>   SpeechWorks International
> >
Received on Tuesday, 2 April 2002 00:05:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:55 GMT