Subject: Re: Ietf Digest, Vol 15, Issue 17

From: Bruce Lilly <[email-masked]>
Date: Tue, 5 Jul 2005 20:09:12 -0400

>  Date: 2005-07-05 11:18
>  From: Magnus Westerlund <[email-masked]>

Magnus,

Comments in-line:

> [...] registered a large amount of names (>70) makes it very hard to see 
> that moving into separated registries will resolve any confusion. In 
> addition it will require a huge work effort to move to the new registry.

I have suggested grandfathering existing RTP-related registrations in
a separate RTP registry.  That would prevent further confusion and
would give the RTP registry a separate sandbox with clean sand and new
toys.  Some small amount of copying work would be required, and of course
registration procedures for both registries would require some minor
tweaking.
  
> To me the best way forward is that we clean up the registration 
> procedures of the current media types registry.

Because of widely-deployed mission-critical MIME applications, any such
"clean up" cannot change the fundamental rules for text media types, as
detailed earlier.  We're not talking about mere entertainment applications,
we're talking about email and things like Internet fax, voice messaging,
and EDI.

> The issue I see is that with two separate registries one will not 
> seriously consider the names in the other registry.

Why should a MIME implementer need to "consider" RTP names or vice versa;
e.g. text/plain or text/html vs. RTP?
 
> What I intended to stress was that 
>   having cross review between registries is a hard way of avoiding 
> having two different formats register the same name but in different 
> registries. As the name structure looks the same, it is very hard to 
> determine to which registry such a name would belong. Thus one needs to 
> look up both if checking.

Why?  An particular implementation is either handling RTP streams or MIME
data, and would only need to be concerned with the appropriate registry.

