Subject: [Speechsc] draft-25 changes

From: Dan Burnett <[email-masked]>
Date: Mon, 11 Jul 2011 19:56:26 -0400

Group,

This draft addresses some, but not all, of the Area Director review comments received so far.  I went ahead and posted the draft so you could see what's changed so far.
Expect another draft after the IETF-81 publication moratorium expires containing the remainder of the changes needed to address the AD review comments.

Below is the list of changes.  Note that there have been many editorial changes which are not detailed below.

Also, if you posted a comment to the list and I have not yet replied, please wait for the next draft.  I have some outstanding comments to reply to that may be addressed in draft-26.

-- dan

**************************************************

General:
- Clarified RFC2119 language throughout the document, including rewriting some text to use RFC2119 language.
- Expanded acronyms (and provided references) at first use.
- Fixed more errors in the SIP and SDP examples.
- Numerous editorial changes.

Section 13.6:
- Made reference to RFC 4395 Informative rather than Normative.
- Replaced "URL" with "URI"
- Added "Status" of "Permanent"
- Replaced the "Encoding considerations" text with "There are no other encoding considerations for the 'session' URIs not described in RFC 3986 [RFC3986]." and added RFC 3986 as a normative reference.
- Removed "The character set for URLs is restricted to US-ASCII." from the Interoperability considerations field.
- Changed "Intended usage" to "URI scheme semantics"
- In the "Security considerations" field, added "Generic security considerations for  
URIs described in RFC 3986 apply to this scheme as well" and adjusted the remaining text appropriately.
- Added "[email-masked]" in Author/Change controller field.

Section 4.2:
- Clarified that when the client wants to add a media processing resource to the session, it issues a new SDP offer, according to the procedures of RFC 3264, in a SIP re-INVITE request.
- Similarly, clarified that when the client wants to de-allocate a resource from the session, it issues a new SDP offer, according to RFC 3264, where the control m-line port MUST be set to 0, and that this SDP offer is sent in a SIP re-INVITE request.
- Clarified that the a=setup attribute must be used for TCP and TCP/TLS according to RFC 4145 and RFC 4572, respectively.

Section 5.4:
- For failure code 407, changed "MAY BE" to "might be".

Section 8.5.1:
- Clarified that MRCPv2 clients and servers MUST support the multipart/mixed Media Type.

Section 8.6:
- "The SPEAK method can carry voice ..." => "The SPEAK method MAY carry voice ..."

Section 6.2.6:
- Clarified that "registered Media Types" refers to the IANA Media Types registry.
- Added ABNF for content-type.

Sections 9.4.11, 10.4.3, 11.4.16, and 15:
- Clarified in text and ABNF that the cause code and name are from the table.

Sections 9.4.26 and 15:
- Clarified in ABNF that only the two values "normal" and "hotword" are allowed.

Section 9.9:
- Changed "In addition to performing recognition on the input, the recognizer may also enroll the collected utterance . . ." to "In addition to performing recognition on the input, the recognizer MUST also enroll the collected utterance . . .".

Section 9.17:
- Clarified that the recording location/URI must be provided via the Waveform-URI header.

Section 10.4.7:
- Clarified that if the header field is not specified the audio must be captured, encoded, and returned in the body of the STOP or RECORD-COMPLETE.

Section 12.1:
- Clarified that SIP digest authentication support is required and that clients and servers SHOULD use it.
- Clarified that employing 'sips' URIs means setting up TLS connections.

Section 13.7:
- The parameters in section 13.7.2 were actually media-level parameters, so the section has been renamed and merged with the contents of section 13.7.3.

Section 14:
- Normative text has been moved from the examples in this section to other sections, including:
  - From Section 14.1 to Section 8.4.2.
  - Removal of unnecessary RFC2119 text from Section 14.1.

Sections 6.1.1 and 6.1.2:
- Corrected "Response-Status" to be "response status-code".