Subject: [Speechsc] FW: change list for forthcoming draft -12

From: "Daniel C. Burnett" <[email-masked]>
Date: Wed, 14 Mar 2007 08:56:23 -0400

Resending.

________________________________

From: Daniel C. Burnett 
Sent: Tuesday, March 06, 2007 9:13 PM
To: [email-masked]
Subject: change list for forthcoming draft -12

Group,

I've sent in draft -12 for publication.  It should be published sometime
this week.

This is the list of changes since draft -11.  There were also some minor
editorial fixes (typos, formatting) that are not listed below.

-- Dan Burnett

6.2.9: "Content encoding is defined . . ." -> "Content-coding is defined
. . ."

6.2.11: "It is interpreted . . ." -> "Otherwise, it is interpreted . .
."

6.2.11: Appended this to the end of the section: " When a message having
no use for a message body contains one, i.e. the Content-Length is
non-zero, the receiver MAY ignore the content of the message body."

4.2: Changed "The format field of the m-line is not used and MUST be
left empty."

 to

 'The format field of the m-line is not used by this protocol.  However,
to enable proper generic SDP parsing, it MUST have the
arbitrarily-selected value of "1".'

Changed all MRCPv2 m-lines in the document to include a format value of
"1".

Replaced all instances of '126.16.64.4' with '192.168.64.4'.

Replaced all instances of '224.2.17.12' with '10.2.17.12' in the client
and '10.2.17.11' in the server.

Changed channel-id production from '1*HEXDIG "@" 1*VCHAR' to '1*VCHAR
"@" 1*VCHAR' to match what we decided when we changed the text in
section 6.2.1.  Also removed word "hexadecimal" from section 4.2.

10.1: Added START-INPUT-TIMERS to state machine.

10.5: Replaced 'The "STOP" response or the RECORD-COMPLETE event MAY
contain a message body carrying the captured audio. This happens if the
RECORD request did not have a Record-Uri header.'

with 

     'If the RECORD request did not have a Record-Uri header, the "STOP"
response or the RECORD-COMPLETE event MUST contain a message body
carrying the captured audio.'

10.6: Replaced "The audio is then made available to the client as
specified by Record-URI."

with

"The audio is then made available to the client either in the message
body or as specified by Record-URI."

10.6: Added "If the type specified in the Media-Type header is not
supported, the server MUST respond with a status code of 409,
"Unsupported Header Value", with the Media-Type header in its response."

10.10: Added "The recorder resource also MUST send a proxy-sync-id
header with a unique value for this event." and added the header to the
associated example.

In addition, I reviewed every "should" or "SHOULD" in the document and
have made the following changes:

3.1:

Speech Synthesizer

                  A full capability speech synthesis resource capable of

                  rendering speech from text.  Such a synthesizer SHOULD

                  have full SSML [25] support.

(MUST)

Recorder

                  A resource capable of recording audio and saving it to

                  a URI.  A recorder SHOULD provide some end-pointing

                  capabilities for suppressing silence at the beginning

                  and end of a recording, and MAY also suppress silence

                  in the middle of a recording.

(SHOULD->MUST)

4.2:

All servers MUST support TLS, SHOULD support TCP without TLS, and MAY
support SCTP.

(reword: "All servers MUST support TLS. Servers MAY support TCP without
TLS in physically secure environments.")

4.4:

All MRCPv2 servers MUST support TLS, SHOULD support TCP and MAY support
SCTP.

(reword: "All servers MUST support TLS. Servers MAY support TCP without
TLS in physically secure environments.")

5.2: If the server receives duplicate or out-of-order requests

   the server should reject the request with a response code of XXX.

(MUST; XXX->410)

6.1.1: If one or more of the headers being set has an unsupported value,

      the server SHOULD reject the request with a 409 Unsupported Header

      Value, except as described in the next paragraph.

(MUST)

6.1.2: The "GET-PARAMS" method, from the client to the server, asks the

   MRCPv2 resource for its current session parameters, such as voice

   characteristics and prosody on synthesizers, recognition-timer on

   recognizers, etc.  The client SHOULD indicate the list of parameters

   it wants to read from the server by sending a set of empty header

   fields.

(reword: "... recognizers, etc.  For every empty header field the client
sends

in the request, the server MUST include the corresponding headers and
their values

in the response.")

6.1.2: If no parameter headers are specified by the client then the

   server SHOULD return all the settable parameters and their values in

   the corresponding headers of the response, including vendor-specific

   parameters.

(MUST)

6.2.2: The Accept header field follows the syntax defined in [H14.1].
The

   semantics are also identical, with the exception that if no Accept

   header field is present, the server SHOULD assume a default value

   that is specific to the resource type that is being controlled.

(MUST)

6.2.3: In a request, this header indicates the list of request-ids that
the

   request should apply to.

(reword: "... list of request-ids to which the request applies.")

6.2.3: In the case of such

   terminated requests, the server SHOULD NOT send any "SPEAK"-COMPLETE

   or RECOGNITION-COMPLETE events.

(reword: "After sending the STOP response, the server MUST NOT send any
SPEAK-COMPLETE or RECOGNITION-COMPLETE

 events for the terminated requests.")

6.2.10: The server MAY use this header to optimize certain

   operations.  When providing this header the entity being sent should

   not have been modified from what was retrieved from the content-

   location URI.

(reword: "This header is provided for optimization purposes only.  The
receiver of this header MAY assume

 that the entity being sent is identical to what would have been
retrieved or might already have been

 retrieved from the content-location URI.")

6.2.14: The MRCPv2 server SHOULD provide a mechanism to subset its

   output logs so that system administrators can examine or extract only

   the log file portion during which the logging tag was set to a

   certain value.

(MAY)

6.2.15: The MRCPv2 client

   should be able to push its stored cookies to the MRCPv2 server and

   get new cookies that the MRCPv2 server stored back to the MRCPv2

   client.

(reword: "To enable the MRCPv2 client to push its stored cookies to the
MRCPv2 server and

   get new cookies from the MRCPv2 server stored back to the MRCPv2

   client, ") - connects with following sentence.

6.2.15: Since the type of cookie header

   is dictated by the HTTP origin server, MRCPv2 clients and servers

   SHOULD support both the set-cookie and set-cookie2 entity header

   fields.

(reword: "To ensure support for the type of cookie header dictated by
the

HTTP origin server, MRCPv2 clients and servers

   MUST support both the set-cookie and set-cookie2 entity header

   fields.")

6.2.15: An MRCPv2 client or server SHOULD calculate the age of the
cookie

   according to the age calculation rules in the HTTP/1.1 specification

   [6] and append the "Age" attribute accordingly.

(MUST)

7: Server resources may be discovered and their capabilities learned by

   clients through standard SIP machinery.  The client can issue a SIP

   OPTIONS transaction to a server, which has the effect of requesting

   the capabilities of the server.  The server SHOULD respond to such a

   request with an SDP-encoded description of its capabilities according

   to RFC3264 [7].

(MUST)

7: There should be one "resource"

   attribute for each media resource that the server supports with the

   resource type identifier as its value.      

(MUST)

8.4.1: This header MAY also be specified in a "SPEAK" request to
indicate an

   offset into the speech markup that the "SPEAK" request should start

   speaking from.

(reword: "This header MAY also be specified in a "SPEAK" request as a
desired offset into the synthesized speech.

 In this case, the synthesizer MUST begin speaking from this amount of
time into the speech markup.  Note

 that an offset that extends beyond the end of the produced speech will
result in audio of length zero.")

8.4.1: If the synthesizer

   resource does not support a unit or the operation, the resource

   SHOULD respond with a status code of 409 "Unsupported Header Value".

(MUST)

8.4.2: If the recognizer or signal detector resource is on the same
server

   as the synthesizer and are part of the same session, the server

   SHOULD work with both to provide kill-on-barge-in support.

(remove paragraph and, after the next paragraph, add

"If the recognizer or signal detector resource is on the same server

as the synthesizer and both are part of the same session, the server MAY

work with both to provide internal notification to the

synthesizer so that audio may be stopped without having to wait for the

client's BARGE-IN-OCCURRED event.")

8.4.2: If this header is

   not specified in a "SPEAK" request or explicitly set by a

   "SET-PARAMS", the server SHOULD default to "true".

(reword: '..., the default value for this header is "true".')

8.4.5: Clients SHOULD NOT interpret the completion reason text.  Instead
it

   is RECOMMENDED that the reason be recorded in client logs and

   otherwise made available for debugging and instrumentation purposes.

(reword: "The completion reason text is provided for client use in logs

 and for debugging and instrumentation purposes.  Clients are NOT
REQUIRED to interpret the

 completion reason text.")

8.4.6: If the synthesizer resource does not support this operation, it

   SHOULD reject the request with a status of "Unsupported".

(reword: '... MUST reject the request with a status of 403 "Unsupported
Header".')

8.4.7: If the synthesizer resource does not support this

   operation, it should respond back to the client with a status of

   unsupported.

(reword: "... MUST respond back to the client with a status of 403
"Unsupported Header".')

8.4.8: This header SHOULD be part of the

   SPEECH-MARKER event and contain the marker tag value.

(MUST)

8.4.8: This header SHOULD also be returned in responses to STOP,
CONTROL,

   and BARGE-IN-OCCURRED methods, in the "SPEAK-COMPLETE" event, and in

   an IN-PROGRESS SPEAK response.

(MUST)

8.4.8: In these messages the marker tag

   SHOULD be the last embedded marker encountered or a null string if no

   marker has yet been encountered.

(MUST)

8.4.10: A value of

   "prefetch" indicates the content may be downloaded when the request

   is received, whereas "safe" indicates that content should only be

   downloaded when actually referenced.

(reword: 'A value of

   "prefetch" indicates the content MAY be downloaded when the request

   is received, whereas "safe" indicates that content MUST NOT be

   downloaded until actually referenced.')

8.4.12: When a synthesizer method needs a synthesizer to fetch or access
a

   URI and the access fails, the server SHOULD provide the failed URI in

   this header in the method response.

(add "unless there are multiple URI failures, in which case one of the

failed URIs MUST be provided in this header in the method response.")

8.4.13: When a synthesizer method needs a synthesizer to fetch or access
a

   URI and the access fails the server SHOULD provide the URI specific

   or protocol specific response code in the method response through

   this header.

(MUST.  Also change "response code" to "response code for the URI in the
Failed-URI

header".)

8.4.14: 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 SHOULD contain this header indicating a

   restart.

(MUST)

8.4.15: If a server does not

   support the specified unit, the resource SHOULD respond with a status

   code of 409 "Unsupported Header Value".

(MUST)

8.6: If caching is implemented, this URI

   fetching MUST conform to the cache control hints and parameter

   headers associated with the method in deciding whether it should be

   fetched from cache or from the external server.

(should -> "is to")

8.8: If a "SPEAK" request is active with kill-on-barge-in enabled, and
the

   BARGE-IN-OCCURRED event is received, the synthesizer SHOULD

   immediately stop streaming out audio.

(MUST)

8.9: If a

   PAUSE method is issued on a session when a "SPEAK" is not active the

   server SHOULD respond with a status of 402 "Method not valid in this

   state".

(MUST)

8.9: If a PAUSE method is issued on a session when a "SPEAK" is

   active and paused the server SHOULD respond with a status of 200

   "Success".

(MUST)

8.10: If a RESUME request is

   issued on a session with no active "SPEAK" request, the server SHOULD

   respond with a status of 402 "Method not valid in this state".

(MUST)

8.10: If a

   RESUME request is issued on a session with an active "SPEAK" request

   that is speaking (i.e., not paused) the server SHOULD respond with a

   status of 200 "Success".

(MUST)

9: The "speechrecog" resource type can recognize regular speech

   as well as DTMF digits and hence SHOULD support grammars describing

   either speech or DTMF.

(MUST)

9.4.8: Otherwise, the URI generated by the server SHOULD be unambiguous

   across the server and all its recognition sessions.

(MUST)

9.4.8: The content

   associated with the URI SHOULD be available to the client until the

   MRCPv2 session terminates.

(MUST)

9.4.8: Otherwise, the URI generated by the

   server SHOULD be unambiguous across the server and all its

   recognition sessions.

(MUST)

9.4.8: The content associated with the URI SHOULD be

   available to the client until the MRCPv2 session terminates.

(MUST)

9.4.12: Clients SHOULD NOT interpret the completion reason text.
Instead it

   is RECOMMENDED that the reason be recorded in client logs and

   otherwise made available for debugging and instrumentation purposes.

(reword: "The completion reason text is provided for client use in logs

 and for debugging and instrumentation purposes.  Clients are NOT
REQUIRED to interpret the

 completion reason text.")

9.4.13: This Content-ID SHOULD match

   the Content-ID that came with the context data during the

   "GET-PARAMS" operation.

(MUST)

9.4.14: The recognizer should not start the timers until

   the client sends a START-INPUT-TIMERS request to the recognizer.

(MUST NOT)

9.4.15: The speech-complete-

   timeout value applies when the recognizer currently has a complete

   match against an active grammar, and specifies how long the

   recognizer should wait for more input before declaring a match.

(MUST)

9.4.20: When a recognizer needs to fetch or access a URI and the access
fails

   the server SHOULD provide the failed URI in this header in the method

   response.

(add "unless there are multiple URI failures, in which case one of the

failed URIs MUST be provided in this header in the method response.")

9.4.21: When a recognizer method needs a recognizer to fetch or access a
URI

   and the access fails the server SHOULD provide the URI specific or

   protocol specific response code through this header in the method

   response.

(MUST.  Also change "response code" to "response code for the URI in the
Failed-URI

header".)

9.4.26: This header specifies what mode the RECOGNIZE method should
operate

   in. 

(should->will)

9.4.27: This header specifies what should happen if the client attempts
to

   invoke another RECOGNIZE method when this RECOGNIZE request is

   already in progress for the resource.

(should->will)

9.4.28: It

   specifies the maximum length of an utterance (in seconds) that should

   be considered for Hotword recognition.

(should->will)

9.4.29: It

   specifies the minimum length of an utterance (in seconds) that should

   be considered for Hotword recognition.

(should->will)

9.5: When one or more

   grammars are specified using the DEFINE-GRAMMAR method, the server

   SHOULD attempt to fetch, compile and optimize the grammar before

   returning a response to the DEFINE-GRAMMAR method.

(MUST)

9.5.1: These grammars MAY be in one of the following standard

   grammar specification formats:

   o  W3C's XML-based Speech Grammar Markup Format (SRGS) [26]

   o  Sun's Java Speech Grammar Format [32]

   All MRCPv2 servers MUST support the XML form (MIME-type application/

   srgs+xml) of SRGS and SHOULD support the ABNF form (MIME-type

   application/srgs).

(Reword:

"All MRCPv2 servers MUST accept grammars in the XML form (MIME-type
application/

   srgs+xml) of the W3C's XML-based Speech Grammar Markup Format (SRGS)
[26] and MAY

accept grammars in other formats.  Examples include but are not limited
to:

  o the ABNF form (MIME-type application/srgs) of SRGS

  o Sun's Java Speech Grammar Format [32]"

)

9.5.4: The

   Content-ID value should also be specified in the recognizer-context-

   block header in the "GET-PARAMS" response.

(MUST)

9.5.4: The "SET-PARAMS" request

   wishing to provide this vendor-specific data should send it in the

   message body as a MIME-entity with the same Content-ID that it

   received from the "GET-PARAMS".

(MUST)

9.5.4: The Content-ID should also be sent

   in the recognizer-context-block header of the "SET-PARAMS" message.

(MUST)

9.5.4: Each speech recognition implementation choosing to use this
mechanism

   to hand off recognizer context data among servers should distinguish

   its implementation-specific block of data from other implementations

   by choosing a unique Content-ID that is recognizable among the

   participating servers and unlikely to collide with values chosen by

   another implementation.

(MUST; also remove "unique".)

9.6.3.4 (simple text content): MRCPv2 clients SHOULD

       be prepared to receive such markup but are not required to act on

       it.

(change to MUST and NOT REQUIRED, respectively)

9.9: This means that the recognizer is active and that the client should

   expect further events with this request-id.

("client MUST be prepared to receive further ...")

9.9: The recognizer

   SHOULD expect the media to start flowing when it receives the

   recognize request, but SHOULD NOT buffer anything it receives

   beforehand.

(SHOULD -> "can")

(SHOULD NOT -> MUST NOT)

9.12: The recognizer resource also

   SHOULD send a proxy-sync-id header with a unique value for this

   event.

(MUST)

9.12: This event SHOULD be generated by the server irrespective of
whether

   the synthesizer and recognizer are on the same server or not.

(MUST)

9.13: If not, the recognizer resource SHOULD NOT start the timers

   until the client sends a START-INPUT-TIMERS method to the recognizer.

(MUST NOT)

9.15: If the client has specified Save-Best-Waveform as true, then the

   response after ending the phrase enrollment session SHOULD contain

   the location/URI of a recording of the best repetition of the learned

   phrase.

(MUST)

9.16: This method should be invoked when the

   caller provides undesirable input such as non-speech noises, side-

   speech, commands, utterance from the RECOGNIZE grammar, etc.

(reword: "The client can invoke this method when ...")

9.17: It should be called when successive calls to

   RECOGNIZE have succeeded and Num-Repetitions-Still-Needed has been

   returned as 0 in the RECOGNITION-COMPLETE event to commit the new

   phrase in the grammar.  Alternatively, it can be called by specifying

   the Abort-Phrase-Enrollment header to abort the phrase enrollment
session.

(reword: "To commit the new phrase in the grammar, the client MAY call
this method

once successive calls to RECOGNIZE have succeeded and
Num-Repetitions-Still-Needed

has been returned as 0 in the RECOGNITION-COMPLETE event.
Alternatively, the client

can abort the phrase enrollment session by calling this method with the
Abort-Phrase-Enrollment header.")

9.17: If the client has specified Save-Best-Waveform as true in the
START-

   PHRASE-ENROLLMENT request, then the response SHOULD contain the

   location/URI of a recording of the best repetition of the learned

   phrase.

(MUST)

10: A recorder SHOULD provide some end-pointing capabilities for

   suppressing silence at the beginning and end of a recording, and MAY

   also suppress silence in the middle of a recording.  If such

   suppression is done, the recorder MUST maintain timing metadata to

   indicate the actual time stamps of the recorded media.

(MUST)

10.4.4: Clients SHOULD NOT interpret the completion reason text.
Instead it is RECOMMENDED that the reason be 

recorded in client logs and otherwise made available for debugging and
instrumentation purposes.

(reword: "The completion reason text is provided for client use in logs

 and for debugging and instrumentation purposes.  Clients are NOT
REQUIRED to interpret the

 completion reason text.")

10.4.5: When a recorder method needs to post the audio to an URI and
access

   to the URI fails, the server SHOULD provide the failed URI in this

   header in the method response.

(MUST)

10.4.6: When a recorder method needs to post the audio to an URI and
access

   to the URI fails, the server SHOULD provide the URI specific or

   protocol specific response code through this header in the method

   response.

(MUST)

10.4.12: When recorder is started this header specifies if the recorder
should

   start capturing immediately (false) or wait for the end-pointing

   functionality to detect speech (true) before it starts capturing.

(reword: "If false, the recorder MUST start capturing immediately when
started.  If true, the recorder MUST wait for the end-pointing
functionality to detect speech before it starts capturing.")

11.4.3: Acceptable values indicate whether

   the verification session should train a voiceprint ("train") or

   verify/identify using an existing voiceprint ("verify").

(should -> will)

11.4.7: The verification resource SHOULD NOT

   declare a verification 'accepted' unless the Num-Min-Verification-

   Phrases utterances are available. 

(reword: "... MUST NOT declare a verification 'accepted' unless
Num-Min-Verification-Phrases valid utterances have been received.")

11.4.12: The URI value of

   the header MUST be NULL if there was some error condition preventing

   the server from recording.  Otherwise, the URI generated by the

   server SHOULD be globally unique across the server and all its

   verification sessions.

(MUST)

11.4.12: The content SHOULD be available via the URI

   until the verification session ends. 

(MUST)

11.4.17: Clients SHOULD NOT interpret the completion reason text.
Instead it

   is RECOMMENDED that the reason be recorded in client logs and

   otherwise made available for debugging and instrumentation purposes.

(reword: "The completion reason text is provided for client use in logs

 and for debugging and instrumentation purposes.  Clients are NOT
REQUIRED to interpret the

 completion reason text.")

11.4.21: The verification resource

   SHOULD NOT start the timers until the client sends a START-INPUT-

   TIMERS request to the resource.

(MUST NOT)

11.5.2.9: Note that the value of the verification

   score SHOULD NOT be interpreted as a probability value in the strict

   statistical sense.

(reword: "Note that the verification score is not a probability value.")

11.6: By default, the voiceprint model SHOULD NOT be

   adapted with data from a verification session.

(MUST NOT)

11.6: The server SHOULD return 402

   (Method not valid in this state) for all other operations, such as

   VERIFY, or QUERY-VOICEPRINT.

(reword: 'The server MUST return 402 "Method not valid in this state"

 for all other verification operations.')

11.13: If the header is present

   and its value is "false", the "STOP" response SHOULD contain a

   "Completion-Cause" header and carry the Verification result data in

   its body.

(MUST)

12.2: To ensure control channel protection,

   MRCPv2 clients and servers MUST support TLS and SHOULD utilize it by

   default.

(append "unless alternative control channel protection is used")

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc