Subject: Re: [Speechsc] Last Call: <draft-ietf-speechsc-mrcpv2-24.txt> (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard

From: Slawomir Testowy <[email-masked]>
Date: Mon, 18 Apr 2011 08:31:59 +0200

Hello,

my small comment:

The BARGE-IN-OCCURRED method is in few places wrote as BARGE-IN-OCCURED
(note missing "R"). I wonder how this could go through all 24 MRCPv2
revisions....

Regards,
Slawek Testowy

2011/3/16 The IESG <[email-masked]>:
>
> The IESG has received a request from the Speech Services Control WG
> (speechsc) to consider the following document:
> - 'Media Resource Control Protocol Version 2 (MRCPv2)'
>  <draft-ietf-speechsc-mrcpv2-24.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-04-13. (This allows an additional two
> weeks for review since the document is large and the review period overlaps
> the Prague IETF meeting). Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speechsc
> Supplemental web site:
> &lt;http://www.standardstrack.com/ietf/speechsc&gt;
>

---

From: Slawomir Testowy <[email-masked]>
Date: Mon, 18 Apr 2011 09:10:53 +0200

Hi!

Some other comments:

> 4.2. Managing Resource Control Channels

> When the client wants to add a media processing resource to the
> session, it issues a SIP re-INVITE transaction.

Is it possible to allocate more than one resource of the same type
during one SIP dialog? Example in 4.2 shows how to allocate
synthesizer and recognizer, but does not specify if there may be e.g.
more than one synthesizer.

>6.2.9. Content-Encoding
>
>
>   The content-encoding entity-header is used as a modifier to the
>   media-type.  When present, its value indicates what additional
>   content encoding has 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.  Content-encoding is
>   primarily used to allow a document to be compressed without losing
>   the identity of its underlying media type.  Note that the SDP session
>   can be used to determine accepted encodings (see Section 7).  This
>   header field MAY occur on all messages.

Section 7 describes usage of OPTIONS method of SIP and Accept-Encoding
header is returned by SIP response, not SDP answer, so I guess "Note that
the SDP session can be used" should be changed to "Note that the SIP
session can be used".

>   When a CONTROL request to jump backward is issued to a currently
>  speaking synthesizer resource, and the target jump point is before
>   the start of the current "SPEAK" request, the current "SPEAK" request
>   MUST restart from the beginning of its speech data and the response
>   to the CONTROL request MUST contain this header field with a value of
>   "true" indicating a restart.

Why sometimes requests are surrounded by quotation marks (like "SPEAK")
and sometimes not (like CONTROL request)? This happens through all the
specification. This may be a minor nit, but makes the whole paper look like a
"draft" :)

> 8.4.7. Prosody-Parameters

>  The prosody parameter headers in the "SET-PARAMS" or "SPEAK" request
>  only apply if the speech data is of type text/plain and does not use
>  a speech markup format.

Why is it so? Why it is not true for Voice-Parameters?
Is it true for CONTROL (i.e. current SPEAK must be text/plain)?

Specification does not say anything about it.

> 8.4.16. Load-Lexicon
>
>
>   This header field is used to indicate whether a lexicon has to be
>   loaded or unloaded.  The default value for this header field is
>   "true".  This header field MAY be specified in a DEFINE-LEXICON
>   method.

I propose rewording this paragraph to explicilty state that "true" means
"load lexicon" and "false" means "unload lexicon".

Thanks.
Slawek Testowy