Subject: Re: [Gen-art] Gen-ART review of draft-ietf-speechsc-mrcpv2-24.txt

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

Miguel,

Thank you for your comments.  I have replied to each with either the action I intend to take or the reason why I believe a change is not warranted at this time, with one exception.

There is one item below, regarding the Vendor Parameters registry, which is still under discussion.

Draft-25, which I will post in a few minutes, addresses the comments that I say below that I will address.
It does not address all of the draft-24 review comments received from others, so there will be another draft after the IETF 81 publication moratorium expires.

-- dan

On May 3, 2011, at 2:39 AM, Miguel A. Garcia wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft. For background on Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> 
> Please resolve these comments along with any other comments you may receive.
> 
> Document: draft-ietf-speechsc-mrcpv2-24.txt
> Reviewer: Miguel Garcia <[email-masked]>
> Review Date: 2011-05-03
> IETF LC End Date: 2011-04-13
> 
> Summary: The document is on the right track, but has some issues that should be addressed before publication as a standards track RFC.
> 
> Major issues: none
> 
> Minor issues:
> 
> - Section 4.2 reads:
> 
>   To remain backwards compatible with conventional SDP usage,
>   the format field of the m-line MUST have the arbitrarily-selected
>   value of "1".
> 
> The comment is that in other protocols, for example, MSRP [RFC4975] it
> has been selected to use an asterisk "*" in the format field. I wonder if
> it is possible to unify criteria, in order to allow usage of conventional
> SDP parsers.

I don't see how this has any relationship to "conventional SDP parsers".  Any SDP parser should be able to parse the value "1", and the allowed value is protocol-specific anyway.  Since the values of the media and protocol fields are completely different in our case, and because this would break existing implementations of MRCP, I see no sufficient reason to change the value.

> 
> - Although at the general level the draft says that it reuses the SDP
> offer/answer model, I think it would be good to explicitly mention it,
> just explicitly indicate that "we aren't doing anything new here". For
> example, in Section 4.2, the text reads
> 
>   When the client wants to add a media processing resource to the
>   session, it issues a SIP re-INVITE transaction.
> 
> and I think it would be better to say:
> 
>   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 [RFC3264], in a SIP re-INVITE request.

I will make this change.

> 
> Also, on page 17, the text reads:
> 
>   When the client wants to de-allocate the resource from this session,
>   it issues a SIP re-INVITE transaction with the server.  The SDP MUST
>   offer the control m-line with port 0.
> 
> It could be completed with:
> 
>   When the client wants to de-allocate the resource from this session,
>   it issues a new SDP offer, according to RFC 3264 [RFC3264], where the
>   control m-line port MUST be set to 0. This SDP offer is sent in a SIP
>   re-INVITE request.

I will make this change.

> 
> - Section 4.2 describes the usage of the a=setup attribute, but it does
> not clarify if setting up MRCP sessions MUST always use the a=setup
> attribute or not. I think the answer is yes, at least for TCP or TLS
> transports (those defined in this version of the draft). But there should
> be a "MUST use the 'setup' attribute as per RFC 4145" somewhere. I
> recommend to add the following sentence at the beginning of the last
> paragraph in page 16:
> 
>   MRCVv2 clients and servers using TCP as a transport protocol MUST use
> the procedures specified in RFC 4145 [RFC4145] for setting up the TCP
> connection, with the considerations described hereby. Similarly,  MRCVv2
> clients and servers using TCP/TLS as a transport protocol MUST use the
> procedures specified in RFC 4572 [RFC4572] for setting up the TLS
> connection, with the considerations described hereby. The 'setup
> attribute, as described ... [continue with the current text]

I will make this change.

> 
> - Section 5.1. The ABNF of "mrcp-version", at the top of page 26, comes
> out of the blue: there is no "mrcp-version" in the ABNF on page 25, so,
> it is difficult to find out how to put "mrcp-version" into context.

Because this section describes common protocol elements, its ABNF will be out of context of the (multiple) locations in which it is relevant.  The normative ABNF definitions in Section 15 already make clear where various productions are used.  Moreover, the preceding text already explains that the MRCP version is used in request, response, and event messages and that these messages are described in following sections.  However, for convenience I will include very explicit forward references to where productions using "mrcp-version" can be found.

> 
> - Section 5.4, in the client failure table, the description of the 407
> contains a normative text "MAY BE". I think these tables are an
> informative summary. All the normative text should be written in detail
> elsewhere in the document. You can safely turn them lowercase.

I will change "MAY BE" to "might be".

> 
> - On Section 8.5.1 the spec talks about using the multipart/mixed Media Type. It is not clear to me if implementation of multipart/mixed is a MUST or a MAY that is negotiated.

It is a MUST.  I will reword this sentence to clarify that implementations must support this capability.

> 
> - On Section 8.6, first paragraph, the text reads:
> 
>  The SPEAK" method can carry voice and prosody....
> 
> I guess the "can" should be replaced by a normative "MAY".

I will make this change.

> 
> - On Sections 9.4.9, 10.4.8, and 11.4.11, there is no indication of the possible values of the "media-type-value". I guess you want to say that these are intended to be MIME types (so far, the word "MIME type" is not written), and in that case, you should also say that possible values are any of the values included in the MIME media types registry maintained by IANA.

I originally referred to these as MIME types.  However, a prior reviewer assured me that "media type" was the more proper term (since MIME is about Internet Mail and media types are used for much more than email), so I replaced every instance of "MIME type" with "media type".  I would need a very strong argument to change them all back.

Regarding possible values, as explained in section 6.2.6 each resource type describes the content types that are appropriate.  However, I will clarify in section 6.2.6 that "registered Media Types" refers to the IANA media type registry.

I will also add the appropriate ABNF to section 6.2.6 since it seems to be missing.

> 
> - On Sections 9.4.11, 10.4.3, and 11.4.16, the ABNF merely reads:
> 
>    completion-cause       = "Completion-Cause" ":" 3DIGIT SP
>                                              1*VCHAR CRLF
> 
> I am assuming that when the ABNF refers to "3DIGIT", these are supposed to be any of the values included in the "Cause-Code" column of the table in the same section. Similarly, I am assuming that the "1*VCHAR" should include any of the values of the "Cause-Name" column in the same table. I think this should be spelled out. I suggest to change the ABNF for this one:
> 
>    completion-cause       = "Completion-Cause" ":" cause-code SP
>                                             cause-name CRLF
>    cause-code                 = 3DIGIT
>    cause-name                = *VCHAR
> 
> And then do the missing mapping with a text similar to:
> 
> "The 'cause-code' contains a numerical value selected from the Cause-Code column of the following table. The 'cause-name' contains the corresponding token selected from the Cause-Name column.
> 
> Note that the resolution of this issue should be also applied to Sections 10.4.3 and 11.4.16.

I will make this change.

> 
> - Question: In Sections 9.4.21 and 10.4.6, should "1*UTFCHAR" be included in quotes? It is true that there is no other subfield in the same header, meaning that there is no intention to parse the text. But somehow I feel safer if you enclosed the text in quotes. Also, remember that this text is coming from other protocol beyond your control, so you never know, for example, if the other protocol is going to add CRLF or something weird that will crash the recipient of the header.
> 
> Note that the resolution of this issue should also be applied to Section 10.4.6.

I checked with my engineer implementing this.  We don't see how this is any different from, say, "Subject:" in SIP, which also allows unquoted descriptive text, except that MRCP specifically does not allow LWS.  Just like for any other descriptive header field that does not allow LWS, if the sender includes a CRLF as content it will be interpreted as an end to the header, quote or no.
I do not plan to make a change at this time.

> 
> - On Section 9.4.26, the ABNF reads:
> 
>   recognition-mode   = "Recognition-Mode" ":" 1*ALPHA CRLF
> 
> However, there is only to values for choice, "normal" and "hotword". I think the following ABNF represents better that there is only two possible values:
> 
>  recognition-mode   = "Recognition-Mode" ":"
>                                        normal-value / hotword-value
>  normal-value            = "normal"
>  hotword-value          = "hotword"

I will make this change.

> 
> - Section 9.4.40. I wonder why the Phrase-NL is defined as UTFCHAR, while most of the other headers are defined as VCHAR

The other headers are all identifiers of some sort -- they identify a language, or they reference some entry in a table or database.  Limiting them to be VCHAR values is reasonable.
This value is an actual human language text string, and as such could be Chinese, Cyrillic, etc.  Full UTF is necessary.

> 
> - Section 9.9, third paragraph, the text reads:
> 
>   "If the client needs to explicitly control grammar weights for the recognition operation, it must employ method 3 below. "
> 
>  I guess the "must" should be a "MUST".

I will make this change.

> 
> - Section 9.9, the paragraph that goes after bullet point number "3", the text reads:
> 
>  "In addition to performing recognition on the input, the recognizer may also enroll the collected utterance in a personal grammar if the ..."
> 
>  Here the "may" should be a "MAY".

Actually, this should be a MUST.  I will make this change.

> 
> - Section 9.9, bullet point number 1 on page 114:
> 
>  "the recognizer must complete ...."
> 
>  I guess the "must" should be a "MUST". There is another instance with the same text on bullet point number 1 on page 115.

I will make this change (in both places).

> 
> - Section 9.9, bullet point number 2 on page 115:
> 
>  "the RECOGNIZE completes with ..."
> 
>  I guess it should be normative: "the RECOGNIZE MUST complete with ..."

This needs to be rewritten.  It should say "If at any point a match occurs, the RECOGNIZE MUST complete with ...".
I will make this change.

> 
> - Section 9.17, the text reads:
> 
>  "The END-PHRASE-ENROLLMENT method may be called ONLY during an active phrase enrollment session. "
> 
>  Two issues: First, the "may" should be a "MAY". Second, I guess the readability is increased if the sentence is turned into active. What about this:
> 
>  "The client MAY call the END-PHRASE-ENROLLMENT method ONLY during ..."

I will make this change.

> 
> - Section 9.17, the text reads:
> 
>  "... the client can abort ..."
> 
>  I guess the "can" should be a "MAY".

Agreed.  I will make this change.

> 
> - Section 9.17, second paragraph. The text should clearly indicate the name of header where the 'location/URI' should be included.

Agreed.  I will add this.

> 
> - In Section 10.4.7, I would like to clarify that if the record-uri is not sent in the header, then the actual audio should be sent as a MIME body. I would suggest to replace:
> 
> If this header field is not specified in the RECORD request, the server MUST capture the audio and send it in the "STOP" response or the RECORD- COMPLETE event as a message body.
> 
> with this text:
> 
> If this header field is not specified in the RECORD request, the server MUST capture the audio, MUST encode it as a MIME body, and MUST send it in the "STOP" response or the RECORD- COMPLETE event.

I disagree with the "encode it as a MIME body, and MUST send it in" wording since I am not using the term "MIME" for Media Types.  I will use the following instead:  "encode it, and MUST send it in".

> 
> - In Section 10.4.7, I believe you should write normative text at the end of paragraphs 1 and in paragraph 3. Also, in paragraph 3, you need to add references to all the valid schemes and add the 'cid' scheme. And perhaps write all the scheme names in lowercase.
> 
>                                                 In this case, the response
> carrying the audio content MUST include a Content ID (cid) [RFC2392] value in this header
> pointing to the Content-ID in the message body.

I will make this change.

> 
> And in the the third paragraph:
> 
> Implementations MUST only use 'http', 'https' [RFC2616], 'file' [RFC3986], and 'cid' [RFC2392] schemes in the URI. Other URI schemes MUST NOT be used. Note, however, that implementations already exist that support other schemes.

We have worked on this wording several times, and ultimately we do not want to prevent other schemes.  I will change the wording to the following:

Implementations MUST support 'http', 'https' [RFC2616], 'file' [RFC3986], and 'cid' [RFC2392] schemes in the URI.  Note that implementations already exist that support other schemes.

> 
> - Section 10.5. Perhaps a reference to Section 10.4.7 should be added, because the details are described in 10.4.7.

I will make this change.

> 
> - Sections 4.2 and 10.6. The text says that if physical security is provided, one can void TLS and merely used TCP. I have the feeling that the connection of these two concepts (physical security and lack of TLS) is not sufficiently justified for the security experts. One could access the resources of the MRCP server remotely, via a TCP connection, not using TLS. Or even sniff the network. So, physical security is not enough for voiding TLS.

Many of the deployments of MRCP are single-box deployments, or deployments contained completely in fixed-topology, few-node, local-area networks in physically-secure rooms.  Both of these are situations where neither remote access nor network sniffing are issues unless physical access to machines is compromised, in which case few security models are sufficient.  We do not want to require the use of TLS for such deployments.
I expect that "the security experts" you mention will express an opinion if there is a problem with this.

> 
> - Section 11.4.2. I am missing more normative strength text here. For example:
>  + a couple of occurrences of "is required" should be set to "MUST be present"
>  + "may" should be "MAY"
>  + "can" should be "MAY"

I will make these changes in this section.

> 
> - Section 11.5.2.10. I am missing more normative strength text. In particular, a couple of occurrences of "must" in the first paragraph should be "MUST".

I will make this change.

> 
> - Section 11.6, 7th paragraph. I am missing more normative strength text. When the text say:
>  "... operations may be performed on the verifier resource". The "may" should be a "MAY".

I will make this change.

> 
> - Section 12.1, bullet point 1. Although the text says that clients and servers MUST support digest authentication, I think they SHOULD use it (isn't that the intention). In particular, the server SHOULD authenticate the client using SIP digest authentication. Also, a reference to RFC 3261 should be added here.

I will make this change.

> 
> - Section 12.1, bullet point 2. I agree that clients and servers SHOULD employ 'sips' URIs, but I guess the 'sips' is just the format of the underlying TLS security. I guess you should add "including that clients and servers SHOULD setup up TLS [ref] connections".

I will make this change.

> 
> - Section 12.3. The last word of this section, "recommended", should be normative: "RECOMMENDED".

I will make this change.

> 
> - Section 13.1.6 describes a mechanism where vendor-specific extensions use the reverse DNS mechanism, for example., "com.example.foo". Then, if the vendor-specific extension is connected to DNS to avoid clashes in names, why is there a need for an expert review policy prior to its registration? I see a contradiction in having a self-managing registry by avoiding clashes due to the connection to DNS, and then having anything else than a volunteer registry.

(I have not yet addressed this item.  Eric Burger and I disagree on how to reply to your request.  I will need to provide an update to this item after draft-25.)

> 
> - Section 13.7.2 registers new SDP "att-field" at the *session-level* (at least according to the title in Section 13.7.2. However, the text of both registers reads "media-level" in the type of attribute. So, are these two session-level or media-level SDP attributes? I think they are media-level, in which case, they both should be written in Section 13.7.3, which is the SDP "att-field" registration at the media-level.

I will make this change.

> 
> - I think it is not correct to have normative text (capitalized) in the examples, because examples are informative by nature. The text around the examples should describe what is happening. If there is a need for normative text, then it should be already written elsewhere, and if it isn't, it should be written in the normative sections, but not in the examples. So, I found the following instances of normative text in Section 14:
>  + RECOMMENDED on page 186
>  + A couple of MUST on page 187
>  + MUST on page 189

I will find normative text sections to which to move the normative text.

> 
> - Sections 16.3 and 16.3. If these are schema definitions, then why don't they start with:
>  <?xml version ="1.0" encoding="UTF-8"?>
>  and the namespace definition, like any other XML schema document?

Keep in mind that these  (16.2 and 16.3) are RelaxNG, not XML Schema, documents.  As such, the namespace definition is already provided in the root element of each document.
However, as XML documents they should all begin with the xml header.  I will add it.

> 
> Nits:
> ====
> 
> - Expand acronyms at first occurrence. This includes: SSML, NLSML, VXML, RTSP

I did not do this because I assumed the document links were sufficient (since the document titles themselves all expand the acronyms).  However, since another reviewer made the same comment I will skim for these and correct any I find.

> 
> - General to all the examples containing SDP. In Section 4.3. I think the "o=" lines are not correct, in particular, the IP address in the o= line is set to "192.0.2.4" in both the offer and the answer. So, the first thing is that it should be a different value in the offer and the answer. The second thing is that it should typically be equal to the IP address that we see in the c= line, unless you have a very good reason for it. Since it is not the goal of the spec to deal with these rare use cases, I would recommend to set the IP address in the o= line to become equal to that in the c= line.
> 
> This  also applies to the example in Section 7 and the examples in Section 14.

I will change the examples as you suggest.

> 
> - General to all the examples containing SDP. According to RFC 3264 you must include a "t=0 0" line in all the SDP offers and answers.

I will make this change.

> 
> - General to all the examples containing SDP. There is an "s=" line that contains text. According to RFC 3264, it is RECOMMENDED that it contains a white space or a dash "-". If you want to add a subject, the SIP Subject header field serves the purpose.

Putting these values in is legal per 4566, and allowed by 3264 (RECOMMENDED is a synonym for SHOULD). 
They significantly improve the readability of the examples.  I will add a statement reminding the reader that these are illustrative examples and that 3264 recommends that messages actually put on the wire use a space or dash.

> 
> - Section 5, add a formal reference to ISO 8859-1 when the text mentions it.

I will make this change.

> 
> - It would be good to have numbers in those tables in Section 5.4. I
> mean, there should be a caption saying "Table 1: Success 2xx response codes".

I am using XML2RFC.  If I can figure out how to get it to number the tables I will do this.

> 
> - In Sections 9.4.21 and 10.4.6, add a formal reference to RFC3629 when you name "UTF-8".

Will do.

> 
> - Section 9.6.3.3., 1st bullet point:
>  s/contains an float/contains a float

Will fix.

> - Section 9.6.3.4, add a formal reference to ISO 8601 when the text mentions it.

Will do.

> 
> - Section 9.9, bullet point numbered "3". Add a reference to the document that defines the  "3C grammar weights"

Will do.

> 
> - Section 9.9, the first paragraph on page 114,
> s/The No-Input-Timer MUST BE started/The No-Input-Timer MUST be started

Will fix.

> 
> - Section 10, add a formal reference to RFC 2326 when mentioning RTSP.

Will do.
> 
> - Around Section 10.4.7, it would be good to write a simple example showing a message body that includes the audio. This is to see an example of a 'cid' URI scheme.

Getting this right is tricky, and I'd rather not make a mistake on this one that causes yet another comment by someone who will actually take the example, uncompress and unencode it, and try to play it!  If someone contributes one I will be happy to include it.

> 
> - General: Names of URI schemes should be written in lowercase, for example: 'https' URI scheme. There is an instance in Section 10.6, page 135. Other instances of "SIPS:" are in Section 12.1

Okay.  As I find these I will correct them.

> 
> - Starting in Section 10.6, but with many occurrences after that, there is a message from the Server to the Client which is written as "MRCP/2/0", where the second "/" should actually be a ".", such as: "MRCP/2.0".

I will fix these.

> 
> - Sections 9.20 and 9.21. The third message of the example starts with this line:
> 
> S->C: MRCP/2.0 ... INTERPRETATION-COMPLETE 543267 200 COMPLETE
> 
> The request-id value is 543267. However, the request-id of the client is 543266. I guess this request-id should also be 543266.

I will correct this.

> 
> - Section 10.6, 10.7, 10.8. The request-id of the request is set to 543257. However, the request-id of the following responses are all set to 456234. I guess they should all be set to the same value.

I will correct this.

> 
> - Section 10.8, page 137, first paragraph:
>  s/audio ./audio.

I will make this change.

> 
> - Section 11, fourth paragraph:
>  s/'multi-verification.'/'multi-verification'.

I will make this change.

> 
> - Section 11.1. The request-id of the fifth message is set to 314164, however, it should be set to 314162, because it is a response to the forth message.

I believe you mean section 11.11.  I will correct this.

> 
> - Section 11.5.1. There is a closing bracket ")" at the end of the first sentence, for which there isn't an opening bracket.

I will correct this.

> 
> - Section 13.1.1. The registry of the set-cookie and set-cookie2 point to the wrong RFC. They should point to RFCs 2109 and 2965, respectively.

I believe you mean section 13.1.3.  If so, then I respectfully disagree.  Because of the extra text needed to explain how they work in MRCPv2, it is appropriate to refer the reader to the MRCP specification.  In section 6.2.15 where they are defined there are abundant references to the two RFCs you mention.

> 
> - Section 13.1.3. I would suggest to split this long registry and create five separate registries, one per resource type and the Generic. This simplifies if in the future someone wants to add a new, e.g., Synthesizer header. With the current registry, IANA will add the new at the end of the registry, after the last header of the Verifier, and most people will miss this new hypothetical Synthesizer header. If you create five different registries, then the problem will be solved.

I agree with you in principle but not in practice.  In practice, I expect
a) that there will be few new headers, and
b) that if there are more headers, we are likely to create a successor to MRCP that does split out all the text of all the different resources, not just the registries, into separate documents.
For these reasons, and because some of the values are shared today, I plan to leave them as a single registry for now.

> 
> - Sections 13.7.1 and 13.7.2. There are two tokens being registered in each Section. Can you add an empty line in between these two registrations (within the same Section) for the sake of readability?

Hmm, XML2RFC did this.  If I can find a way to add an empty line I will do so.

> 
> - Section 14.1. The example at the top of page 182, the "m=" line reads:
> 
>  m=audio 49170 RTP/AVP 0 96
> 
>  However, there is no "a=rtpmap:96" line and an "a=fmtp:96" describing what the media type "96" is. I guess 96 represents a telephone event, in which case, you should add:
> 
>  a=rtpmap:96 telephone-event/8000
>  a=fmtp:96 0-15

I will make this change.

> 
> - Next to last paragraph on page 187, the text reads "... turn around and issued a ...".
>  s/issued/issue

This text has been removed due to other changes above.

> 
> - First sentence on page 189:
>  s/a SIP BYE/a SIP BYE request

I will correct this.

> 
> - Idnits reveals:
> ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888)

I will update this.

> ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965)

Addressed in the shepherd document.

> ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646)

I will update this.

> ** Downref: Normative reference to an Experimental RFC: RFC 2483

Addressed in the shepherd document.

> -- Obsolete informational reference (is this intentional?): RFC 2234 (Obsoleted by RFC 4234)

I will update this.

> Regards,
>      Miguel Garcia
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 19 Jul 2011 09:27:16 +0200

Hi Dan:

I have some further discussions on a couple of comments. I have deleted 
from this e-mail all those comments for which no more discussion is needed.

On 12/07/2011 1:40, Dan Burnett wrote:
> Miguel,
>
> Thank you for your comments. I have replied to each with either the
> action I intend to take or the reason why I believe a change is not
> warranted at this time, with one exception.
>
> It does not address all of the draft-24 review comments received from
> others, so there will be another draft after the IETF 81 publication
> moratorium expires.
>
> -- dan
>
>> Reviewer: Miguel Garcia <[email-masked]
>> <mailto:[email-masked]>>
>> Review Date: 2011-05-03
>> Summary: The document is on the right track, but has some issues that
>> should be addressed before publication as a standards track RFC.
>>
>> Major issues: none
>>
>> Minor issues:
>>
>> - Section 4.2 reads:
>>
> I don't see how this has any relationship to "conventional SDP parsers".
> Any SDP parser should be able to parse the value "1", and the allowed
> value is protocol-specific anyway. Since the values of the media and
> protocol fields are completely different in our case, and because this
> would break existing implementations of MRCP, I see no sufficient reason
> to change the value.

Let me give you an example. If I have an SDP class that encodes SDP, the 
class would not be able to decide whether to write an asterisk "*" or a 
"1" in the format field, when you invoke it. Writing "1" or "*" will be 
dependent on the application.

Then, if you see an SDP body captured by Wireshark or similar, you will 
need to know which application generated it before you could decided 
whether the SDP is correct or not. And Wireshark will not be able 
indicate "format is irrelevant" until it knows which application carried 
that SDP.

I haven't heard a good reason for keeping the value "1". So, I am still 
proposing to reuse the "*".

>> - On Sections 9.4.9, 10.4.8, and 11.4.11, there is no indication of the
>> possible values of the "media-type-value". I guess you want to say that
>> these are intended to be MIME types (so far, the word "MIME type" is
>> not written), and in that case, you should also say that possible
>> values are any of the values included in the MIME media types registry
>> maintained by IANA.
>
> I originally referred to these as MIME types. However, a prior reviewer
> assured me that "media type" was the more proper term (since MIME is
> about Internet Mail and media types are used for much more than email),
> so I replaced every instance of "MIME type" with "media type". I would
> need a very strong argument to change them all back.

Yes, you are right, the terminology used these days is "media types", so 
keep on using it.

>> - Question: In Sections 9.4.21 and 10.4.6, should "1*UTFCHAR" be
>> included in quotes? It is true that there is no other subfield in the
>> same header, meaning that there is no intention to parse the text. But
>> somehow I feel safer if you enclosed the text in quotes. Also, remember
>> that this text is coming from other protocol beyond your control, so
>> you never know, for example, if the other protocol is going to add CRLF
>> or something weird that will crash the recipient of the header.
>>
> I checked with my engineer implementing this. We don't see how this is
> any different from, say, "Subject:" in SIP, which also allows unquoted
> descriptive text, except that MRCP specifically does not allow LWS. Just
> like for any other descriptive header field that does not allow LWS, if
> the sender includes a CRLF as content it will be interpreted as an end to
> the header, quote or no.

Ok, it is fine to leave it as is.

>>
>> - Sections 4.2 and 10.6. The text says that if physical security is
>> provided, one can void TLS and merely used TCP. I have the feeling that
>> the connection of these two concepts (physical security and lack of
>> TLS) is not sufficiently justified for the security experts. One could
>> access the resources of the MRCP server remotely, via a TCP connection,
>> not using TLS. Or even sniff the network. So, physical security is not
>> enough for voiding TLS.
>
> Many of the deployments of MRCP are single-box deployments, or
> deployments contained completely in fixed-topology, few-node, local-area
> networks in physically-secure rooms. Both of these are situations where
> neither remote access nor network sniffing are issues unless physical
> access to machines is compromised, in which case few security models are
> sufficient. We do not want to require the use of TLS for such deployments.

I'm sympathetic with the spirit of the text. But once more, the lack of 
TLS is not only connected to physical security, as I understood in the 
draft. I think TLS can be omitted in controlled environments (e.g., not 
in the public Internet) where both nodes are inside a protected 
perimeter, for example, preventing access to the MRCP server from remote 
nodes outside the controlled perimeter.

> I am using XML2RFC. If I can figure out how to get it to number the

The trick is to write an 'anchor' attribute and presumably a 'title' 
attribute as well, for example:

<texttable anchor="table_ex" title="IETF Meetings in 2005">

Source: http://xml.resource.org/xml2rfcFAQ.html#anchor27

>>
>> - Sections 13.7.1 and 13.7.2. There are two tokens being registered in
>> each Section. Can you add an empty line in between these two
>> registrations (within the same Section) for the sake of readability?
>

Try adding an &nbsp; symbol. Or an empty paragraph.

BR,

        Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Robert Sparks <[email-masked]>
Date: Tue, 19 Jul 2011 14:08:11 -0500

Replying to just one part
On Jul 19, 2011, at 2:27 AM, Miguel A. Garcia wrote:

> Let me give you an example. If I have an SDP class that encodes SDP, the class would not be able to decide whether to write an asterisk "*" or a "1" in the format field, when you invoke it. Writing "1" or "*" will be dependent on the application.
> 
> Then, if you see an SDP body captured by Wireshark or similar, you will need to know which application generated it before you could decided whether the SDP is correct or not. And Wireshark will not be able indicate "format is irrelevant" until it knows which application carried that SDP.
> 
> I haven't heard a good reason for keeping the value "1". So, I am still proposing to reuse the "*".

Miguel - your SDP class will have to ask the application what the <fmt> field means for a given <proto> field value _anyhow_ to populate it correctly.
Similarly, something like wireshark will have to recognize what is in the <proto> field to do any higher level of verification beyond
the basic syntax in 4566 (which is to match a token as 4566 defines token, and either * or 1 will match).

As Dan points out already there is deployed code that this change would break, and I don't see the benefit you are arguing for.

RjS

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 20 Jul 2011 08:13:22 +0200

On 19/07/2011 21:08, Robert Sparks wrote:
> Miguel - your SDP class will have to ask the application what the<fmt>  field means for a given<proto>  field value _anyhow_ to populate it correctly.
> Similarly, something like wireshark will have to recognize what is in the<proto>  field to do any higher level of verification beyond

Ok, I understand your motivation. Let's keep the draft as is in this aspect.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain