ietf
[Top] [All Lists]

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

2011-03-17 10:32:52
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(_at_)cisco(_dot_)com
    Author/Change controller:  IESG
Good to add the iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>