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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you. Based on your comments I have made the following changes to section 13.6 in my working copy (which will be reflected in the next draft):

- Made reference to RFC 4395 Informative rather than Normative.
- Replaced "URL" with "URI"
- Added "Status" of "Permanent"
- Replaced the "Encoding considerations" text with "There are no other encoding considerations for the 'session' URIs not described in RFC 3986 [RFC3986]." and added RFC 3986 as a normative reference. - Removed "The character set for URLs is restricted to US-ASCII." from the Interoperability considerations field.
- Changed "Intended usage" to "URI scheme semantics"
- In the "Security considerations" field, added "Generic security considerations for URIs described in RFC 3986 apply to this scheme as well" and adjusted the remaining text appropriately.
- Added "iesg@xxxxxxxx" in Author/Change controller field.


-- dan

On Mar 17, 2011, at 11:27 AM, Mykyta Yevstifeyev wrote:

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@xxxxxxxxx
   Author/Change controller:  IESG
Good to add the iesg@xxxxxxxx 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@xxxxxxxx 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@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce


_______________________________________________
Speechsc mailing list
Speechsc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/speechsc
Supplemental web site:
&lt;http://www.standardstrack.com/ietf/speechsc&gt;

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]