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

[Colin Perkins <[e-mail]>]

A couple of comments inline...

--> "Lim, Young-Kwon" writes:
>Dear all,
>
>As you might already notice new draft does not contain substantial changes
>because I'm waiting the approval from the MPEG group to change the document.
>It could be done during the meeting starting tomorrow. Then, I'll go to the
>IETF meeting next week to finalize the discussion with IETF AVT
>
>I want to discuss the open issues both on-line and off-line in parrallel
>since many of interesting people are not here. Here are the draft
>disposition about the comments from Colin;
...
>> > - Characteristic 2.6: where is the mapping for RFC 3016 defined?
>
>We asked the authors of RFC3016 to prepare the document about the mapping.
>The issue at that time was not technical but procedural. As you remember
>authors of RFC3016 don't want to delay of getting the RFC number because
>strict schedule of using it for ITU-T standards. Do you think we can add a
>section about the mapping in RFC3016 now?

It's not possible to change an RFC once it's been published, so we can't
add anything to RFC 3016. The mapping will either have to be a separate
document, or added to the framework draft.

...
>> > - 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
>
>This topic was discussed on the reflector. No technical changes are
>required. More detailed explanation about the scenario for the case of
>mixing MPEG-4 presentation and non-MPEG-4 streams would be helpful. Do you
>agree Colin?

Yes.

>> > - 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?
>
>We don't want to specify any specific encoding method here. But we have a
>example. Quotes from FDIS, "The location should be a URL enclosed in
>double-quotes, which will supply the IOD (e.g. small ones may be encoded
>using "data:", otherwise "http:" or other suitable file-access URL)." Is
>this sufficient?

Maybe. Someone more familiar with URL syntax needs to comment on what's
legal.

>> > - Characteristic 3.2 informally defines a number of MIME types (mpeg4-sl
>> >   and mpeg4-flexmux) which should be defined by reference to their specs.
>
>If you are concerned about the names in the example, we can simple remove
>it.

Either that, or reference the definitions.

>> > - Characteristic 3.4 would be better included as part of the payload
>> >   format, as an a=fmtp parameter.
>
>We are specifying basic rules as a guideline for payload format design.

It could be read as defining an SDP attribute, and the attribute in
question doesn't look appropriate.

>> > - Characteristic 4.1 contradicts the multi-sl draft, which also defines
>> >   "application" as a valid top level MIME type for MPEG4
>
>This topic was discussed and resolved. "application" could be top level MIME
>type for MPEG-4 streams except audio visual elementary streams. Both of
>draft will be updated accordingly.
>
>> >
>> > - 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).
>
>We prefer to use mpeg4 rather than mp4. mp4 should be used only for file
>format.
>
>> >
>> > - 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.
>
>This comment is little bit confusing to me. Can you answer this, Dave?

I can answer this: if there is an RTP payload format for FlexMux, which 
I assume there will be, then this should be part of that draft (not the
framework).

>> > - You need an IANA considerations section, if this is to be published as
>> >   an RFC.
>
>No disagreement.
>
>> >
>> > - References need updating. If this is to be published as an RFC, there
>> >   may be normative dependence on the payload formats..
>
>Absolutely.
>
>Looking forward to receiving comments.
>
>Sincerely,
>Young.

Cheers,
Colin

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