[AVT] Comments on draft-freed-media-types-reg-01.txt
Allison, Art
AAllison at nab.org
Tue Sep 7 16:54:59 CEST 2004
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 at ericsson.com]
Sent: Tuesday, September 07, 2004 10:40 AM
To: Ned Freed; John C Klensin; 'ietf-types at 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 at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt
More information about the Ietf-types
mailing list