Subject: [AVT] Error in draft-ietf-avt-rtp-mime-04.txt

From: Rajesh Kumar <[email-masked]>
Date: Tue, 17 Jul 2001 17:18:30 -0700

AVT chair,

My colleague at Cisco, Joseph Swaminathan, pointed out this  error in 
draft-ietf-avt-rtp-mime-04.txt which goes against the consensus of the AVT 
working group.

This consensus, as reflected in draft-ietf-avt-profile-new-10.txt is:

"This specification establishes the policy that no additional static 
payload types will be assigned beyond the ones defined in this document."

Further, Henning Schulzrinne wrote on Fri, 06 Jul 2001 in this group:

"Again, static payload types are history. See the FAQ."

But if you read draft-ietf-avt-rtp-mime-04, you find the assertion with 
relation to the MIME subtype RED:

" pt: a comma-separated list of static RTP payload types.  The  mapping to 
the a=fmtp attribute is to eliminate the parameter name and change the 
commas to slashes.  For example, "pt=0,5" maps to "a=fmtp:99 0/5".  This 
specification does not support dynamic payload types."

If you look at rfc2198, on which this MIME subtype is based, you do not 
find this restriction to static payload types.

Clearly, this restriction is behind the times and needs to be fixed.

Anyone disagree?
  Rajesh Kumar
--------------------------------------------------------
Cisco Voice Technology Center
------------------------------------------------ --------

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

---

From: Stephen Casner <[email-masked]>
Date: Tue, 17 Jul 2001 19:09:25 -0700 (PDT)

Rajesh,

> Clearly, this restriction is behind the times and needs to be fixed.

You are right, this limitation is unfortunate and inappropriate.  It
has probably been that way for a while.  The reason it exists is that
the pt parameter would need to contain a list of complete MIME type
specifications (type, subtype and parameters) in order to define each
of the dynamic payload types.  I don't know if any syntax has been
defined for embedding one MIME type specification into the parameter
of another.  It would be necessary to quote comma and all parameter
delimiters using some quoting scheme that does not conflict with the
syntax of a MIME type specification.  We can probably create
something, but I bet it will be ugly.

The registration for audio/RED includes an implicit "Encoding
considerations" limiting the type for transport over RTP only.  To
allow for use with stored files, say where the RTP packets are
captured into a file, it would be necessary to specify pt in terms of
the dynamic payload type numbers that were used in the captured packet
stream, and then specify some new parameter for audio/RED that binds
those dynamic payload type numbers to full MIME type specifications.
We could decide not to do this.

Any ideas?
							-- Steve

---

From: Rajesh Kumar <[email-masked]>
Date: Wed, 18 Jul 2001 12:02:27 -0700

Steve,
I think you can define an elegant mechanism to reference MIMEs from other 
MIMEs. Taking a cue from SDP, I suggest that you  support dynamic payload 
types within the 'pt' parameter, and define another parameter (call it 'da' 
or dynamic assignment) to  associate the dynamic payload type with another 
MIME.

I think one can define a pretty rigorous syntax for this referencing of 
MIMEs from other MIMEs. This is analogous to SDP where you can place rtpmap 
attributes  in tandem (you do not need to embed rtpmaps within rtpmaps).

So, in SDP you can have:
         m=audio 11111 RTP/AVP   0 101
         a=rtpmap:100 red/8000/1
         a=fmtp:100 0/101
         a=rtpmap:101 G729E/8000/1

and there is no unnatural restriction, nor is there any ugliness. If you 
want to use a similar concept for MIME definitions, you can generalize the 
definition of the 'pt' parameter to support static and *dynamic payload 
types*. You also define another parameter, da (dynamic assignment), which 
assigns the dynamic payload type to another MIME definition. To avoid 
ugliness, you can enclose the referenced MIME within square brackets, after 
the dynamic payload type. Thus, the SDP lines above translate into the 
following MIME definition:

         audio/red; pt="0,101"; da  =101 [audio/G729E;rate=8000;channels=1]

If you had another SDP segment with multiple dynamic payload types, for 
instance:

         m=audio 11111 RTP/AVP   101 102
         a=rtpmap:100 red/8000/1
         a=fmtp:100  101/102
         a=rtpmap:101 G729E/8000/1
         a=rtpmap:102 G726-40/8000/1

you can map it into the following MIME definition:

         audio/red; pt="101,102"; da  =101 
[audio/G729E;rate=8000;channels=1], 102 [audio/G726-40;rate=8000;channels=1]

I can write up the detailed syntax definition if you agree with the concept 
(e.g. 'da' is a comma separate list of ....). Alternately, you or the team 
can come up with equivalent, elegant grammars - you do not need to embed 
stuff within the 'pt' parameter.

draft-ietf-avt-rtp-mime-04.txt  is still a draft, and you agree, it has 
this  "unfortunate and inappropriate"   flaw, which is, in my view, a fatal 
flaw. One way or the other, we need to fix this flaw and solve this 
problem. I have shown one way of doing it which, to my boorish 
sensibilities, does not look particularly hideous. I am sure others can 
construct better syntaxes .

MIME definitions are no more than "models' of reality.     I think this 
problem needs to be solved, unless one wants to divorce the "model" from 
"reality", in which case, "reality" will ignore the "model" and work around it.

Let me know what you think!

Rajesh Kumar

  Rajesh Kumar

---

From: Stephen Casner <[email-masked]>
Date: Thu, 19 Jul 2001 18:51:35 -0700 (PDT)

Rajesh,

> or dynamic assignment) to  associate the dynamic payload type with another

Yes, this is what I had in mind when I talked about a MIME description
for a storage format consisting of captured packets.

>          audio/red; pt="0,101"; da  =101 [audio/G729E;rate=8000;channels=1]

Can you guarantee that the enclosed MIME definition will not contain
any square backets?  If not, what quoting mechanism can be used for
the contained square brackets that won't conflict with a quoting
mechanism that might already be used within the MIME definition?

I'm not saying the syntax is impossible, I'm just saying that there
are several syntax requirements that must be considered.  I know that
I don't know enough about the MIME syntax and its existing uses to
answer the questions I posed above.

> stuff within the 'pt' parameter.

Embedding a MIME definition in the pt parameter is no different than
embedding it in a new da parameter.  In fact, it would probably be
better to embed the dynamic payload type bindings into the pt
parameter so that an opportunity for inconsistency (between pt and da)
is avoided:

         audio/red; pt=0,101[audio/G729E;rate=8000;channels=1]

> construct better syntaxes .

You are right to point out this problem, and we need to do something.
The draft is a collection of several MIME registrations, most of which
don't have any problem.  Several them are needed to be advanced to RFC
status quickly.  I intend to submit a revision before deadline
tomorrow.  Options are:

   - define a syntax to accomplish the embeded MIME definitions that
     will really work

   - remove audio/RED from this draft and write a new separate draft
     for that one alone

   - leave this flaw in place and accept the constraint on MIME
     specification of audio/RED usage until some future update

I'm open to input.
							-- Steve

---

From: Rajesh Kumar <[email-masked]>
Date: Thu, 19 Jul 2001 22:43:07 -0700

>mechanism that might already be used within the MIME definition?

Steve,
We're addressing a limited problem - how to represent rfc2198 encoding in 
MIME format. The rfc allows one level of nesting only. This is captured in 
the syntax I described. Right now, the problem of multiple levels of 
nesting is an academic one - I see no practical application. If you can 
support one level of nesting (and you can say so explicitly in the RTP MIME 
document), you've done what's needed to address currently defined RTP/AVP 
payload formats, of which RED is one.

In other words, what you're saying is an interesting problem, but the fact 
that we may not have an elegant representation of n-level nesting of MIMEs 
should not prevent us from stipulating what we need (and what we can 
represent cleanly): namely the single level of MIME nesting that is needed 
for rfc2198 support.

Rajesh

  Rajesh Kumar

---

From: Rajesh Kumar <[email-masked]>
Date: Thu, 19 Jul 2001 23:26:16 -0700

Steve,
I agree on all points. While you go to RFC with the current draft, I would 
much rather have the less restrictive stipulation:

"in audio/RED ... dynamic payload types can only be
included for payload formats that don't use square brackets in their
MIME parameter syntax. "

This would me it usable in the rfc2198 context at this time and would fix 
the problem from a practical perspective. You might also add a recommendation:

"Ir is recommended that RTP
MIME registrations, except audio/RED,  not  use square brackets. None of 
the  the RTP MIME registrations in this internet draft/RFC use square 
brackets. If square brackets are used, then under current syntax 
limitations, the embedding of the MIME registration in that for audio/RED 
is precluded."

I appreciate the difficulty. However, I do think we can , at this time, 
address it more adequately if not perfectly.

Rajesh

At 11:17 PM 7/19/2001 -0700, Stephen Casner wrote:
>Rajesh,
>
>No, I'm not talking about nesting.  I'm talking about the possibility
>that one of the payload formats that you want to use with a dynamic
>payload type under RFC2198 would use square brackets as part of the
>syntax of one of its parameters, say to delimit a list of features to
>be used.  Perhaps none of the payload formats defined so far specifies
>square brackets as part of its syntax, but unless there is a rule
>somewhere that says square brackets are not allowed, then it could
>happen in the future.
>
>If there is a global rule for MIME syntax that says square brackets
>are not allowed, then we can't use them for our purpose, either.
>
>If not, then we could add a rule in rtp-mime that says payload format
>MIME registrations are not allowed to use square brackets, except for
>audio/RED.  That seems bogus.
>
>Or we could say in audio/RED that dynamic payload types can only be
>included for payload formats that don't use square brackets in their
>MIME parameter syntax.  That's less restrictive than the current
>prohibition of all dynamic paylod types, but it is the same kind of
>thinking.
>
>Let me emphasize that I don't oppose crafting a solution here, it is
>just that I think doing it correctly is harder than you anticipate.
>
>                                                         -- Steve
>
>
>On Thu, 19 Jul 2001, Rajesh Kumar wrote:
>

  Rajesh Kumar

---

From: Stephen Casner <[email-masked]>
Date: Thu, 19 Jul 2001 23:17:26 -0700 (PDT)

Rajesh,

							-- Steve

---

From: Stephen Casner <[email-masked]>
Date: Mon, 30 Jul 2001 11:41:46 -0700 (Pacific Daylight Time)

I have expanded the syntax of the pt parameter for audio/RED (RFC
2198) to address the shortcoming that Rajesh identified.  That is, the
syntax now allows specifying the mapping for dyanmic payload types.

This change is in draft-ietf-avt-rtp-mime-05.txt -- I would appreciate
comments from the WG, especially from those with expertise in MIME
content-type syntax.
							-- Steve

---

From: Rajesh Kumar <[email-masked]>
Date: Mon, 30 Jul 2001 14:38:25 -0700

Steven,
Thanks. If the MIME experts see no problem, then it is fine with me.

I did find the following explanatory text obscure:

"The mapping of the pt parameter to the a=fmtp attribute is to eliminate 
the parameter name and change the commas to slashes."

Thanks,

Rajesh

> > Clearly, this restriction is behind the times and needs to be fixed.

Thanks,

  Rajesh Kumar