Subject: [Speechsc] Proposed resolutions for WGLC comments on diraft-ietf-speechsc-reqts-00.txt

From: "David R. Oran" <[email-masked]>
Date: Sun, 06 Oct 2002 13:29:03 -0400

Thanks to all who submitted comments on this draft during WGLC, and to the 
ensuing discussions, which were useful and productive. I apologize for the 
delay in getting this message out. I have no excuse beyond the usual "too 
much work".

After reviewing all the comments and discussion, I believe we will have WG 
consensus on the requirements with some minor adjustments to the document. 
These are reflected in draft-ietf-speechsc-reqts-01, which I have submitted 
to the archive and should appear within a day or two. Below please find my 
proposed resolution to each of the issues raised during last call (also in 
the change log of the revised document).

>From a process point of view, I believe we should do a "mini" repeat of 
WGLC since there are some changes. Therefore, please post any OBJECTIONS 
you have to the revised requirements document to the list by Friday, 
October 11. If there are no objections, I will ask the ADs to have the IESG 
consider the document for publication as an Informational RFC.

Given the short time, I am violating the usual email etiquette and am 
attaching the full document because I don't have a convenient place to put 
up a temporary copy for fetching. It isn't inordinately large, and I 
apologize in advance.

Thanks again to all of you who worked on helping to write, review, and 
discuss the requirements.

Dave.

Changes to draft-ietf-speechsc-reqts-00.txt based on WGLC comments:

- Adopted Rajiv D.'s wording clarification to the TTS & ASR requirements to 
allow control to come from either a separate Application Server, or a 
combined server with a Media Processing entity.

- Reorganized references into separate normative and informative sections 
as requested by Scott Bradner

- Added numbering for requirements in sections that were not previously 
numbered. This necessitated a bit of text shuffling to group related 
requirements more closely together.

- Added a paragraph to the introduction to emphasize the wide variety of 
applications of the speechsc framework and explicitly call out wireless 
mobile devices, IP phones, and PSTN VoIP gateways.

- During WGLC, the use of the term "speaker recognition" to cover both 
speaker identification and speaker verification was questioned. In addition 
some WG participants felt that there should be separate requirements for 
each, while others argued that the differences, while affecting the 
structure of the application, did not affect the requirements for the 
protocol in any substantive way. There were views that the existing 
terminology was common in the industry and hence should not be changed, and 
sentiments for a variety of other solutions. The best compromise seemed to 
be to continue to group the requirements together, but point out where 
there may be subtle differences affecting applications. It also seemed 
prudent to keep the identification/verification distinction in the 
terminology, and hence the document uses the acronym SI/SV rather than SR 
when talking about both together.

- added a requirement in section 5 for 1:N mapping of control to media 
channels, but pointed out that if SDP is used this comes for free.

- Changed the input capture requirement from SHOULD to MUST, but made 
implementation by the server a SHOULD.

- added a SHOULD requirement for protocol efficiency with re-use of 
transport connections as one of a set of examples.

- noted in section 10 that while RTP is assumed, the framework applies to 
other media carriage schemes that can be described by SDP, as long as they 
have the right features.

---

From: Qiru Zhou <[email-masked]>
Date: Fri, 11 Oct 2002 22:21:40 -0400

In general, the requirements looks good, with few more comments:

5.5. Server Location and Load Balancing 
I'd like to see "performing service location and load balancing," to
"supporting service location and load balancing,". Dave, this is what
I mean from my last comments.

5.6 Simultaneous services
Could we change the tittle to "5.6 Multiple services" since the text
is talking about multiple services that may not be simultaneous.

6.2.1. Plain Text and 6.2.2. SSML 
Does this mean we have to support both free form plain text and SSML
markup? Then we may need to redefine things that already defined in SSML
to support basic synthesis features such as language selection, rate,
etc. This will increase the implementation complexity and could leave
some ambiguities for TTS text parsing. Why don't we just support SSML?
It can be just as simple as:

<speak ...>
	I don't speak Japanese.
</speak>

In requirement, we can say SPEECHSC MUST support SSML <speak> basics, and
SHOULD support other SSML tags, etc.

7.2 XML
I would like to use more precise text such as:

7.2. 
   VoiceXML Speech Recognition Grammar Specification
    
   The ASR Server MUST support the VoiceXML speech recognition grammar specification
  (SRGS) for speech recognition [4].

Dave, my last comments concern was the requirement mentioned XML only. The
SRGS also defined a ABNF format which is not XML at all.

7.3.3. Grammar Sharing
Is there a need to define a protocol to say "share" or "don't share" when
send a grammar to a speech server?

If the grammar is public and the speech server should support archiving
feature (i.e., "Servers SHOULD be able to store and later retrieve by
reference large grammars" in 7.3.1), I think this implies sharing function
already.

7.5. Input Capture
I am a little concern about this seems ASR internal tuning feature. It is
nice to have it, but in many countries it is illegal to record user's
speech without user's explicit permission. If we define speech capture
in protocol, we have to specify a protocol to force the permission
request process. Unless the tuning is totally automatic and there is no
chance that the recorded speech can be stored and copied for other
uses (such as online adaptation). Should we put a legal notice here?

8.3. State for multiple utterances
What is the state duration here? In a session, or cross sessions?

-- Qiru
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David R. Oran
Sent: Friday, October 11, 2002 7:49 AM
To: [email-masked]
Subject: [Speechsc] Reminder: please register any objections to sending
draft-ietf-speechsc-reqts-01.txt to IESG by end of today

Folks, a gentle reminder that today is the last day for our "mini WGLC 
repeat" on draft-ietf-speechsc-reqts-01.txt.

If you have objections to any of the requirements, now is the time to
voice 
them.

So far, we have a comment from Scott Bradner to reword the requirements 
which mention servers to be clear that the requirements are on the 
framework/protocol and not the servers themselves. Some example changes 
have been posted and it appears nobody has a problem with such changes.

If no objections are forthcoming, I will update the document over the 
weekend and send it to the IESG for processing toward Informational RFC.

Dave.

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked] _______________________________________________
Speechsc mailing list
[email-masked] https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc