Comments on draft-freed-media-types-reg-01.txt

[ned.freed at mrochek.com]

> Hi Ned and John,

> I have now reviewed your document and have some comments and questions.

> MW1: Section 3.4: Based on all arguments I have heard about any
> experimental tree, they should be strongly discouraged to be used at
> all. The motivation, is that if one defines a experimental type in a
> test application. The application becomes a success, suddenly you have
> an deployed base of something you didn't intended to. Then trying to
> change the type leads to interoperability issues, and may in best case
> result in usage of two different names for the same type. I think it
> might be better to recommend that one simply uses a real type, and tries
> to register it as soon as possible.

But this is what the section already says:

   However, with the simplified registration procedures described above
   for vendor and personal trees, it should rarely, if ever, be
   necessary to use unregistered experimental types, and as such use of
   both "x-" and "x." forms is discouraged.

I think this is pretty clear already.

> MW2: Section 4.2.1, third paragraph:

>    "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"."

> When one has limited usage, like say "only for usage in RTP" I think
> there are need to consider some wider interpretation of what "to some
> extent readable" means. We had an example in the 3GPP timed text
> discussion, where the RTP payload format consists of embedded UTF-8 or
> UTF-16 strings in an otherwise binary format. However for RTP that is
> the common case. Should such any clarification on the performance of
> such consideration be written into this spec or do it belong to a
> further registration document in relation do a specific domain of usage?

I would say it belongs in the registration document.

> ME3: Section 4.3: Parameters only applicable to a specific domain of
> usage? Certain types will be (are) registered for several domain of
> usage, however the different domain may require that different
> parameters are used. I can give you an example in RFC 3267 that has
> quite many parameters for RTP usage, but none for the file format. How
> is it supposed to be indicated that this is the case?

IMO if the parameter space is different the types are different. I don't
think it is appropriate to have domain-specific parameters, only
type-specific ones.

> MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF)
> definition of the parameter values need to be properly defined.

That's impossible because there really isn't one. Parameter encoding is allowed
in MIME, with the result that parameters can be (a) Tagged with a particular
charset, and (b) If need be can be pure binary.

> Otherwise it is hard to make any assumption about what is potential to
> be used in protocols. I think it also needs to take the current used
> protocols like, mail, HTTP, SDP into account.

Mail at least allows binary parameter values.

The best I can do here is to say that specific transport may impose
limits on the allowed syntax for parameter values. I will add words to
that effect.

> MW5: Section 4.9: I think the draft hints in section 4.2 that with
> certain limited usage, another document may further define how the media
> types should be treated, and what to think of. However I think it might
> be worth being a bit more clear on what such a document should do. In
> addition to defining any further restrictions on registration, I think
> it should define a "name" for this application to be used in the
> "Restriction on Usage" heading in the template.

I'm really not sure we want to go here. Asking for people to specify an
application names gets us onto a slippery slope towards having an application
name registrary. And AFAIK past experience with such registrations has been
poor.

> MW6: I think further clarification on the coupling between the "intended
> usage" and the "Restriction on usage" is needed. For example, is one
> allowed to use "Common" when the restriction of usage says: Only for use
> in RTP? And is the classification of what is common, limited usage, or
> obsolete depending on the domain?

I guess I don't see the problem. The commonality of use of something
has almost nothing to do with how usage is restricted. I could have
a media type that's commonly used but only RTP. Or I could have
an obsolete type that can be used anywhere. Any combination is possible.

Perhaps moving the restrictions on usage field below the intended usage
field in the registration form and adding some text as to what goes
in the restrictions on usage will help.

> MW7: Section 10:

> Actually I find the labeling of "Author/Change controller:" a bit
> confusing. In my view there can be a big difference between Author and
> Change controller. For example in my proposed registration of
> audio/rtp.enc.aescm128 where I am the author and the direct recipient of
>   any comments at the initial stage. However the change control over
> this type belongs to 3GPP.  And although the contact person exist, that
> might be even a third entity in some cases. Might it not be wise to
> split them into separate cases to clarify this?

I have no problem with splitting the field.

				Ned