On Apr 18, 2011, at 3:10 AM, Slawomir Testowy wrote:
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.
No, it is not possible. There is no way, for example, to specify which
recognizer is being deleted when you deallocate one. I will clarify this
restriction in the specification.
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".
Good catch. I will make this change.
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" :)
This is an artifact of having had multiple editors over the years :) I will
correct this.
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?
Technically they are similar in that both can be specified within SSML.
However, this distinction is a subtle one and reflects common practice in voice
output design -- a designer is more likely to want to specify a default voice
as a header than default prosody, because the former is commonly needed for a
document as a whole (even though it can be changed within a document) while the
latter typically only applies to specific text (even though one could change it
for the document as a whole).
Is it true for CONTROL (i.e. current SPEAK must be text/plain)?
The distinction between Prosody and Voice parameters applies in the case of
CONTROL as well.
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".
This is a good clarification. I will add it.
Thanks.
Slawek Testowy
2011/3/16 The IESG <iesg-secretary(_at_)ietf(_dot_)org>:
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
ietf(_at_)ietf(_dot_)org 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 iesg(_at_)ietf(_dot_)org 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
Speechsc(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/speechsc
Supplemental web site:
<http://www.standardstrack.com/ietf/speechsc>
_______________________________________________
Speechsc mailing list
Speechsc(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/speechsc
Supplemental web site:
<http://www.standardstrack.com/ietf/speechsc>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf