Comment: One very widely deployed <though for a single purpose in DTV> standard for rich text display that has not been mentioned is CEA 708 C. The media types standard seems to be able to support different encodings of rich text and this is a good thing. I also urge that rich text formats have identification codes at the highest possible level. Art ::{)> Arthur W. Allison Director, Science & Technology National Association of Broadcasters 202 429 5418 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Tuesday, September 07, 2004 10:40 AM To: Ned Freed; John C Klensin; 'ietf-types@iana.org' Cc: IETF AVT WG Subject: [AVT] Comments on draft-freed-media-types-reg-01.txt 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@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt