Subject: Re: [Speechsc] Comments on draft-ietf-speechsc-mrcpv2-03.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Oct 2004 16:19:26 +0200

Hi Sarvi,

A few comments inline.

Sarvi Shanmugham wrote:
> Magnus Westerlund wrote:
>>
>> 8. Section 2: Do you completely rule out a proxy in MRCPv2? That would 
>> then be a big difference and should be noted in this section. The 
>> reason is that it strongly effects if what you have specified in terms 
>> of methods, signalling will work or not. Also when referencing HTTP 
>> headers, it is important to consider this issue.
> 
> I don't beileve MRCPv2 proxies have been rulled out. If  a proxy exists, 
> I would expect it to be a back to SIP UA which would also proxy the 
> MRCPv2 channel messages coming from the client to the appropriate server 
> behind it.
>

Okay, then if I remember correctly, there is some issues with how things 
are defined. When one has a proxy, one suddenly needs to clarify a lot 
of things, like:
- How does the proxy know where to send a request?
- What changes are allowed to the headers and other parts of the requests.
- How do one perform capability detection/negotiation when one have one 
or more proxies?

Therefore one can't easily put in proxies, they have to be considered 
from the beginning. Thus I think that you will have some problem of 
allowing proxies. I think the WG needs to make a decision if this is 
desired, and secondly if you are willing to spend the time on doing the 
work.

>>
>> 12. Section 3.2, example 2: The offer and answers contain a dynamic 
>> payload type 96 for the audio description that is not mapped. This is 
>> not correct.
> 
> If you are pointing to the missing  mapping line for 96. I will get to 
> it in the next draft.

Yes.

>>
>> 15. Section 3.3, second last paragraph on page 13, last sentence:
>> "The media stream in either
>>     direction may contain more than one Synchronized Source (SSRC)
>>     identifier due to multiple sources contributing to the media on the
>>     pipe and the clientserver SHOULD be able to deal with it. "
>>
>> Please correct "the client server" is it missing a "or"?
> 
> Yes.
> 
>>
>> Also, what do you mean with dealing with it. They are clearly 
>> different sources and unless RTP retransmission is used, performing 
>> speech recognition on different SSRCs are like doing on different 
>> phone lines in some sense, while in others it is natural to do it on 
>> the mixed signal from all sources. Further consideration are needed.
> 
> It is assumed to be one source. But there may be cases where RFC2833 
> DTMF packets arrive on the same RTP pipe but with different SSRCs. I am 
> also not ruling out the case where the server may want to support 
> recognizing hotwords when listening to a conference. There could be 
> different speakers on different SSRC in the multicase case and we might 
> want to respond for anyone saying the "hotword".
> 

Okay, I took a look at section 4.3 in version 05. It is a start, however 
I think you will need a lot of more specification in relation to the 
media transport. The question is how to handle this, when one has 
actually learn what is needed. I have to little knowledge about your 
applications to really help you here. I can compare to RTSP, where it 
has become evident that we needed to clarify a lot about the handling of 
RTP. I would recommend you take a look at section B of 
draft-ietf-mmusic-rfc2326bis-08. I know that this section is not 
directly applicable, however it may given you some points to think over.

I would also consider how the negotiation in the SIP domain for media 
affects the possibility for interoperability.

>>
>> 33. Section 6.1, Cache-Control: So if I understand this correctly, 
>> this header controls how the media server should cache any resource 
>> that are referenced in a request to perform a resource purpose, like 
>> recognition? This is rather different from HTTPs use of the header. It 
>> might be wise to consider to rename it.
> 
> Well the usage of these headers have the same meaning as in HTTP, except 
> that it is not meant for the reltionship between the MRCP client and the 
> server, but the HTTP client on the MRCP server and its cache and its 
> relationship with  the HTTP server where it goes to fetch documents.  
> Which is why these headers have been leveraged from HTTP and their 
> naming has been left the same.
> 

I think that difference is important. In HTTP the cache-control applies 
to the response, while in MRCPv2 it applies to a referenced resource. I 
think one should consider renaming the header to avoid misunderstanding.

By the way, is MRCP intended to be part of the common header registry 
for email and HTTP starts with?

>>
>> 36. Section 8: I think that one should spend some paragraphs on 
>> writing an introduction to each different type of resource describing 
>> its purpose and the normal setup in which it is used. From the 
>> beginning I had some problem understanding how everything worked. It 
>> will make things easier also when some AD is going to read it later.
> 
> Are you refering to any particular resource, coz as I see it each 
> resource does have an introduction in the beginning describing its 
> capabilities.

No, I think it has to do with all the resources. However, it might be 
that I am not knowing the services enough.

>>
>> 56. Section 8.11, Example: The message lengths is clearly wrong.
>>
> I have not tried to exactly match the message length. I don't think that 
> is a requirement is it.

Then you should clearly note that. Because people are considering 
examples very carefully, and any failure to being compliant with the 
specification do confuse people reading the spec.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 22 Oct 2004 14:21:49 -0700

Hi Magnus,

Magnus Westerlund wrote:

> Hi,
>
> I have read some parts of the specification, basically only skipping 
> chapter 9, 10, 11 And Appendix A. Please be aware that I am reading 
> this from the perspective of not knowing the area of speech processing 
> engines. Although I should, I will not make the effort of structuring 
> my comments in different categories.
>
> 1. Status of this memo: The boilerplate will need to be updated. see 
> the new ID checklist and ID guidelines.

Done.

>
> 2. Abstract: Missing space between 2 and (MRCPv2).

Done.

>
> 3. Section 1:
>    "The MRCPv2 protocol is designed to provide a mechanism for a client
>     device requiring audio/video stream processing to control media
>     processing resources on the network."
>
> I found this sentence a bit strange, and think it could be 
> substantially simpler formulated.

Done.

>
> 4. Section 1: "It also describes how these messages are carried
>     over a transport layer such as TCP or SCTP." I think this sentence 
> should consider TLS as secure transport is so important.

Done

>
> 5. Section 1:
>    "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
>     document are to be interpreted as described in RFC 2119[10]."
>
> I would propose that this paragraph is the start of the "Notational 
> Conventions" section, and move the rest of section 4 into this new 
> section 2. The fact is that the current section 4 comes to late, long 
> after several of this conventions are already used.

Done

>
> 6. Section 2: Architecture figure. It should be labelled and numbered. 
> Also please keep it in one page.

Done

>
> 7. Question in relation to section 2.2: Is it correct that you assume 
> that the client will already know where the media resources exist or 
> that some other mechanism is used to learn about them?

I believe the client needs to know the SIP URI pointing to MRCPv2 
server. But it can then use SDP to query the capabilities of the server 
as discussed in the spec.

>
> 9. Section 3.2: I think when writing the rule that all SDP offer with 
> m= lines with MRCP MUST use port 9, it should be clarified in 
> parenthesis that this is the discard port, i.e. 9 (TCP discard port). 
> Please note that port 9 is not registered as discard for SCTP.

Done

>
> 10. Section 3.2, Example 2: I could not find an example 1, prior to 
> example 2.

Done.

>
> 11. Section 3.2, Example 2: In relation to a=cmid. Is the reason that 
> you decided to create the this new attribute for binding them, that 
> the grouping of media line does not allow for multiple groups of the 
> same type to reference the same mid? Otherwise I would think that 
> defining a group method would have been a nicer solution more inline 
> with what exist.

Yes.

>
> 13. Section 3.2, example 3: Is it really obvious that two different 
> recognizes at a server really is capable of accessing the same media, 
> and in consistent manner. In general I think the media handling issues 
> are kind of loosely thought of. One issue that I thought of, does 
> different resources need to use the same amount of buffering, for 
> example if one resource need to be quick and another has more time, 
> then they should have different buffering strategies.

A recognizer and Verifier and Recorder are all feeding of the same 
stream and their response when sharing the stream is expected to be the 
same. Anyway, the spec does not specify if each resource needs to buffer 
on its owne or if they should share a common buffer. That is left to the 
implementation decide.

>
> 14. Section 3.3: The cmid syntax. This defines the syntax, but is not 
> a complete definition of the attribute. You will also have to do an 
> IANA registration of the SDP attribute. Also, the m= lines for control may

Will add an IANA Considerations section to the document.

> also need to have a "a=mid" line to allow for other types of grouping. 
> See RFC 3388.

I agree.

Yes.

>
> 16. Section 3.3, last paragraph on page 13: How does the client know 
> that the Offer was refused due to the fact that the server can't 
> handle sharing the audio pipe?

By failing the SIP INVITE request with say the SIP 501 Not  Implemented 
Server error..

>
> 17. Section 3.2:
> "This m-line
>     will have a media type field of "control" and a transport type field
>     of "TCP", "SCTP" or "TLS". "
>
> I hope you understand that neither SCTP or TLS is defined as proto 
> identifier in SDP. They will need to be registered together with some 
> definition how to use them. Also the TCP is under defined and could 
> benefit from a update.

Made the changes to adopt mechanism of comedia draft per your suggestion 
on a different thread. Which does define these proto identifiers.

>
> 18. Section 3.2 and 3.4:
> In 3.2 the following is written:
> "    All servers MUST support TCP, SCTP and TLS and it is up to the
>     client to choose which mode of transport it wants to use for an
>     MRCPv2 session. "
>
> In 3.4 the following is written:
> "All MRCPv2 based
>     media servers MUST support TCP for transport and MAY support SCTP. "
>
> A nice little inconsistency.

Per discussions on the alias, this has been changed to "TLS, SHOULD 
support TCP and MAY support"

>
> 19. Section 3.4: Are there any rules governing the reuse of MRCP 
> control connections? Can the server or client insist on doing it, and 
> how is it signalled? From a server perspective it must be of interest 
> of avoiding opening either a listening port, or at least one new TCP 
> connection.

The server and client MUST support sharing one or more transport pipes 
across multiple MRCPv2 channels which are recognized by the 
Channel-Identifiers only. But the server cannot mandate this sharing and 
is up the client.

>
> 20. Section 5: Second paragraph: Is it not time to remove the 
> statement that receivers SHOULD interpret CR and LF by themselves. 
> Can't people implement this correctly?

Are you suggesting we should remove the option to have CR or LF only? I 
am fine with this.
Fixed in draft-05

>
> 21. Section 5.1,
> "message-length =    1*DIGIT"
>
> Please consider that it might be more appropriate to actually provide 
> bounded fields. They allow for consistency checking and would simplify 
> implementation. Let say that message length should be limited to 1 
> gigabyte, thus allowing for the value to be stored in a 32 bit-integer 
> and do nice checking that the field does not overflow. Thus I would 
> propose that the syntax is changed to:
> "message-length =    1*10DIGIT"
>
> If a gigabyte is to small, then give it a few more number, but do not 
> make it unlimited length. This applies to a many of the syntax fields. 
> For example request IDs could be restricted to a 64 bit number.
>
> 22. Section 5.1, wrong formatting in fourth paragraph.

fixed.

>
> 23. Section 5.2:
> "The mrcp-version field used here is similar to the one used in the
>     Request Line and indicates the version of MRCPv2 protocol running on
>     the server. "
>
> I think that "similar" is the wrong word here.

fixed.

>
> 24. All ABNF syntax: Lack of defined format for extensions. Almost all 
> syntax is missing definition for which format a extension method, 
> header, parameter, etc. can have. This should really be defined, so 
> that one avoids backwards consideration due to syntax handling when 
> deploying extensions. Example: Current syntax:
> "     request-state    =  "COMPLETE"
>                        |  "IN-PROGRESS"
>                        |  "PENDING"
> "
> Proposed syntax:
>       request-state    =  "COMPLETE"
>                        |  "IN-PROGRESS"
>                        |  "PENDING"
>                        |  req-state-ext
>
>       req-state-ext = 1*(UPPER_ALPHA / "-")

Fixed, methods and header fields. Request state is not extensible.

>
> 25. ABNF syntax: Wrong format of ABNF. This syntax in this spec does 
> not follow 2234. In 2234 ABNF the alternative is "/" instead of the 
> older "|". Please read 2234 and update. Be also aware that all the 
> syntax will need to be complete and go through the syntax checker.

Fixed.

>
> 26. Section 5.2: Status codes:
> Don't you think it is appropriate to use more main status code 
> classes? I would think that 5xx (Server Errors) would be needed.

A few more status codes have been added including 5XX codes per 
discussion in the mailing list.

>
> 27. Section 6.1: It is something strange with the "field-value" syntax 
> definition. Following the text it should allow any number of LWS, 
> followed by content. If broken over multiple lines, then it should be 
> something like (CRLF 1*LWS). I would guess that it should be something 
> like:
>
> field-value = *LWS field-content *(CRLF 1*LWS field-content)
>
Fixed.

>
>
> 28. Section 6.1:
>    "The order in which header fields with the
>     same field-name are received is therefore significant to the
>     interpretation of the combined field value, and thus a proxy MUST
>     NOT change the order of these field values when a message is
>     forwarded."
>
> To much copy paste? If you don't have proxies then this is unnecessary 
> text.

Like I have mentioned earlier. It is possible to have a MRCPv2 proxy in 
between the client and the server that relays the MRCPv2 messages. Plus, 
this may be restriction on the proxy that may come in handy for future 
version of the protocol, where there is a possibility of multiple 
instances of the same header field.

>
> 29. Section 6.1, Active-Request-Id-List: What is "it" in the first 
> sentence?

The request/method. Fixed accordingly.

>
> 30. Section 6.1, Content-Encoding: In the syntax you are using the 
> rule 1#content-encoding. I haven't seen a definition in ABNF for it, 
> so you would need to define it. If you are unable to define it, then I 
> would recommend that you change it to:
> content-encoding *("," *LWS content-encoding)

fixed this and other places that use the 1# rule.

>
> 31. Section 6.1, Content-Encoding: I think you will need to be a bit 
> more explicit on how multiple encoding and their order reflect how 
> things should be done. For example, it is not defined if a second 
> encodings should be written before or after the previous one in the 
> header.

"If multiple encoding have been applied to an entity, the content coding 
MUST be listed in the order in which they were applied. "
I think this covers it well. This means that if say 2 types of 
compression have been applied, say gzip and zcat, they are listed in the 
order in which they were applied to the orginal data to arrive at the 
content attached. i.e. Content-Enconding: gzip, zcat.
To retrieve the data the uncompress operations of each type have to be 
applied in reverse.

>
> 32. Section 6.1, Content-Id: I would recommend that you put a real 
> reference in after RFC 2111.

fixed.

>
> 34. Section 6.1, Set-Cookie:
> "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. "
>
> Sorry I have a bit hard to understand how the cookie flow is between 
> HTTP, across MRCP servers and client. It might be needful to include a 
> section about cookies in MRCPv2.

I have added some text to the beginning of the Set-Cookie and 
Set-Cookie2 definition discussing the usage and intent of these headers. 
Hope this clarifies.

>
> 35. Section 7, S->C SIP message. Is this SIP message really correct. I 
> know to little SIP to be certain. For example should the "Accept" 
> header really be there?

Per section 6.7 of the SIP RFC Accept headers are allowed in INVITE and 
OPTION request and their 2xx or 4xx responses.  Is there something else 
that in this message that is cause for concern.

>
> 37. section 8.4: Why is all headers called parameters. I think a 
> consistent terminology is important.
>
Changed to Headers where appropriate.

> 38. Section 8.4, There is a table describing the different headers and 
> their requirement to be implemented and methods that can use them. 
> However as I found out when editing RTSP and which also SIP has 
> understood, it is not sufficient. It is also good to describe the 
> interesting relations between header and methods, by describing if the 
> header is mandatory, optional, conditional in request or responses. I 
> would recommend that each resource type make a table like table 2 and 
> 3 in section 20 of RFC3261. It should list all the resource methods 
> and the generic methods possible to use in this resource type.

used the table for format you have recommended here.

>
> 39. Section 8.4, Jump-Target. The section name is called Jump-Target 
> while the syntax defines "Jump-Size".

Fixed.

>
> 40. Section 8.4, Kill-On-Barge-In: This issue is shared with all the 
> configuring methods, what scope does they have. Session, request, or 
> server?

Hopefully the new table format is more clear.

>
> 41. Section 8.4, Kill-On-Barge-In:
> "   If the recognizer or signal detector resource is on the same server
>     as the synthesizer, the server should be intelligent enough to
>     recognize their interactions by their common MRCPv2 channel
>     identifier (ignoring the portion after "@" which is the resource
>     type) and work with each other to provide kill-on-barge-in support. "
>
> Should be smart enough? Kind of strange formulation. Either SHALL be 
> it, or MAY be it. I read later on that the client is always requiring 
> to forward a BARGE-IN detection from a recognizer to the TTS. However 
> it seems that it should be clarified through signalling if the server 
> will do this, or if the lesser performance from the client forward 
> method will be required.

I have clarified that the server SHOULD implement the optimization. 
Still, the client MUST relay barge-in events  from the input resource, 
even if they  may be part of the same SIP session since we still want 
this to work where the server doesn't do it, or if there is MRCP proxy 
in between which makes it look like one MRCP session to the client, 
though it may be dealing with separate MRCP sessions behind it.  

>
> 42. Section 8.4, Completion Cause: Syntax of completion cause. Might 
> it not be better to allow a cause description that allows for other 
> characters then ALPHA, like VCHAR?

I agree. Fixed.

>
> 43. Section 8.4, Voice-Parameters and Prosody-Parameters:
> Is this really the best way of providing signalling of these parameter 
> values. Without having looked at the reference, I have no idea what 
> type of data they will need to indicate, neither how many they are. 
> Also what issues exist in extending this. Wouldn't parameters in a 
> header be better? In any case I think that one should at least list 
> the ones that exist. Also what will happen when W3C updates their 
> specification?
>
> Sorry for the inconsistent comment. I am lacking information to 
> determine if defining header in the way you do really is a good way.

I think parameters in the headr would be a better idea. Will change 
accordingly.

>
> 44. section 8.4, Vocie-Parameters:
> "If the synthesizer resource does not support this operation, it 
> should respond back to the client with a status of unsupported." What 
> status code is this? I would recommend that any time on reference a 
> status code to include both number and explanatory string.

will do.

>
> 45. Section 8.4, Failed URI: shouldn't the syntax element be "uri" 
> instead of "url"?

fixed.

>
> 46. Section 8.4, Failed URI cause: Shouldn't the text be VCHAR instead 
> of ALPHA?

fixed.

>
> 47. Section 8.4, Speak Start:
> "   When a CONTROL jump backward request is issued to a currently
>     speaking synthesizer resource and the jumps beyond the start of the
>     speech, the current SPEAK request re-starts from the beginning of
>     its speech data and the response to the CONTROL request would
>     contain this header indicating a restart."
>
> I would replace "would" with normative language SHALL.

fixed.

>
> 48. Section 8.4, Speak Length: This parameter MAY BE ...
> lower case be.
>
fixed.

> 49. Section 8.5: I don't understand how to determine how things 
> included in a multi-part body should be ordered into rendering order?
>
> 50. Section 8.6: Method issue. In several methods, one can get 
> termination or other asynchronous behaviour. However I don't see any 
> mechanism other than speech markers to allow the client to determine 
> how long into the processing was terminated. It might be my lack of 
> understanding of the applications, that I don't understand why the 
> mechanism provided is sufficient. If I would doing this I would 
> provide a EVENT and RESPONSE header that would tell where in the 
> process a SPEAK request was interrupted.

This information is already avaliable through the failure headers which 
describe the cause and reason text along with additional information 
such as which URI failed and with what cause.  Apart from that the 
completion-cause codes also have infromation as to why it failed which 
has information on which stage.
I have also aded the marker header which has timestamp information to be 
sent in other asynchronous events as well. Hope this addresses your concern.

>
> 51. Section 8.6: In a SPEAK response, I would also include a header 
> that gives the current queue of in progress and pending SPEAK requests.

Considering there is a request processing order and that each request 
does return its status. I don't see a need for this.

>
> 52. Section 8.6:
> "This means that this
>     SPEAK request is in queue and will be processed after the currently
>     active SPEAK request is completed."
>
> This sentence implies that the latest SPEAK request would put it self 
> as first in the queue and be played after the completion of the 
> IN-PROGRESS SPEAK request. Please clarify behaviour.

Correct. This means that this SPEAK request will be placed in the 
request queue and will be processed in the other order received after 
the currently active SPEAK request and previously queued SPEAK requests 
are completed. Clarified statement as mentioned here.

>
> 53. Section 8.8:
> "If there were no SPEAK requests terminated
>     as a result of the BARGE-IN-OCCURRED method, the response would
>     still be a 200 success but MUST not contain an active-request-id-
>     list header field. "
>
> the "MUST not" shall be "MUST NOT"

fixed.

>
> 54. Section 8.9: I don't see a method for pausing at a specific point 
> in the provided SPEAK commend. If one likes to pause at specific 
> marker or word, that doesn't seem possible. I would think that 
> providing a block of text to speak, and then something happens that 
> results in that one now should pause after a specific sentence or so. 
> Without protocol support this will be difficult to do nicely. This 
> comment does also apply to CONTROL.

Does any one see a need for this. So far we haven't seen a need for this 
kind a functionality.

>
> 55. Section 8.10:
> "If a RESUME method is
>     issued on a session when a SPEAK is not active the server SHOULD ..."
> I don't think active clearly describes what state you are referring to.

It seems clear. I am not sure how it could be clarified even further. Do 
you have a text suggestion suggestion to improve this..

> 57. Whole specification: Presence of non US 7-bit ascii characters. 
> Please run ID checker or other suitable tool.

will do.

>
> 58. IANA section. For your information you will need to write an 
> fairly extensive IANA section setting up a number of different 
> registries. You will also need to register a number of SDP related 
> entries. I would guess that you will need 5+ number of pages for this 
> section. Look at SIP or my RTSP draft 
> (draft-ietf-mmusic-rfc2326bis-06.txt) for indication what will be 
> required.

being worked on.

>
> 59. Extensensibility. I think you in addition to the IANA section 
> should explain what type of extensions you foresee. And how to handle 
> extensions within a resource type.

Will work on it.

>
> 60 Section 14. The reference table needs to be split into a normative 
> and an informative part.
>
Done.

> 61. Copyright and IPR statement needs to be updated.

This has been updated in the -04 draft.

I appreciate your taking the time to provide a very detailed review of 
the document.
Thanks,
Sarvi

>
>
> I would recommend that you get further WG external review. I will try 
> to read the other resource types, but will not promise any date. If 
> anything is unclear, simply ask for clarification.
>
>
> Cheers
>
> Magnus Westerlund
>