Media Type Specifications and Registration Procedures
draft-freed-media-type-reg-05

[Ballot comment]
Email from Scott about a phone call with Ned and John on 7/25.  They have an 05 that includes a
cleanup of the steps to make it clearer, text that I'd seen, but also that makes the ietf-types
review MUST for both stds and ietf, as I requested.  This was not accepted in our original
several email dialogs in May, though Scott reports that this is not recalled by the author as
such :(

I've removed my Discuss in favor of Scott watching the draft till the revision comes out after
IETF 63.

[Ballot discuss]
The IESG has decided to ask the community explicitly about the
possibility that the namespaces will be disjoint.  draft-iesg-media-type
documents that question to the community, and community
discussion of that is expected.

I expect to drop this DISCUSS once the community discussion has
concluded whatever the outcome; my primary concern was an
ambiguity of interpretation, and I believe that discussion will
resolve it.

[Ballot discuss]
As a long time user of Media type review, I find Section 5 is not
organized so as to best funnel users to the behavior the Applications
Area is now using for media reviews:


The first paragraph needs to go, because it says:

  The following procedure has been implemented by the IANA for review
  and approval of new media types.  This is not a formal standards
  process, but rather an administrative procedure intended to allow
  community comment and sanity checking without excessive time delay.


About this paragraph:

  In all cases notice of a potential media type registration MAY be
  sent to the "ietf-types@iana.org" mailing list for review.  This
  mailing list has been established for the purpose of reviewing
  proposed media and access types.

This paragraph should also say that all the standards and ietf types
MUST be sent there for two weeks.

About this:

  > Vendor and personal types will be
  > registered by the IANA automatically and without any formal review as
  > long as the following minimal conditions are met:

"without any formal review" seems a little strong - the IANA has the
Expert review those conditions, I think you probably need to say, "with
only a minimal review"

[Ballot discuss]
I'd like to discuss the authors' belief that differences between this and 3555 should
be handled by an update to 3555.  During the discussion leading up to this version,
I understood the aim to be to have this document relate more tightly to 3555.  While not quite
delegating that portion of the registration to 3555, it would make normative reference
to 3555 and see it as detailed description of the application of this to RTP.  If that is still
the aim, I believe we need to hold this document while we get at least an early draft of
355bis on the table.  An early normative reference would be required, for example.

If that is not the aim, I believe that we need to consider carefully the risk that this will cause
the namespaces to become disjoint.  Given the work that went into their unification, that is
not something we should do lightly.

Last call comments from Colin Perkins :

I have reviewed draft-freed-media-type-reg-03.txt, and have a number of
comments intended to align the registration procedures with the current
practice defined RFC 3555. These primarily arise due to the widespread
use
of media subtype names to identify formats that can be conveyed within
RTP.

The rules for display of text media types assume that such types are, to
some extent, readable without special purpose viewing software. This is
certainly true for most types, but some existing types have restrictions
on their use which are incompatible with this rule (e.g. the "text/t140"
type specified in RFC 2793 is a framed encoding defined only for
transfer
via RTP and cannot be directly displayed). The following edit to Section
4.2.1 ("Text Media Types"), third paragraph, is one way to resolve this
inconsistency, by noting that subtypes which are defined with restricted
usage cannot necessarily be directly displayed:

OLD:

    Beyond plain text, there are many formats for representing what might
    be known as "rich text".  An interesting characteristic of many such
    representations is that they are to some extent readable even without
    the software that interprets them.  It is useful, then, to
    distinguish them, at the highest level, from such unreadable data as
    images, audio, or text represented in an unreadable form.  In the
    absence of appropriate interpretation software, it is reasonable to
    show subtypes of "text" to the user, while it is not reasonable to do
    so with most non textual data.  Such formatted textual data should be
    represented using subtypes of "text".

NEW:

    Beyond plain text, there are many formats for representing what might
    be known as "rich text".  An interesting characteristic of many such
    representations is that they are to some extent readable even without
    the software that interprets them.  It is useful, then, to
    distinguish them, at the highest level, from such unreadable data as
    images, audio, or text represented in an unreadable form.  In the
    absence of appropriate interpretation software, and provided the
subtype
                                                   
^^^^^^^^^^^^^^^^^^^^^^^^
    is not defined for restricted usage, it is reasonable to show
subtypes
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    of "text" to the user, while it is not reasonable to do so with most
non
    textual data.  Such formatted textual data should be represented
using
    subtypes of "text".


The addition of the "framed" encoding defined in section 4.8 is valuable
now that media types are being widely used outside the traditional email
environment. Since there are many media types defined to use RTP
framing,
and since RFC 3555 imposes additional registration requirements on these
formats, it would be useful to reference it from within this draft. The
following change to section 4.8 is one possible such edit:

OLD:

    framed The content consists of a series of frames or packets without
      internal framing or alignment indicators.  Additional out of band
      information is needed to interpret the data properly, including
      but not necessarily limited to knowledge of the boundaries between
      successive frames.  Note that media types of this sort cannot
      simply be stored in a file or transported as a simple stream of
      octets, and therefore such media types are unsuitable for use in
      many traditional protocols.

    Additional restrictions on 7bit and 8bit are given in [RFC2046].

NEW:

    framed The content consists of a series of frames or packets without
      internal framing or alignment indicators.  Additional out of band
      information is needed to interpret the data properly, including
      but not necessarily limited to knowledge of the boundaries between
      successive frames and knowledge of the transport mechanism.  Note
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      that media types of this sort cannot simply be stored in a file or
      transported as a simple stream of octets, and therefore such media
      types are unsuitable for use in many traditional protocols.

    Additional restrictions on 7bit and 8bit are given in [RFC2046].
    A commonly used transport with framed encoding is the Real-time
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Transport Protocol, RTP.  Additional rules for framed encodings
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    defined for transport using RTP are given in [RFC3555].
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This change also adds wording to indicate that knowledge of the
transport
mechanism is required to understand a framed format, since each
transport
may convey frames in a different way, and will hence require different
out
of band information to interpret the data (e.g. RFC 3952 defines a
subtype
"audio/iLBC" comprising a sequence of iLBC audio frames, along with out
of
band information necessary to interpret those frames when conveyed in
both
file- and RTP-based transport).

As a consequence of the above changes, a normative reference to RFC 3555
is introduced. This will require the addition of:

    [RFC3555]  Casner, S., and P. Hoschka, "MIME Type Registration of RTP
              Payload Formats", RFC 3555, July 2003.

in section 14.1.

One might expect many framed encodings to be defined for restricted use
only, or to require parameters which are specific to the combination of
transport and media type. It might be worthwhile adding text to clarify
that this is expected, although it's not clear to me what would be the
best place to add it.

Last call comments from Bruce Lilly :

Comments, in same order as the draft (though some as noted apply in
general or to multiple sections of the draft):

Section 13 heading in table of contents and in the actual section
contains a spelling error: "Acknowledgements" should be
"Acknowledgments".

Historical Note, 2nd paragraph, 2nd line needs a period and additional
space character at the end of the first sentence (i.e. between
"environments" and " This").

Formatting seems a bit peculiar (e.g. huge empty space on page 5).

There does not appear to be any mention of case-insensitivity of
media type and subtype names (e.g. sect. 3 w.r.t. tree and facet
names, sect. 4 w.r.t. additional name components). [see also RFC
1958 section 4.3]

Section 4.2.1 might benefit from a clarification of "text" as
communication in a natural language intended primarily for human
consumption (perhaps something like the description in BCP 18).

Section 4.2.6 contains a spelling error: "labelled" should be
"labeled".

Syntax of parameter attribute names is significantly changed from
that of RFC 2045 as amended by RFC 2231 and errata.  Those RFCs
prohibited '%' and tspecials, while the draft specifies "reg-name"
as defined in the draft, which explicitly includes '%'. [draft
sections 4.2, 4.3]

Section 4.8 introduces "framed" content type, but that change is
not noted in Appendix B.

As "Mac OS" is a somewhat obscure platform, and as the registration
template provides for "Mac OS" "Type codes", a normative reference
providing information on those codes would be appropriate in
section 4.11.

Section 4.11 refers to RFC 2396, which (according to the rfc-index)
has been obsoleted by RFC 3986.

Section 5.4 references RFC 2026 regarding decisions made by the
media types reviewer, but RFC 2026 does not contain any text
specifically regarding media types review.  RFC 2026 section 6.5
discusses conflict resolution and has three parts, none of which
seem apropos to media type review (6.5.1 Working Group disputes,
6.5.2 [IESG] Process Failures, and 6.5.3 Questions of Applicable
Procedure) [publication of the draft as-is as a BCP might raise
a question of applicable procedure].  At minimum, some clarification
(regarding which section(s) of RFC 2026 is meant to apply) seems
necessary.

The section 6 procedure (modified from RFC 2048 section 2.4) doesn't
seem to be effective in practice.  While the additional step of review
by the media types reviewer might be an improvement, specific
statements regarding necessary IANA actions should probably be included
in the IANA Considerations section (the present IANA Considerations
section seems somewhat sparse).

Section 8 is somewhat unclear regarding standards tree registration
requirements. It states "Registrations in the standards tree MUST
satisfy the additional requirement that they originate from the
IETF itself or from another standards body recognized as such by the
IETF".  Ignoring the part about "another standards body", there is
some ambiguity regarding standards tree registrations using IETF
procedures (i.e. published RFCs).  The ambiguity arises from the
phrase "originate from the IETF itself", coupled with the fact that
"the IETF" is not a well-defined set.  It is unclear whether or not
an individual submission RFC (as distinct from an RFC which is the
product of an IETF working group) qualifies for registration of a
media type or subtype in the standards tree.

Section 9 raises some issues which should probably be incorporated
into the IANA Considerations section so that IANA's roles are
consolidated in one place as mentioned above.

Several of the references are amended by other RFCS (e.g. RFC 2231
amends normative reference RFC 2045) or by errata maintained by the
RFC Editor.  Additional references to those amending RFCs and
errata should probably be included.

A list of the specific media types which are affected by ownership
and change control principles in the draft should probably be included
in Appendix A.