> > If there is a single registry:
> > o each MIME and each RTP implementer will have to examine each entry
> >   and determine:
> >   * is this media type applicable to my work?
> >     - yes
> >     - no
> >     - unclear
> >   This is clearly more work for implementers if there is a combined
> >   registry.  To the extent that implementers ask questions ("what's
> >   this 'framed' stuff?"), it may be more work for registered contacts
> >   also.
> 
>  From my perspective a implementor normally know what it needs to 
> support on a fundamental level. I need to support the AMR codec.

MIME types are explicitly not supposed to be encoding schemes; there is a
separate MIME mechanism for encodings.  If RTP permits mixing encodings
with true media types, that's another reason to have a separate RTP
registry; it doesn't fit the MIME model.

> From  
> that perspective looking up audio/amr in either of the registries will 
> be simple.

Let's discuss lookups.  In MIME, a receiver has a clear indication of
a media type (Content-Type field), encoding (Content-Transfer-Encoding),
identifier (Content-ID), checksums (Content-MD5), language
(Content-Language), etc.  Where does an RTP receiver get the "audio/amr"
from; does RTP send a Content-Type field?

In the MIME case, the MIME type from the Content-Type field can be
looked up in the MIME registry.  If a particular RTP type can never be
sent via MIME, putting it in the MIME registry may have a performance
impact on MIME lookups, either directly (e.g. a table search) or
indirectly (e.g. paging/swapping due to large hash tables).

Likewise for the RTP case; if, as you say, there is no way for text/plain,
text/html, text/enriched, text/troff, text/rtf, text/sgml, text/csv, etc.
to be sent via RTP, surely their presence complicates RTP applications
finding types that *can* be used with RTP.

In any event, merely looking up something in a registry simply confirms
whether or not there is a registered type.  At least in the case of
MIME, it may be necessary for an implementer to determine what parameters
are required, which optional parameters are valid, what effect any
parameters might have on processing, etc.  As the registry is currently
organized, that means wading through each registration form in detail
and consulting the detailed specification.  Why should MIME
implementation programmers have to wade through RTP registration forms --
what purpose would that serve?

Unless I'm reading RFC 3267 incorrectly, there are in fact *two*
separate formats, one for RTP use (sect. 4) and one for MIME (sect. 5).
One of which will never be seen in MIME, and one of which will never
be seen in RTP.  So why force two sets of programmers to wade through
twice as many format specifications than either will need?

> In fact this is one of the media types that are both RTP and  
> file format. This would need to be doubly registered and thus needs 
> links to the other registry to have people avoid taking the wrong 
> version if they are lacking the necessary knowledge.

As IANA maintains registration information via a web site, two links
to the same registration form would be trivial.

> If the registry page would include columns that indicated usage of the 
> media type this can easily be resolved.

With separate registries, the need to redesign the pages would be
avoided, which is of course easier than such a redesign.
 
> > o the registration procedures, forms, review forum, etc. will have
> >   to accommodate items which are the union of items which are
> >   individually applicable to different uses
> >   * MIME registrants will continually ask "what is this 'framed'
> >     encoding stuff?"
> >   * RTP registrants will continually be told "your 'text' type
> >     is incompatible with the requirements for 'no software required',
> >     'fallback to text/plain', etc."
> 
> 
> These reasons you list are due to the unclarity regarding the procedure. 

No, "framed" has no meaning in a MIME context.  That isn't sue to a
procedure; it's due to something irrelevant to MIME being shoehorned
into the registration form.  The restrictions on the nature of media
registered under the text top-level MIME type aren't a mere procedural
formality; they are essential to the interoperable functioning of MIME.

>  > These have been observed issues with use of the MIME registry for RTP
> 
> What are you referring to.

The "what is framed" question and the comments about incompatibility
of proposals for registration under the MIME top-level text media type.

> > o if there is some media type that is usable by MIME and by RTP, it
> >   need only be registered once (unless of course there are differences
> >   in parameters, security issues, etc, in the registration form that
> >   would indicate separate registration)
> >   * the key question is, are there any such types?
> >     - clearly you have said that, unlike MIME media types, the RTP
> >       types cannot be stored in a file, etc.  So it's clear that
> >       the RTP types cannot be used by MIME
> >     - can the MIME types be used by RTP?  For example, can RTP make
> >       use of the MIME media type application/vnd.ms-excel?
> >   This would be a point in favor of a combined registry -- if and only
> >   if there is a reasonable number of media types usable by both MIME
> >   and RTP.
> 
> I think this is one of the points of contentions in the earlier 
> discussions we have had regarding this topic. This in the light of 
> registrations like audio/amr (RFC 3267) that are for both file format 
> and RTP.

3267 gives very different format specifications and different security
considerations; precisely my point.
 
> > o if there are two types with incompatible definitions which wish
> >   to use the same name, there will be a clash
> >   * the namespace is big enough so that names aren't scarce
> >   * however, there may be some user-land confusion, as sometimes
> >     users infer more from a name that just it being a tag for something
> >   This is a relatively minor point in favor of separate registries.
> > 
> 
> I agree that it is not a problem if we are capable of detecting and 
> keeping the review to actually look in both registries and ensure that 
> the other work is not trying to use the same name.

Separate registries, same name isn't a technical problem; it's more of
a potential user confusion issue -- but if that hasn't happened with
audio/amr is probably not worth worrying about.

> > If there are separate registries:
> > o RTP implementers can look through an RTP registry, without having to
> >   wade through MIME types and vice versa.  Likewise for any other
> >   registries that might be desirable
> >   * MIME implementers can safely ignore the RTP registry and vice versa
> >     - any implementer who needs to be concerned with both can of course
> >       look at both
> >   Point in favor of separate registries.
> 
> I can agree with that if one comes looking at names from that direction. 
> However I think the most common is that one either comes from the 
> defining RFC

The RFC should indicate (or it should be clear from context) whether it
addresses MIME or RTP or something else.

> or have the type name and want to look it up.

In the case of MIME, the type name comes from a MIME Content-Type field,
so the only appropriate place to look would be the MIME registry.  It's
unclear where an RTP receiver would get a media type name to look up, but
as it is an *RTP* receiver, the logical place to do so would be in an RTP
registry.

> In these   
> cases separate registries do not provide any benefit.

The benefit (primarily for RTP, but going forward preventing the MIME
registry from becoming more cluttered) is in not having to cut through
the brush of irrelevant registrations.

> However the will actually be an increase in questions as you will also 
> need to ask: Are this name registered in the other registry?

Why would anybody care -- where do MIME and RTP intersect?

> > o if there is some media type which is usable by both MIME and RTP,
> >   registration would have to be duplicated (modulo differences in forms
> >   and so on)
> >   * as above, are there any?
> >   * copy and paste...
> >   * maybe some incremental work for IESG and IANA -- *IF* there are any
> >     such types
> >   Point in favor of a combined registry, if and only if there is a
> >   reasonable number of such combined-use media types
> 
> There are 5 or so that are combined registered.

1. in the case of audio/amr and audio/amr-wb there are (each) two different
   formats registered under the same name.  If I understand the 3267 sections
   4 and 5, the separate formats never mix; the section 4 RTP format never
   appears in MIME and the section 5 format never appears in RTP (whether or
   not it has ever actually appeared in MIME is another matter).
2. There are currently a total of 615 registered media types (41 text, 71 audio
   36 image, 36 video, 12 model, 394 application, 13 multipart, 12 message).
   5 out of 615 is less than one percent, and doesn't seem to warrant a
   combined registry, especially as that small amount of overlap (if it
   really is overlap -- see the item above re. audio/amr and audio/amr-wb)
   can be handled by links or copies.

> > o no clashes in the case of incompatible definitions, even if similar or
> >   the same name is used, provided that MIME and RTP do not interact in
> >   such a way as might cause confusion about whether media is a MIME
> >   type or an RTP type
> >   * as I understand it, there is no opportunity for confusion; any
> >     relationship would require some sort of conversion, and a software
> >     or protocol entity accepts/generates either one type or the other
> >   * names in each realm can be convenient for users, though there may
> >     be some potential for user confusion about whether a type is a MIME
> >     type or an RTP type
> >   Point in favor of separate registries.
> 
> The confusion on this level do exist more in the head of implementors 
> and users. Looking at the name audio/amr can you determine what registry 
> it belongs in? And the answer is no, you need to have the application 
> context to determine that.

How under RTP would one *not* know the application context?  The root
of the audio/amr problem seems to be that two incompatible formats are
given the same name  (and to introduce an informal notation, MIME:audio/amr
and RTP:audio/amr would be distinct names, so separate registries would
help).

> There are a lot of pro and con and I don't see a lot of decisive 
> arguments. Therefore I would like to point out the issue of workload. I 
> think we should select the way forward that results in least work why 
> still improves the situation. To me that is to keep a single registry 
> and improve the registration process and information.

Re workload:
o for whom?
o short-term or long-term?

A single registry means more work for MIME implementers and reviewers,
both short-term and long-term, and doesn't improve the situation.  The
registration process has changed a little since RFC 1341, and isn't a
problem.  Getting necessary information from the registry involves
carefully reviewing the registration forms and full specifications, and
would be facilitated by separate registries so that irrelevant
specifications can be more easily ignored.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephen Casner <[email-masked]>
Date: Wed, 6 Jul 2005 01:06:20 -0700 (PDT)

> registration procedures for both registries would require some minor

That's not it.  Of course all the existing registrations would be
copied.  However, all of the many RTP-related RFCs that refer to MIME
registrations would become obsolete and need to be revised.  A fair
number of those RFCs are referenced by other SDO's documents.

As Colin mentioned, in December 1997, then-ADs Harald Alvestrand and
Keith Moore strongly encouraged the AVT working group to convert from
using its own name space for media payload formats to using the MIME
media type registry.  Some of the motivations for moving the RTP
namespace into the MIME namespace were:

  - To avoid different names for the same media format, such as MIME's
    audio/basic and RTP's PCMU.  More on this below.

  - To help populate the MIME audio and video spaces which were very
    sparse.

The AVT working group did a lot of work between then and now to
specify the mechanism for the registrations and to create
registrations with what I believe was careful attention to detail.
This process has imposed very little load on the "MIME folks"; in
fact, it has received little notice until the recent consideration of
two subtypes under the text major type.

In my opinion, we should set a fairly high bar for the decision to
change from the status quo and induce the overhead of obsoleting a
large number of RFCs.

> we're talking about email and things like Internet fax, voice messaging,

There is no proposal to change the way email, html, and fax use MIME
types.  Perhaps "clean up" is not the most appropriate term.  I would
say what's needed is to be more specific about the domains in which
media types are used, without changing at all how they have been or
will be used for email, etc.

> e.g. text/plain or text/html vs. RTP?

This question does not make any sense.  Someone wanting to know more
about text/plain would look up that media type.  However, it would be
good if someone who was thinking about sending snippets of audio
captured from a GSM phone considering the registration of audio/GSM
that is defined currently only for the transport via RTP.

> data, and would only need to be concerned with the appropriate registry.

It seems to me that the main concern in this discussion is "leakage".
Leakage occurs precisely then implementors and users don't reference
documentation.  If we have different names for the same media format
when carried in RTP and in email, this increases the likelihood that
the name from one domain will be used incorrectly in the other.  Sure,
one could register the same name in both registries at the same time
if both modes of use were being defined at once, but that is not
always the case.  I believe it is better to have an entry in one
unified registry that says for subtype foo that "this type is defined
only for transport in RTP" than to have separate registries with
nothing for the name foo in the MIME registry.  That is, negative
information is better than no information.  Not foolproof, but better.

> registry; it doesn't fit the MIME model.

I don't understand this point.  Are you saying that all audio should
be only one subtype, and that a compression scheme such as AMR should
be expressed as a content-transfer-encoding or the equivalent?  That
would be a pretty extreme view.

> from; does RTP send a Content-Type field?

RTP does not communicate the "audio/amr" selection at all.  RTP
carries a small integer Payload Type that is dynamically bound to a
payload format such as audio/amr by some signaling protocol.  There
are several different signaling protocols in use.  I don't think any
of the ones currently in use has a field labeled "Content-Type", but
it would be perfectly reasonable to have a signaling protocol that did
so.

Are the only applications of "text/plain" ones that put that string
after "Content-Type: " ?

> finding types that *can* be used with RTP.

I doubt that this is a significant problem on either the MIME or RTP
side.  In both cases, the application supports some set of types which
it keeps in its one little list.  The application does not go to IANA
to look up the name in a registry.

> what purpose would that serve?

The implementer of a system wanting to use a media type will look for
a registration of a type that corresponds to that medium.  One hopes
that the subtype name choices allow a more narrow search than linear.
An implementor wanting to specify a MIME media type for a new format
would do well to reference the registration for RTP transport of that
format (if it existed) because it is likely that at least some of the
parameters required to identify the type for RTP will also be needed
to identify the type for MIME usages.

> twice as many format specifications than either will need?

The frames of audio are the same in both cases, so defining both uses
together makes a lot of sense.  Further, many applications or
application suites will use both means of transport.

> avoided, which is of course easier than such a redesign.

These are trivialities that do not cross the high bar.

> formality; they are essential to the interoperable functioning of MIME.

Nothing about framing needs to be included in the main MIME documents
nor the registration form.  All that's needed is a recognition that
media types may be used differently in different domains, and to make
a provision for separate documents (like RFC 3555) to specify the
additional details that are required for the specific domain.

> of proposals for registration under the MIME top-level text media type.

There is a certain amount of angst in the current discussions, but I
believe it is the result of misperceptions.  I believe Colin's
messages expressed the issues well.  A number of strong theoretical
concerns have been described, but they don't map to reality.

> considerations; precisely my point.

The sequence of audio frames is just the same in both modes of use.

[skipping some in the interest of brevity -- there are various
tradeoffs between combined and separate registries, but not strong
reasons for changing from the status quo -- neither choice can prevent
stupidity]

> > and improve the registration process and information.

For the AVT working group in particular, which has operated in good
faith building in the MIME registry for years.

> both short-term and long-term, and doesn't improve the situation.

I don't think that is true.  As I said, specification of additional,
domain-specific details for registration procedures falls to those
working in the domain.  We have been registering RTP payload formats
for some time with little impact on MIME reviewers until the recent
discussion ensued.  And I can't see how the impact of an audio/amr
registration on MIME implementors interested only text/plain can be
any more than trivial.

> The registration process has changed a little since RFC 1341, and
> isn't a problem.  Getting necessary information from the registry
> involves carefully reviewing the registration forms and full
> specifications, and would be facilitated by separate registries so
> that irrelevant specifications can be more easily ignored.

I doubt that anyone reads through all the full specifications in the
registry to decide which type to use.  Finding a type is not hard.
Learning the details of how to implement that type correctly requires
looking at the full specification for that type, not not others.

                                                        -- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Jul 2005 11:18:00 +0200

Hi Bruce,

Please consider what Stephan Casner says. I totally agree with his 
response. I simply want to make a few comments.

I think you really should ask yourself how it comes that the current 
process has been used in 6-7 years and for more than 70 registrations 
without anyone raising any issues. I take this as an sign that the 
current process works and is viable. It can only benefit from a bit of 
clarification. For example in the area of text. Where all we desire is 
clarification on the possibility to register types that are restricted 
to RTP without the strict requirement on basic parsing.

I also question if the MIME world really can continue using that 
criteria themselves. Is this really working, it seems not in the 
application I am using. I don't want to see the html formating in my 
browser, even if it is readable.

> registration procedures for both registries would require some minor

We don't want a new sandbox, moving from the current is such work that 
it isn't worth it with the small gain and great risk for confusion it 
creates. What I suggest is that we clean up the current sandbox so that 
we can reduce the confusion on what is in it and what is allowed.

> we're talking about email and things like Internet fax, voice messaging,

I am not intending to breaking MIME based applications. I want to avoid 
breaking any of the applications, MIME or RTP. But you seem to be fine 
saying that breaking RTP does not count, it isn't mission critical, 
despite it being a hugely deployed protocol. Separating the registries 
will cause confusion, generate errors and inconsistencies in a number of 
standard documents IETF's and others.

> o for whom?

A separate registry would mean that AVT would need to perform the 
following work:

- Write a new registration RFC
- Update the 70+ registrations documented in 35+ RFC
- Inform a number of standard organizations or consortium like ITU, 
ETSI, 3GPP, 3GPP2, DLNA, etc about the new rules and have them update 
their specifications.

Are you volunteering to see these changes thou?

Regards

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]