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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf