[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Draft for new media types (MIME) registration rules
Ned,
1. I am glad that you accept proposal <GH2> that might be important to make designers to
be sure of what media type to propose.
2. I accept your view on <GH1> if you have found that it gives guidance to understand what
is text and what is not. I still think the view that text can be seen without interpreting
software is confusing. What if you have a block of Unicode text in Japanese Katakana, and
you look at it without tools. What can that mean - an 8-bit US ASCII converter? The user
will not be able to read anything from that. I still think that there must always be some
basic resemblance between the tool for reading and the media coding.
You may have a filtering tool that does not understand all framing and formatting
characters but displays the text in between. Still, I think software that have some basic
understanding of the underlying text format is needed to make sense of any text.
This is not important for me or any media question that I have, so I am happy if you want
to leave it as it is.
Regards
Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom at Omnitor.se
--------------------------------------------
>-----Original Message-----
>From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]On Behalf Of
>ned.freed at mrochek.com
>Sent: Friday, September 10, 2004 12:05 AM
>To: Gunnar Hellstrom
>Cc: Magnus Westerlund; Ned Freed; IETF AVT WG
>Subject: RE: [AVT] Draft for new media types (MIME) registration rules
>
>
>> A few comments on draft-freed-media-type-reg-01.txt:
>
>> <GH1> 4.2.1 Last paragraph:
>> This paragraph is a bit strange to me:
>> "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". "
>
>> What does it want to say?
>
>This text was very carefully worked out a very long time ago. It has
>successfully guided any number of implementations. Unlike most of the material
>in this document, I am EXTREMELY reluctant to change it at this late date.
>
>> Is it that there are kinds of text coding expressed in images or on video that
>are better
>> declared as image or video media?
>
>No, of course not. There are, however, numerous textual types that a normal
>person cannot make sense of at all without specialized software to interpret
>the material.
>
>> E.g. postscript coded text would rather be an image medium?
>
>I have no idea what this means or why it is in any way relevant.
>
>> The thought that text is readable even without the software that interprets it
>is strange
>> and does not produce any distinguishing definition.
>
>On the contrary, it has done exactly that.
>
>> I think encrypted text should still be
>> declared as text, but it is impossible to read without interpreting software. So the
>> comments rather create confusion than clarification.
>
>This is a red herring. An encryption layer is just that - a separate layer
>requiring a separate type declaration. And it is long established practice that
>container types belong under application. If necessary an encryption layer can
>provide a means of identifying the type or types of the protected content.
>
>> I think that the definition that 4.2.1 starts with is sufficient to define
>what text is.
>> The last paragraph could be limited to:
>
>> "Beyond plain text, there are many formats for representing what might be
>known as "rich
>> text". Coding is often intermixed control information and text contents. Such formatted
>> textual data should be represented using subtypes of "text". "
>
>I disagree in the strongest terms possible. This is exactly the text which
>various implementations ignored in the early days of MIME, in the
>process causing numerous interoperability problems. Removing it now would
>be reckless and irresponsible.
>
>> <GH2> 4.2.4 last paragraph:
>> "Note that although in general this document strongly discourages the
>> mixing of multiple media in a single body, it is recognized that many
>> so-called video formats include a representation for synchronized
>> audio, and this is explicitly permitted for subtypes of "video"."
>
>> It is also common that text for subtitling is multiplexed into the file or stream. I
>> suggest that the word "text" is added so that the paragraph reads:
>
>> "Note that although in general this document strongly discourages the
>> mixing of multiple media in a single body, it is recognized that many
>> so-called video formats include a representation for synchronized
>> audio and text, and this is explicitly permitted for subtypes of "video"."
>
>This is a reasonable change. I'll add it.
>
> Ned
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt at ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt