Subject: [Speechsc] Revision of draft-ietf-speechsc-reqts based on IESG feedback

From: "David R. Oran" <[email-masked]>
Date: Fri, 06 Dec 2002 14:39:55 -0500

I have produced an update to the Speech Services Control Requirements based 
on the helpful feedback from the IESG. This revision addresses most of the 
comments. Some comments, such as those suggesting we get review from 
certain communities, are still pending, so this should be considerd an 
interim version not yet ready for formal reconsideration by the IESG.

The authors are soliciting WG feedback to ensure these changes are in 
keeping with the established WG consensus on the requirements.

The revision, in draft-ietf-speechsc-reqts-03.txt, should be available in 
the archives shortly. Please contact me if you want an advance copy; I'll 
email it to you.

Note also that I got sick and tired of fighting with MS Word for producing 
I.D.s, and have converted this document to XML and produced the output 
using the xml2rfc tool. It is possible that errors were introduced in this 
process that escaped my proofreading. It would be helpful if some of the WG 
members looked over the entire document carefully as a quality control 
check on the conversion.

IESG comments and responses (with corresponding changes to the document as 
needed) follow.

Cheers, Dave Oran

Comment set 1:
- Title uses unknown (at least to me) acronyms.

Response: There is a tradeoff betwen using acronyms and entering the 
contest for the longest title of an RFC/internet draft. For this version I 
have attempted to strike a balance by retaining the acronyms in the title, 
but ensuring that the acronym and its expansion is prominent in the 
Abstract. IF this does not do the trick, I'm perfectly happy to enter the 
longest-title contest.

- Sect 2 talks about:
    OPEN ISSUES: This document highlights questions that are, as yet,
    undecided as "OPEN ISSUES".
  Id did not find any such opern issues anymore (which is good),
  So the note can be removed I think

Response: correct, and the note on open issues has been removed.

- I see a number of places where a notation of: ?some text? is used
  Is that normal practice? And what does it mean?
  See sections 5.8, 6.2.3, 6.3... others

Response: all removed

- I see normative references to "work in progress"

Response: first, I've updated the references to the most recent versions. 
More to the point, we have our fingers crossed that the normative ones will 
be completed by the time the RFC editor is ready to publish these 
requirements. Specifically:
	. SSML is in W3C last call which closes 15 Jan 2003.
	. SRGS is now a "candidate recommendation", which is roughly
		equivalent to proposed standard. I would hope the RFC
		editor will consider this past the "work in progress"
		stage.

- you should remove the reference to 2026 in the boilerplate
since that will go away when it becomes an RFC and the RFC Ed will
have to renumber all references - better you do that (or, better yet,
don't use numbered references)

Response: Removed. Kept numbered references since that is what xml2rfc does.

- The framework drawing is confusing.  Why is SPEECHSC on two lines?
   There needs to be more explanation of the protocol role in its
   two invocations.  Give an example as well of using SPEECHSC in a
   SIP application, since this document is the first appearance of
   SPEECHSC and is setting up its role in the community.

Response: The paragraphs describing the framework drawing have been 
modified to attempt to be moe illuminating. On the specific issue of the 
protocol appearing twice, this is now explicitly addressed by pointing out 
that either the media processing entity or the application server (if 
present) may be the client in the protocol exchanges.

The idea of including a more complete example employing SIP could be quite 
useful, as long as it does not overly bias the reader in understanding and 
evaluating the requirements themselves (examples can be over-intepreted 
fairly easily). I'd like WG feedback on the desirability of including such 
an example, and solicit specific text if anyone want to take a crack.

This aspect of the IESG comment I still consider PENDING.

- The requirement of the VCR-like control is not for all use - and it
   clearly treads on RTSP as described in 6.5 - the section needs a
   qualifier that it is for uses of SPEECHSC where there is streaming
   material that can be controlled, not for realtime-produced media.

I have some difficulty addressing this comment. Few if any of the 
requirements are "for all use" in terms of being employed under all 
circumstances. The controls are oriented toward the TTS usage, and that is 
why they appear in the TTS section of the requirements. There are some 
cases of very simple TTS where such controls can be eliminated, but 
generality and flexibility argues for their presence for all TTS usages. 
The fact that such controls "tread" on RTSP is not coincidental - the 
functions needed are a close match to what RTSP does for streaming media. 
I'd like some clarification on just what sort of qualification is needed on 
these requirements. The SSML framework in the W3C, for example, makes no 
useful distinction between "streaming material" and "realtime-produced" 
media, since many TTS systems freely intermix pre-recorded material with 
realtime computed material. I need some help here - so this comment is 
still PENDING.

- Delete mention of msuri - it was not accepted as a SIP proposal on
   several tries

Response: correct. This has been supplanted by 
draft-burger-sipping-netann-03. The text and reference have been updated. 
This is an informative reference and is not critical to the discussion, so 
if there are objections to the presence of the revised material, it can be 
easily removed.

-  Reference RFC 3351 (SIPPING Deaf Requirements) and consider what
   are specific needs here - solicit review by
   Arnoud van Wijk, the editor of RFC of RFC 3351 and Rohan Mahy.
   This should actually be generalized to handicapped needs, which
   Rohan can give pointers for; an example is under VCR-like control,
   where there needs to be superfast TTS playout for a blind user.

Response: I have launched a query to the editors/authors of 3351 and Rohan 
Mahy. I have also added the reference and a general requirement to address 
the needs of handicapped users. This is PENDING until I get feedback from 
the community.

- SI/SV: Is there adequate support for the the apps to deal with
   their needs to handle false positive identifications, beyond the
   MUST for offline analysis, since network noise and error will
   undoubtedly complicate the situation, and we should understand
   what purposes these functions will be serving.  There should be
   very good timestamps and other features - privacy etc because
   of the abusability of SI/SV noise.

Response: Agree with this observation, however since the applications 
themselves are out of scope (the protocol only provides the necessary 
control machinery), it is not clear just how to craft a comprehensive 
requirement for this. The point about timestamping the recording is an 
excellent one, and I have added text to this effect to the requirement. 
Suggestions for what additional text to add would be greatly appreciated.

For example a false positive can be ascertained and acted on only by 
ex-post facto auditing using data not available at the time of 
verification. At that point it is not clear what beyond the recorded input, 
its timestamp, and the resultant verification output (which could easily be 
a probability ranking for candidates rather than a unique individual) would 
be valuable.

[end of comments and responses]
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc