Re: Last Call: <draft-ietf-speechsc-mrcpv2-24.txt> (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard

Hello all,

I'd like to comment the some sections regarding section 13.6 of 
draft-ietf-speechsc-mrcpv2-24, that is currently in Last Call.

So, some comments in-line.

> 13.6.  session URL scheme registration
>
>     IANA is requested to register the following new URI scheme.  The
>     information below follows the template given in RFC4395 [RFC4395].
Here informative reference to RFC 4395 will be more appropriate.  
Moreover, below URL should be replaced by URI, per RFC 4395.
> URL scheme name:  "session"
What status is requested - Permanent or Provisional?
>     URL scheme syntax:  The syntax of this scheme is identical to that
>        defined for the "cid" scheme in section 2 of RFC2392.
>     Character encoding considerations:  URI values are limited to the US-
>        ASCII character set.
Here it would be better to say that "There are no other encoding 
considerations for the 'session' URIs not described in RFC 3986 
[RFC3986]" with a normative reference to RFC 3986 or have a normative 
reference to ASCII standard.
>     Intended usage:  The URI is intended to identify a data resource
>        previously given to the network computing resource.  The purpose
>        of this scheme is to permit access to the specific resource for
>        the lifetime of the session with the entity storing the resource.
>        The media type of the resource CAN vary.  There is no explicit
>        mechanism for communication of the media type.  This scheme is
>        currently widely used internally by existing implementations, and
>        the registration is intended to provide information in the rare
>        (and unfortunate) case that the scheme is used elsewhere.  The
>        scheme SHOULD NOT be used for open internet protocols.
I cannot find such field in RFC 4395 template.  Maybe you meant URI 
semantics?
>     Applications and/or protocols which use this URL scheme name:  This
>        scheme name is used by MRCPv2 clients and servers.
>     Interoperability considerations:
>        The character set for URLs is restricted to US-ASCII.  Note that
>        none of the resources are accessible after the MCRPv2 session
>        ends, hence the name of the scheme.  For clients who establish one
>        MRCPv2 session only for the entire speech application being
>        implemented this is sufficient, but clients who create, terminate,
>        and recreate MRCP sessions for performance or scalability reasons
>        will lose access to resources established in the earlier
>        session(s).
>     Security considerations:  The URIs defined here provide an
>        identification mechanism only.  Given that the communication
>        channel between client and server is secure, that the server
>        correctly accesses the resource associated with the URI, and that
>        the server ensures session-only lifetime and access for each URI,
>        the only remaining security issues are those of the types of media
>        referred to by the URI.
You should also have mentioned that generic security considerations for 
URIs described in RFC 3986 apply to this scheme as well.
>     Relevant publications:  This specification, particularly sections
>        Section 6.2.7, Section 8.5.2, Section 9.5.1, and Section 9.9.
>     Contact for further information:  Sarvi Shanmugham, sarvi@cisco.com
>     Author/Change controller:  IESG
Good to add the iesg@ietf.org address here.

Thanks for considering my comments in advance.

Mykyta Yevstifeyev

16.03.2011 21:13, The IESG wrote:
> The IESG has received a request from the Speech Services Control WG
> (speechsc) to consider the following document:
> - 'Media Resource Control Protocol Version 2 (MRCPv2)'
>    <draft-ietf-speechsc-mrcpv2-24.txt>  as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-04-13. (This allows an additional two
> weeks for review since the document is large and the review period overlaps
> the Prague IETF meeting). Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>