Re: [Speechsc] AD review of draft-ietf-speechsc-mrcpv2-20

[Arsen Chaloyan <[e-mail]>]

Hi Robert,

It'd be great to have all the mentioned items clarified.
Please let me just add a few more items.

A. Media Type  (Sections 9.4.9, 10.4.8, 11.4.11)

> Media Type in which to store captured audio or video such as the one captured and returned by the Waveform-URI header.

Probably, it would be reasonable to have list of mandatory and optional media types for both audio and video.
I have noticed .wav is used in examples, also there is a reference to sun audio format in Section 8.5.1

B. Mapping of audio, video and control channels
There is no usage examples for video. Also it's not clarified how an MRCP control channel such as Recorder should be associated with audio and video streams. Probably, one should consider, that a control channel should have two "cmid" attributes, one for audio stream and another for video...


C. Yet another very small typo, I have just accidentally noticed (Section 9.8)

Find "applicationt/x-nlsml" and replace with "application/x-nlsml"


Thanks,
-- 
Arsen Chaloyan
The author of UniMRCP 
http://www.unimrcp.org



________________________________
From: Robert Sparks <[e-mail]>
To: [e-mail]
Cc: [e-mail]; [e-mail]
Sent: Tuesday, September 29, 2009 8:06:47 PM
Subject: [Speechsc] AD review of draft-ietf-speechsc-mrcpv2-20

Hi Folks -

I'm working on moving MRCPv2 along. I've found several things so far
that I'd like to discuss and/or have the document address before we take
the document into IETF last call.

This is a large and complex document. Apologies that my review has taken so long.

After talking with Eric and Dave, I'm sending these all in one message instead
of splitting them into several threads at the beginning. When you reply to a particular
point, it would be useful to me if you adjusted the subject line to indicate which point
you are replying to.

These are not listed in any particular order. Nits are grouped at the end.

Thanks!

RjS
----------------------------------------------------------------------------------------------
(The following apply to revision -20)

1 The Introduction points to RFC4313 for a discussion on why MRCPv2
  does not use RTSP and details on alternatives, but I don't find that
  discussion in 4313. Was that discussion captured somewhere? If so,
  please point to that. Otherwise, modify this text.

2 The SIP examples throughout the draft need to be adjusted to reflect
  correct syntax and intended use. There are several aspects of the SIP
  messages, in particular, that are currently in error. Consider
  showing partial SIP headers focusing only on what's important to the
  example as an alternative to showing full messages (that will have to
  be carefully reviewed). Some examples of issues that need to be
  corrected (this is not exhaustive)
    2.1 Several responses are missing "received=" in their Via header
      fields
    2.2 The o= line in answers (as in offer/answer) must be different
      from the o= line in the offer.
    2.3 The branch parameter values need to be reviewed very carefully -
      the first example incorrectly reuses the branch from the INVITE
      in an ACK to a 200 OK. Then the _next transaction_ also reuses
      the branch.
    2.4 There is a to-tag in the OPTIONS request on page 44

3 The MRCP examples need to be similarly reviewed
    3.1 are all the content-lengths correct? (I think the 2nd message's
      on page 59 isn't)
    3.2 It's ok, probably even a good idea, to elide values that are not
      important to understanding an example, but please be consistent -
      the first message on page 65, for example, has an explicit
      (probably incorrect) MRCP length, but elided the mime-body length
    3.3 The example in section 9.14 shows two RECOGNITION-COMPLETE
      messages to the same RECOGNIZE. Were these intended to show two
      alternate possible responses? If so, the document should make
      that more clear.

4 Returning a SIP 501 at the end of section 4.3 is not the right thing
  to do. 501 means the responding element does not implement the
  method. You are probably looking for 488 Not Acceptable Here.

5 This needs to be run through an ABNF checker. There are production
  rules and terminals missing - they either need to be defined or
  pointers to where they are defined need to be added.

6 The document occasionally mentions an MRCP proxy (there is a 503
  Proxy Timeout code even), but I can't find where such proxies are
  defined? Page 32 also talks about intermediaries.

7 Some additional discussion around connection establishment and
  sharing/reuse is probably needed
    7.1 Where does an element look in a peer's certificate to determine
      it's reached the peer it has intended to reach?
    7.2 What happens if a connection gets closed?
    7.3 Must events come over the connection the request was sent on?
    7.4 There should be some guidance on only reusing connections when
      the identity of the peer matches what was confirmed when the
      connection was opened. (Specifically, if it's possible for an
      MRCPv2 server to host services for more than one domain, you
      don't want to blindly reuse the connection you made to talk to A
      to talk to B just because DNS aimed you to the same address/port
      to reach them.)

8 Section 6.1.2 should be explicit about what it means by "empty header
  field"

9 With respect to the URI indirection mechanisms defined in the draft:
    9.1 Much of the text assumes these URIs will be HTTP/HTTPS. But other
      parts of the text, and the syntax goes out of the way to allow
      arbitrary URI types. Please help look for places where the
      recommendations and requirements stated only make sense when the
      URI is HTTP or HTTPS.
    9.2 There's currently no discussion about authenticating the
      requester seeking access to the resource pointed to by one of
      these URIs. Security considerations should call out that if the
      URI leaks, the content leaks. There should probably also be more
      explicit discussion of how long a server should be expected to
      hold onto the state indicated by such a URI (how long can a
      client expect it to be there, and when does a server decide a
      client or set of clients is mounting a state exhaustion attack?),
      whether it should allow multiple accesses from a single client,
      whether it should allow accesses from multiple clients, and what
      it means to a client if the attempt to access the resource fails.

10 Why is there both a "Fetch Hint" and a "Audio Fetch Hint". Why does
  the syntax allow for extensibility in the values for those fields?

11 On page 111, the document talks about timing between audio flows and
  RECOGNIZE methods. It claims there are "a number of mechanisms" for
  dealing with the race conditions. Would it be possible to list a few
  of these as informative examples? You might also consider pointing
  out that the delta between the start of an audio flow (or the point
  in an ongoing stream that you intended to start RECOGNIZEing) and the
  receipt of a RECOGNIZE command could be quite large if TCP is
  reacting to congestion. The prohibition at the end of the paragraph
  ("MUST NOT buffer anything it receives beforehand.") seems odd.
  What's the rationale for it? Finally - did the group consider
  indicating RTP timestamps in the RECOGNIZE request to indicate where
  to start recognition as one of the mechanisms pointed to above?

12 Why is the record semantic defined in 10.4.7 different from the one
  in 9.4.8/9.4.22 (specifically, by providing a way to request a server
  store something somewhere other than on that server)? Why does this
  section allow an arbitrary URI scheme to be passed in here? What is
  an implementation supposed to do if it doesn't know the scheme? What
  does it do if attempts to use a URI with a scheme it recognizes
  results in failure? The security considerations section should
  discuss how this might be abused by providing a URI that points at a
  victim.

13 What should an element do if it receives a status code that it
  doesn't recognize? If that's not already specified in the document,
  it should be added.

14 Consider additional clarification around "Note that "GET-PARAMS"
  returns header values that apply to the whole session and not values
  that have a request level scope."

15 How are parameters like "Confidence Threshold" and "Sensitivity
  Level" interoperable? Would you expect .5 to mean the same thing to
  two different implementations? I'm guessing that the intent is that
  the server gets to interpret these values in an
  implementation-specific way, and the utility of these knobs is that
  you tune them over time to a given server. If that's right, the text
  should explicitly point that out.

16 Something I'm still trying to think through and would like other
  folks to comment on - apologies if I've missed where this is treated
  already: Can a server ever issue a reINVITE affecting an MRCPv2
  session (to change codecs for example)? If so, are there any places
  in the text that need to call that out?

17 On page 15, there's a requirement that "There MUST be one SDP m-line
  for each MRCPv2 resource to be used in the session. " This looks like
  it would prevent offering things like alternates, v4 and v6, etc. Is
  this what's intended?

18 Nits
    18.1 Section 3 paragraph 2 sentence 1: SIP is not the "session
      management protocol"
    18.2 The word "pipe" is used ("control pipe", "audio pipe" for
      example) with no definition and there are well-defined terms that
      could be used instead.
    18.3 Paragraph spanning pages 15 and 16 - I suggest explicitly noting
      that the reINVITE receives an error response.
    18.4 There is an unnatural break in the flow of the prose on page 16
      when the text shifts from an overview of the protocol to giving
      an example. Suggest breaking the example into a subsection to
      make it clear what you're intending.
    18.5 Please use the terms "header" and "header
      field" consistently and align the use of those phrases with
      the definitions in section 2.1 of RFC 5322.
    18.6 The conditional language in 6.1.1 is hard to follow. In
      particular, the paragraph starting "If both error 404 and
      another" is awkward. Please consider clarifying these clauses.
    18.7 typo on page 43: "veriifcation"
    18.8 The string "ECMAScript" is used once with no definition.
    18.9 The term "kill-on-barge-in" is used without any definition.
      Please add a reference or a definition.
    18.10 Page 121 says: "The Personal-Grammar-URI,"..."is created"... . I
      think you meant to say the resource indicated by that URI is
      created.
    18.11 Consider using "octet" for "byte". In places where you are
      describing lengths, consider talking about whether leading 0s
      have meaning (it would probably be good to explicitly call out
      that you don't want such a string to be interpreted base-8).

_______________________________________________
Speechsc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/speechsc
Supplemental web site:
<http://www.standardstrack.com/ietf/speechsc>