[AVT] Comments on draft-freed-media-types-reg-01.txt

[Magnus Westerlund <magnus.westerlund at ericsson.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.

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?

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?

MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF) 
definition of the parameter values need to be properly defined. 
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.

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.

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?

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?


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt