Subject: [AVT] RE: Comments on draft-singer-mpeg4-ip-03.txt

From: CURET Dominique FTRD/DMI/REN <[email-masked]>
Date: Wed, 19 Dec 2001 18:16:31 +0100

Dear all,

My understanding is that the goal of this framework draft is to give a
global picture, from the MPEG-4 point of view, for the recommended RTP
payloads to carry MPEG-4 signals.

This framework draft is not a new payload. It recognises the MultipleSL
payload and the Flexmux payload.

As the MultipleSL draft payload and the Flexmux draft payload have recently
evolved, and as the framework draft does not seem to have been updated, it
is right and obvious that the framework draft may be inconsistent with the
recent draft payloads.

From a FlexMux payload's author point of view, as I am not directly one of
the authors of the framework draft, I didn't feel the necessity informing
the authors (David & Young-Kwon) of the framework, on the evolution of the
details of the Flexmux draft payload. 

The text of the framework draft is quite difficult to finalize, as it tries
to present a digest of the different payloads. Inconsistency is difficult to
avoid in such cases. As far as SDP declaration is concerned, may be should
we give the exact details within the different payloads, without repeating
(which is always inconsistent!) such details in the framework. It is also
certainly possible to have the IANA considerations only within that
framework, and get rid of the IANA considerations in the draft payloads?

I think that keeping consistent our drafts is one task of the 4on2andIP Ad
Hoc group. 

your comments are welcome

yours sincerly

dominique

-----Message d'origine-----
De : Colin Perkins [mailto:[email-masked]]
Envoyé : mercredi 19 décembre 2001 16:47
À : [email-masked]
Cc : [email-masked]
Objet : Comments on draft-singer-mpeg4-ip-03.txt

Folks,

I've been asked to forward this discussion to the list. These are my
comments
on the MPEG-4 framework draft (draft-singer-mpeg4-ip-03.txt), which I've
just
become aware is still under consideration in MPEG.

Colin

------- Forwarded Message
> - The restriction in characteristic 2.3 (ISO/IEC 14496 timescale MUST be
used 
>   as the RTP timescale) is not present in
draft-ietf-avt-mpeg4-multisl-03.txt
>   I assume it is implicit, but this should be made explicit.
>
> - Characteristic 2.4 (MUST implement a default scheme) is meaningless
unless
>   the default is defined. 
>
> - Characteristic 2.6: where is the mapping for RFC 3016 defined?
>
> - Characteristic 2.6 is repeated, the numbering needs to be corrected.
>
> - Characteristics 2.7 - 2.9 are inconistent with the FlexMux format in
>   draft-curet-avt-rtp-mpeg4-flexmux-02.txt. Which is correct?
> 
> - I'm concerned about the use of the "a=mpeg4-iod:" attribute at the SDP
>   session level, given that it is not mentioned in the payload format
>   drafts. This restricts a session description to describing a single
>   MPEG-4 session, and it is not clear how sessions that do not use MPEG-4
>   Systems will interact with this. Similar with a=mpeg4-iod-xmt
> 
> - Are there any encoding considerations for URLs in SDP? Presumably the
>   URL encoding needs to be performed, which is more than just enclosing
>   the URL in double quotes?
>
> - Characteristic 3.2 informally defines a number of MIME types (mpeg4-sl
>   and mpeg4-flexmux) which should be defined by reference to their specs.
>
> - Characteristic 3.4 would be better included as part of the payload 
>   format, as an a=fmtp parameter.
>
> - Characteristic 4.1 contradicts the multi-sl draft, which also defines
>   "application" as a valid top level MIME type for MPEG4
>
> - Characteristic 4.4 contradicts RFC 3016, which uses video/mp4v-es. It
>   may be better to use mp4... as the prefix for all the MIME types, not
>   mpeg4..., to be consistent with RFC 3016 and the file formats (e.g. in
>   4.5 - 4.7).
> 
> - In 4.8, the mpeg4-flexmux type is registered. This should either be done
>   as part of the FlexMux payload format, or the registration should be
>   explicit that this is for the file format, and an alternative format
>   will be used for streaming with RTP.
> 
> - You need an IANA considerations section, if this is to be published as
>   an RFC.
>
> - References need updating. If this is to be published as an RFC, there
>   may be normative dependence on the payload formats..
------- End of Forwarded Message

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

---

From: "Lim, Young-Kwon" <[email-masked]>
Date: Fri, 21 Dec 2001 17:31:36 +0900

Dear Dominique,

Sorry for late comments.

> is right and obvious that the framework draft may be inconsistent with the

As I mentioned several times, framework doesn't specify any technical
detailes related to specific payload formats. It only fill the holes which
can not be filled by payload formats and provide a guideline to design
efficient payload formats providing minimum compatibility.

Would you please provide a detailed list of inconsistent descriptions? They
should be fixed before it is publised if they are editorial. If not, we need
to issue COR.

> details of the Flexmux draft payload.

I repeat. It should not be needed.

> (which is always inconsistent!) such details in the framework.

This is not true, Dominique.

> It is also

What do you mean by this? I can't catch your point.

> I think that keeping consistent our drafts is one task of the 4on2andIP Ad

I agree.

Sincerely,
Young.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Dec 2001 10:11:35 -0500

>efficient payload formats providing minimum compatibility.

I agree that it shouldn't specify any technical details, but it currently 
does specify them.

>should be fixed before it is publised if they are editorial. If not, we need

See my earlier messages.

>What do you mean by this? I can't catch your point.

All IETF RFCs need an "IANA considerations" section, explaining which new
types and parameters (if any) are registered. 

Colin