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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 07 Sep 2004 16:39:59 +0200

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: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Tue, 07 Sep 2004 08:33:34 -0700 (PDT)

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

> further registration document in relation do a specific domain of usage?

I would say it belongs in the registration document.

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

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

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

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

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

> split them into separate cases to clarify this?

I have no problem with splitting the field.

				Ned

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 08 Sep 2004 15:06:07 +0200

Hi Ned,

See below.

> I think this is pretty clear already.

I think one could use a stronger language in discouraging people.

  [snip]

> think it is appropriate to have domain-specific parameters, only

Okay, so registering the RTP payload format and a dedicated file format 
for the same codec needs to use two different media types, due to that 
that they partially needs to have different parameters?

I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt where we have 
RTP payload format that carries the different audio frames. There is 
also a specification of a file format, that also contains the same 
frames. The wrapping structure is somewhat different due to that they 
are file format and RTP payload format. In my view both format has 
advantages of using the parameters:

mode-set
channels
dtx
rate

While the RTP payload format also needs in addition the following:
ptime
maxptime
octet-align
interleaving

These parameter has all to do with how you configure the RTP payload 
format and how much media you aggregate together.

The basic common structure, and the need for the same media coder makes 
it reasonable from my perspective to use the same media type name for 
both usage. The context one receives the media type will make it clear 
what exact format that will be used.

Comments

>> MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF)
[snip]
> limits on the allowed syntax for parameter values. I will add words to

Okay

> name registrary. And AFAIK past experience with such registrations has been

I understand. I might have not meant application really correctly. What 
I mean is that if we update the RTP registration rules for media types, 
we can define a string that should be written into Restriction on usage 
if only RTP is supported. That way we are not really being explicit 
about application, but can ensure that we have a good definition on what 
restriction we applies.

The fact is that RTP is not an application, it is a framework that 
different application can use.

> in the restrictions on usage will help.

What could happen is that we have a media type that is for a codec and 
with two defined usages, file format and RTP payload format. The RTP 
payload format is after standardization used, but later found unsuitable 
for usage. Therefore a new RTP payload format is defined. However as 
there is a deployed basis one can't simple use the same media type for 
the new RTP payload format and defines a new one. The previous name is 
still valid for the file format part, while OBSOLETE for the RTP payload 
part.

The above is the reason I think one might need to consider to provide 
"intended usage" for different usages.

Cheers

Magnus Westerlund

---

From: [email-masked]
Date: Wed, 08 Sep 2004 06:59:54 -0700 (PDT)

> I think one could use a stronger language in discouraging people.

Then by all means suggest some.

> that they partially needs to have different parameters?

They most certainly do.

> are file format and RTP payload format.

In other words, the bits are different as well. That means two media types are
required regardless of whether or not the parameters are the same.

While it is nice to be able to cater to some extent to protocol-specific needs
in our procedures, we cannot afford to compromise the core functionality media
types provide. One of those core functions is that each type labels a single,
canonical object format. Types don't label codecs, and it has long been the
case that a single codec can give rise to multiple media types. (It is also
possible for multiple codecs to be combined in a single type.)

> about application, but can ensure that we have a good definition on what

That may be the right thing to do for RTP, but we need to think more
generally here. Of course nothing prevents RTP from specifying its
own additional registrations requirements for media types it uses.
The MIME specification is certainly going to do something along these
lines once it is revised.

> still valid for the file format part, while OBSOLETE for the RTP payload

In other words, having a media type that labels more than one sort of 
object can give rise to situations where the intended usage varies
depending on where the type is employed. This is hardly surprising given
that the initial premise violates the entire media type philosophy.

This is still more reason why having a single label for two very differnet
things is TOTALLY unacceptable.

				Ned

---

From: "Jose Rey" <[email-masked]>
Date: Thu, 9 Sep 2004 11:54:06 +0200

Hi,

I am the editor of the 3GPP timed text draft.  I have a question regarding
MW2.  THanks in advance
--snip--
> I would say it belongs in the registration document.

does such a clarification belong under "Encoding considerations" or under
"Restrictions on usage"?  Until now most payload formats included a sentece
like "This type is only defined for transfer via RTP." under encoding
considerations.  In this case, is it not more appropriate to do this under
"Restrictions on usage"?

This is how it would look like in our case:

"Encoding considerations:

RTP payloads conforming to this payload format do not comply with the strict
rules for registration under the 'text' top-level MIME type, as outlined in
RFC 2026 and its revision RFCYYYY [].  The reason for this is that the RTP
client must, at least, understand the payload format fields (in binary) in
order to decode the timed text contents (partly text strings, partly
binary).  This binary information is not considered 'directly readable'
without 'special software' as required for 'text' subtypes (in contrast to
text strings).  Around the 60th IETF it was decided to relax these rules for
RTP payload formats.  In particular, it was allowed to register RTP payload
formats under the 'text' top-level type (if appropriate) as long as the
domain of applicability of the format is clearly specified (e.g. only for
transmission using RTP).  This payload format complies with these 'relaxed'
rules.

Restrictions on usage:

This type is only defined for transfer via RTP."

Cheers,

Jose

--snip--

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Sep 2004 23:35:10 -0400

Hi.

For whatever the additional calibration is worth, my reactions
are in complete agreement with Ned's on all issues.  In
particular, the notion of registration by application, rather
than file (body part) content has been absolutely miserable and
a plague on interoperability.  Part of the reason is that, in
many situations, we can have application X that can handle file
formats A, B, and C, and application Y that can handle file
formats D, E, and B.  If the content types reflect the formats,
there is no problem -- both simply use B.  If they reflect the
applications, then there is an serious interoperability problem.

   john

--On Wednesday, 08 September, 2004 06:59 -0700
[email-masked] wrote:

>> >   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.
>> > 
>> >> 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.
> 
>> Okay, so registering the RTP payload format and a dedicated
>> file format for the same codec needs to use two different
>> media types, due to that that they partially needs to have
>> different parameters?
> 
> They most certainly do.
> 
>> I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt
>> where we have RTP payload format that carries the different
>> audio frames. There is also a specification of a file format,
>> that also contains the same frames. The wrapping structure is
>> somewhat different due to that they are file format and RTP
>> payload format.
> 
>> I understand. I might have not meant application really
>> correctly. What I mean is that if we update the RTP
>> registration rules for media types, we can define a string
>> that should be written into Restriction on usage if only RTP
>> is supported. That way we are not really being explicit about
>> application, but can ensure that we have a good definition on
>> what restriction we applies.
> 
>> >> 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
>> > 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.
>> > 
> 
>> What could happen is that we have a media type that is for a
>> codec and with two defined usages, file format and RTP
>> payload format. The RTP payload format is after
>> standardization used, but later found unsuitable for usage.
>> Therefore a new RTP payload format is defined. However as
>> there is a deployed basis one can't simple use the same media
>> type for the new RTP payload format and defines a new one.
>> The previous name is still valid for the file format part,
>> while OBSOLETE for the RTP payload part.
> 
> In other words, having a media type that labels more than one
> sort of object can give rise to situations where the intended
> usage varies

---

From: [email-masked]
Date: Thu, 09 Sep 2004 08:37:52 -0700 (PDT)

> considerations.  In this case, is it not more appropriate to do this under

Encoding considerations is really intended to be a single value chosen
from a list. As such, this really belongs under restrictions on usage.

> RFC 2026 and its revision RFCYYYY [].

Wrong RFC # here,, I believe. Additionally, I don't see this as a case of
noncompliance with the revised rules. A better approach would be to say that
this type is incompatible with use of text media types in other protocols.

> The reason for this is that the RTP

I don't think having this sort of historical note in a registration is
appropriate either. 

				Ned

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Sep 2004 11:35:29 +0100

>> that they partially needs to have different parameters?

I'm a little concerned about the strength of this rule. I agree when 
the parameter space is separate, but I can certainly envisage cases 
when the parameter space and data format for two different domains have 
a very high degree of overlap, and where it makes sense for them to use 
the same media type.

For example, there are several audio codecs where the RTP payload 
format can be summarised as "put frames into RTP packets in order" and 
the file format is "put frames into the file in order, following an 
initial magic number". In both cases there are common parameters: 
sampling rate, frame duration, and number of channels. However the RTP 
payload format needs an additional parameter: maximum frame duration 
(RTP packets have a size limit due to the path MTU, but the file format 
supports any frame size). I'm not sure it makes sense to require these 
to use different media types, since they're clearly the same format 
applied to different domains, yet the above rule would seem to require 
it.

Colin

---

From: [email-masked]
Date: Sat, 11 Sep 2004 10:21:18 -0700 (PDT)

> a very high degree of overlap, and where it makes sense for them to use

Data formats are either the same or they aren't. If they are the same only one
media type is required. If they aren't then different types are required
regardless of the disjointness of domains of applicability, the use of the same
underlying set of codecs, and so on.

Leakage between domains is just too common to relax this rule.

OTOH, parameters can be optional. I don't much care for it, but I suppose
there's nothing to prevent you from having a parameter that's optional in some
contexts and mandatory in others. (This could simply be spelled out in the
parameter specification language.) However, I would not want to  see language
prohibiting a particular parameter in some context; IMO this goes too far.
Having a single parameter with different domain-specific meanings is also
unacceptable.

> applied to different domains, yet the above rule would seem to require

And interop problems are likely if files are produced without the magic number
and software that checks the magic numbers is used. Similarly, treating the
magic number as audio data could, depending on the codec involved have some
interesting effects.

Now, nothing says you cannot use a naming convention of some sort to link the
two types in some way. But IMO they really need to be two different types.

				Ned

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Sep 2004 10:07:41 +0200

Ned,

On 11 Sep 2004, at 19:21, [email-masked] wrote:
>> domain
>> >> of
>> >> >> quite many parameters for RTP usage, but none for the file 
>> format.
>> >> How
>> >> > IMO if the parameter space is different the types are different. 
>> I
>> >> don't

Data formats can be the same, although they have different framing. 
There are several existing examples where we have the same data, using 
the same MIME type, but with different framing for RTP and for the file 
format. I would argue that this is entirely legitimate, and indeed 
required if we're to allow registrations for different domains of 
applicability.

> Having a single parameter with different domain-specific meanings is 

Sure.

> magic number as audio data could, depending on the codec involved have 

Of course, but so what? One clearly needs software that understands the 
format, and if you produce files without the magic number they're not 
conforming.

> two types in some way. But IMO they really need to be two different 

In which case we have two different and separate namespaces, trying to 
share the same registry. This, IMHO, doesn't make sense.

Colin

---

From: [email-masked]
Date: Fri, 24 Sep 2004 08:29:41 -0700 (PDT)

> format, and if you produce files without the magic number they're not

Sure they are. Your entire entire goal here is to use the same label
for two different formats, one with the magic number and one without.
This admits the possibility of two conformant pieces of software
failing to interoperate, and that's not good.

> share the same registry. This, IMHO, doesn't make sense.

No, what we have is a single registry for specific formats and a way to
link formats that are in some way related.

				Ned

---

From: Colin Perkins <[email-masked]>
Date: Sat, 25 Sep 2004 18:52:16 +0100

On 24 Sep 2004, at 16:29, [email-masked] wrote:
>> > magic number as audio data could, depending on the codec involved 
>> have
>> > some
>> > interesting effects.
>

No, not within the same domain. I'm intending that the format that's 
limited to use when transported in an unreliable sequence of RTP 
datagrams has a different header than the format for use when 
transported by a reliable byte stream, but that's a different domain of 
applicability. It's certainly should not be legal to use the headers 
for the byte stream format in RTP, or vice-versa.

> link formats that are in some way related.

But that link is the media type name, with the domain of applicability 
to prevent interoperability problems. This is done in RFCs 3267 and 
3558, for example, and doesn't appear to have caused problems.

Colin

---

From: [email-masked]
Date: Sat, 25 Sep 2004 22:13:15 -0700 (PDT)

> for the byte stream format in RTP, or vice-versa.

You're assuming that material can be constrained to a single domain. We have
ample experience that (a) such assumptions are routinely voilated and (2) we
have absolutely no competence at predicting when violations will occur.

> 3558, for example, and doesn't appear to have caused problems.

Two examples where problems haven't yet arisen in a specific domain doesn't
mean much. There are hundreds of media types and who knows how many domains of
applicability, and the rules have to work for all of them.

				Ned