fyi - the response from the IETF Transport Area to MPEG
For your information:
This is the response from the IETF Transport Area Directors to the request from MPEG to delay consideration of the AVT working group draft draft-ietf-avt-rtp-mpeg4-es-05.txt.
While the specific timing of the IESG consieration takes into account SG16's timetable you can see by the response that the work itself is consistent with other RTP payloads - it is a simple solution to a specific problem.
Scott Bradner Allison Mankin IETF Transport Area Directors
---------------
As the Transport Area Directors of the IETF Internet Engineering Steering Group, we have carefully reviewed the technology in draft-ietf-avt-rtp-mpeg4-es-05.txt, and the points in your liaison statement to us.
We have decided to continue the process of advancing the draft on the standards track. Taking in turn each of the reasons you gave for IETF to suspend this process:
there is no consensus yet on the payload formats for the carriage of various MPEG-4 streams in WG11. For instance, there are still strong concerns that the payload format for MPEG-4 audio specified in <draft-ietf-avt-rtp-mpeg4-es-05.txt>, while adequate for a range of applications, is not appropriate for general use.
We first note that the MPEG-4 audio for the ES use in the draft is an approved standard of MPEG. The AVT Working Group reached what the chairs found to be an adequate rough consensus that the audio in the draft met the requirements of the intended applications of the draft. IETF-wide Last Call comments beside your liaison statement commented only on the question of generality, and did not question the validity of the audio for the intended applications using ES payload types.
Candidates for Proposed Standard may be advanced even when they have a known technical omissions (in this case, omitting alternative audio specifications). According to RFC 2026:
A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions.
The Area Directors support the need for timeliness in the case of this specification. The request from ITU-T SG16 is to be able to reference RTP encapsulations of MPEG-4 audio and video that are adequately provided by the elementary streams payload types. Future development of additional audio payload format and/or improvements in the current Audio-LATM payload format are encouraged, and will in no way be contraindicated by the Proposed Standard status of the elementary streams draft.
<draft-ietf-avt-rtp-mpeg4-es-05.txt> may not be used in the context of MPEG-4 over IP framework in the future.
Indeed, additional development of MPEG-4 specifications is needed for some applications, but the elementary streams draft is expected to serve the purpose of others.
We consider the situation to be analogous to the standards for MPEG-1 and -2 in RTP. For those payloads, when an application requires only Elementary Streams, it uses an ES-only payload type, and when it requires using all of the MPEG Systems Streams format, it uses an SL payload type.
WG11 would prefer to find a design for a single RTP payload format that would suffice for the carriage of all MPEG-4 content over IP networks.
This is not consistent with the design of RTP, which encourages distinct payload encapsulation for distinct application purposes, and has mechanisms for supporting the application layer framing (ALF) approach.
The format for both the ES and SL payload types for MPEG-2 happen to be contained in one RFC (2250), but the Transport Area generally prefers for working groups to publish the specifications meeting different applications requirements as separate RFCs, so that they can mature and be modified each on their own timescale.
RTP provides ample mechanism for uniquely identifying distinct payload types and for applications to signal them. The MIME declarations and payload type considerations for IANA in draft-ietf-avt-rtp-mpeg4-es-05.txt are explicit in distinguishing that the draft pertains only to elementary stream video and elementary stream LATM audio. There would be no identification or signalling difficulty for future specification of other MPEG-4 related payloads.
In summary, we welcome collaboration between the AVT Working Group and MPEG to develop the additional MPEG-4 payload types for RTP, but find that the technical development and IETF standards process are best served by submitting draft-ietf-avt-rtp-mpeg4-est-05.txt for IESG approval now and thereafter advancing it, with the best intention of meeting the ITU-T SG16 timeframe.
Allison Mankin and Scott Bradner IESG Transport Area Directors
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (1)
-
Scott Bradner