[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] [IANA #267864] [Fwd: WGLC: draft-ietf-mmusic-rfc2326bis-22]
Magnus,
I hope this review helps..
We will officially review this document in IETF Last Call. Hopefully these comments will assist in getting
the document's IANA section close to perfect.
Best regards,
Michelle
IANA
IANA COMMENTS:
IANA has examined draft-ietf-mmusic-rfc2326bis-22. While the IANA
Considerations in Section 22 are very helpful and quite detailed, IANA has some
comments and questions about the draft.
General questions for the authors:
IANA notes that four registries for RTSP v1.0 are located at:
http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xhtml. IANA
would like to confirm that these registries (Headers, Methods, Option Tags and
Status Codes) are to remain in place for compatibility purposes. Is this
correct?
The structure of the RTSPv1.0 registry was to provide a single repository for
all RTSP parameter registries. One possibility for the new RTSP v2.0 registry
is to simply create a new file/repository for the v2.0 parameters. Another
possibility is to simply extend the existing repository to contain both v1.0
and v2.0 parameters. Which of these options is preferred by the authors?
Upon approval of this document, IANA understands that there are to be four
major actions completed by the IANA:
1] the creation of 18 new registries (see below) in a registry location to be
determined;
2] the registration of three new, permanent URI schemes (in
http://www.iana.org/assignments/uri-schemes.html); and,
3] the registration of three new SDP attributes (in
http://www.iana.org/assignments/sdp-parameters)
4] the registration of a Media Type for text/parameters (in MIME Media Types
registry located at: http://www.iana.org/assignments/media-types/index.html.
Part 1:
=======
IANA understands that eighteen new registries are to be created.
1.1 A new registry called RTSP v2.0 feature-tags. The description of the
contents of the registry is in section 22.1.1 of the draft document. IANA
understands that future registrations are to be done on a first come, first
served basis. IANA also understands that there are four initial values to be
initially registered and that these are documented in section 22.1.3 of the
draft. For each item in the RTSP v2.0 feature-tags registry, IANA understands
that four fields will be registered:
- the name of the feature tag (with rules for the creation of the name
documented in section 22.1.2);
- a description of the feature tag (a simple text string);
- a indication of whether or not the feature tag applies to clients, servers or
proxies (non-exclusively). and,
- a reference for the source of the registry value (e.g. RFC, etc.)
QUESTION TO AUTHORS: Is there a limit on the length of the description? Should
the indication of whether or not the feature tag applies to clients, servers or
proxies be provided as a matrix, or simply text?
1.2 A new registry called RTSP v2.0 Methods. The description of the meaning of
RTSP Methods, the content of the registry, is in section 13 of the draft
document. IANA understands that future registrations are to be done IETF
Standards Action only. IANA also understands that there are ten initial values
to be initially registered and that these are documented in section 13 of the
draft.
QUESTION TO AUTHORS: Should this registry mimic the presentation of Table 7 in
Section 13 of the draft document? If so, could the authors ensure that the
table column headings have full descriptions and provide any advice about which
fields should be in the registry and which are simply guidance for the reader
of the draft?
1.3 A new registry called RTSP v2.0 Status Codes. IANA understands the
description of RTSP v2.0 Status Codes to be "A status code is the three digit
number used to convey information in RTSP response messages." IANA also
understands that future registrations are to be done through IETF Standards
Action only. IANA also understands that there are 46 initial values to be
initially registered and that these are to be extracted from the ABNF
documentation for "Status-Code" in section 20.2.2 of the draft. For each item
in the RTSP v2.0 Status Codes registry, IANA understands that three fields will
be registered:
- the three digit status code;
- the meaning of the status code; and,
- a reference for the source of the registry value.
QUESTION TO AUTHORS: IANA is unsure how to handle the value "extension-code."
Is a separate registration for "setension-code" required?
1.4 A new registry called RTSP v2.0 Headers. IANA intends to use the
description provided in section 22.4.1 of the document for this registry. IANA
understands that future registrations are to be done using Expert Review. IANA
also understands that there are 68 initial values to be initially registered
and that these are to be extracted from Section 16 (57 values) and Section
22.4.3 (11 values) of the draft.
QUESTION TO AUTHORS: For each item in the RTSP V2.0 Headers registry, what
values are recorded? The name, descirption, and reference sufficient, or
should there be other fields for each entry in the registry?
1.5 A new registry called RTSP v2.0 Accept-Credentials policies. IANA
understands the description of RTSP v2.0 Accept-Credentials policies to be
defined in Section 22.5.1 of the document. IANA also understands that future
registrations are to be done through IETF Standards Action only. IANA also
understands that there are three initial values to be initially registered and
that these are "Any" "Proxy" and "User"
QUESTION TO AUTHORS: Beside the name of the Accept-Credentials value and a
reference to where it is defined, are there any other fields that should be in
this registry based on the definitions in Section 19.3.1 of the document?
1.6 A new registry called RTSP v2.0 Accept-Credentials hash algorithms. IANA
understands the description of RTSP v2.0 Accept-Credentials hash algorithms to
be the first sentence of text in Section 22.5.2 of the document. IANA also
understands that future registrations are to be done through IETF Standards
Action only. IANA also understands that there are no initial values to be
registered upon approval of the document.
QUESTION TO AUTHORS: If there were items in this registry, what fields would be
registered for each item (name, reference, etc.)?
1.7 A new registry called RTSP v2.0 Cache Directive Extensions. IANA
understands the description of RTSP v2.0 Cache Directive Extensions to be the
first paragraph of the text in section 22.6 of the document. IANA also
understands that future registrations are to be done through IETF Standards
Action only. IANA also understands that there are 10 initial values to be
registered upon approval of the document and that these are identified in
section 22.6 of the document. For each item in the RTSP v2.0 Cache Directive
Extensions registry, IANA understands that four fields will be registered:
- the name of the directive;
- the definition of the value;
- specification if it is a request or response directive; and,
- a reference for the source of the registry value.
1.8 A new registry called RTSP v2.0 Media Properties. IANA understands the
description of RTSP v2.0 Media Propoerties to be the text in section 22.7.1 of
the document. IANA also understands that future registrations are to be done
using a designated expert. IANA also understands that there are ten initial
values to be registered upon approval of the document and that these are
identified in section 16.28 of the document. For each item in the RTSP v2.0
Media Properties registry, IANA understands that three fields will be
registered:
- the name of the media property;
- a contact name for the property;
- the description of the media property; and,
- a reference for the source of the registry value.
QUESTION TO AUTHORS: IANA understands that the property values identified in
Section 16.28 are to be registered but not the property groups. Is this
correct?
1.9 A new registry called RTSP v2.0 Notify Reason Values. IANA understands the
description of RTSP v2.0 Status Codes to be the first two sentences of the text
in section 22.8.1 of the document. IANA also understands that future
registrations are to be done using a designated expert. IANA also understands
that there are three initial values to be registered upon approval of the
document and that these are to be extracted from the values defined in the
Notify-Reas-val ABNF in Section 20.2.3. For each item in the RTSP v2.0 Notify
Reason Values registry, IANA understands that four fields will be registered:
- the Notify Reason Value;
- the definition of the value;
- a contact name; and,
- a reference for the source of the registry value.
1.11 A new registry called RTSP v2.0 Range Header formats. IANA understands
the description of RTSP v2.0 Range Header formats to be the first sentence of
text in Section 22.9 of the document. IANA also understands that future
registrations are to be done through IETF Standards Action only. IANA also
understands that there are no initial values to be registered upon approval of
the document.
QUESTION TO AUTHORS: If there were items in this registry, what fields would be
registered for each item (name, description, reference, etc.)?
1.12 A new registry called RTSP v2.0 Terminate-Reason Header Redirection
Reasons. IANA understands the description of RTSP v2.0 Terminate-Reason Header
Redirection Reasons to be the first two sentences of the text in section 16.50
of the document. IANA also understands that future registrations are to be
done using a designated expert. IANA further understands that there are two
initial values to be registered upon approval of the document and that these
are in section 22.10.1 of the document. For each item in the RTSP v2.0
Terminate-Reason Header Redirection Reasons registry, IANA understands that
three fields will be registered:
- the Terminate-Reason Header Redirection Reason;
- the description of the reason; and,
- a reference for the source of the registry value.
1.13 A new registry called RTSP v2.0 Terminate-Reason Header Parameters. IANA
understands the description of RTSP v2.0 Terminate-Reason Header Parameters to
be the first two sentences of the text in section 16.50 of the document. IANA
also understands that future registrations are to be done through IETF
Standards Action only. IANA further understands that there are two initial
values to be registered upon approval of the document and that these are in
section 22.10.2 of the document. For each item in the RTSP v2.0 Terminate-
Reason Header Parameters registry, IANA understands that four fields will be
registered:
- the Terminate-Reason Header Parameter;
- the description of the parameter;
- a contact name; and,
- a reference for the source of the registry value.
1.14 A new registry called RTSP v2.0 RTP-Info header parameters. IANA
understands the description of RTSP v2.0 RTP-Info header parameters to be
extracted from section 16,43 of the document IANA also understands that future
registrations are to be done using a designated expert. IANA further
understands that there are two initial values to be registered upon approval of
the document and that these are in section 22.11.3 of the document. For each
item in the RTSP v2.0 RTP-Info header parameters registry, IANA understands
that four fields will be registered:
- the RTP-Info header parameter value;
- the description of the value;
- a contact name; and,
- a reference for the source of the registry value.
1.15 A new registry called RTSP v2.0 Seek-Style Policies. IANA understands the
description of RTSP v2.0 Seek-Style Policies to be extracted from section 16.45
of the document New registry values require specification and a designated
expert. IANA further understands that there are three initial values to be
registered upon approval of the document and that these are in section 22.12.3
of the document. For each item in the RTSP v2.0 Seek-Style Policy registry,
IANA understands that four fields will be registered:
- the Seek-Style Policy value;
- the description of the value;
- a contact name; and,
- a reference for the source of the registry value.
1.16 A new registry called RTSP v2.0 Transport Protocol Specification. New
registry values require speficiation and a designated expert. IANA also
understands that there are 12 initial values to be registered upon approval of
the document and that these are in section 22.13.1 of the document. For each
item in the RTSP v2.0 Transport Protocol Specification, IANA understands that
four fields will be registered:
- the RTSP v2.0 Transport Protocol Specification value;
- the description of the value;
- a contact name; and,
- a reference for the source of the registry value
QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport
Protocol Specification available?
1.17 A new registry called RTSP v2.0 Transport Modes. New registry values
require IETF Standards Action. IANA also understands that there a single
initial value to be registered upon approval of the document and that this is
in section 22.13.2 of the document. For each item in the RTSP v2.0 Transport
Modes, IANA understands that four fields will be registered:
- the RTSP v2.0 Transport Mode value;
- the description of the value;
- a contact name; and,
- a reference for the source of the registry value
QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport Modes
available?
1.18 A new registry called RTSP v2.0 Transport Parameters. New registry values
require Specification and a Designated Expert. IANA also understands that
there are no initial values to be registered upon approval of the document.
QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport
Parameters available? If there were items in this registry, what fields would
be registered for each item (name, description, reference, etc.)?
Part 2:
=======
IANA understands that, upon approval of this document, three new URI schemes
would be registered in the Permanent URI scheme registry located at:
http://www.iana.org/assignments/uri-schemes.html -- these three URIs are:
2.1 URI Scheme Name: rtsp
URI Scheme Description: Real-time Streaming Protocol (RTSP)
Reference: TBD
2.2 URI Scheme Name: rtsps
URI Scheme Description: RTSP over TLS
Reference: TBD
2.3 URI Scheme Name: rtspu
URI Scheme Description: RTSP over unreliable datagram transport
Part 3:
=======
IANA understands that, upon approval of this document, three new SDP attributes
would be registered in the Session Description Protocol (SDP) Parameters
regristry located at http://www.iana.org/assignments/sdp-parameters. These
three entries would be placed in the "- att-field (both session and media
level)" registry. The attributes are:
3.1 SDP name: range
Reference: TBD
3.2 SDP name: control
Reference: TBD
3.3 SDP name: mtag
Reference: TBD
Part 4:
=======
IANA understands that, upon approval of this document, a single entry is to be
added to the MIME Media Types registry located at:
http://www.iana.org/assignments/media-types/index.html.
This entry would be added to the "text" Media Type and would add a new Subtype
of "parameters"
The reference would be TBD.
IANA understands that the creation of eighteen new registries and these three
other actions are all the IANA actions required upon approval of this document.
On Wed Sep 23 11:53:07 2009, magnus.westerlund at ericsson.com wrote:
> Hi,
>
> Michelle has earlier promised me a review of this documents IANA
> section. As it is now in WG last call in MMUSIC I would appreciate if it
> could happen by the end of the WG last call the 19th of October.
>
> The reason we want early review is that the document contains a quite
> extensive IANA section that is 17 pages long that creates a large number
> of registries.
>
> Thanks
>
> Magnus Westerlund
>
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB | Phone +46 10 7148287
> Färögatan 6 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
> ----------------------------------------------------------------------