Gary, Experts,
The MPEG-ES I-D is in IESG last call since 10/17. I believe that it is neither to SG16 and certainly not to MPEG to decide of its movement forward. For SG16 it is, however, relevant, that the assignment of an RFC number follows the IESG approval at considerable delay, typically several weeks. Unless someone is pushing the RFC editor really hard, the ES-I-D will not have a RFC number assigned in time for the SG meeting. I don't know what the SG should do regarding the determined code points referencing the draft.
If someone wants to stop the progress of the I-D now, the right action would be to announce so, including technical reasons, on the rem-conf reflector.
Before doing so I would like you to consider the following:
MPEG systems wants, for their own reasons, to promote MPEG systems, not only the media coding schemes. Many (including me) believe that the current system specification cannot be delivered over lossy networks. For that reason, the I-D focusing on the transmission of MPEG systems (SL-draft by Civanlar et. al) will likely move forward as "experimental" only, and not as standards track. I'm not sure that MPEG knows the difference, and I'm also not sure whether we in the ITU allow to normatively reference an experimental RFC. Would be nice to see this clarified.
Stephan
At 01:50 PM 10/26/2000 -0700, Gary Sullivan wrote:
ITU-T Systems and Video Experts,
I am at an MPEG meeting in France. There has been a lot of recent discussion here and in the IETF on how to carry MPEG-4 data on IP networks. I was asked by some MPEG participants to help explain and understand the impact of this work on ITU-T SG16.
My understanding is that the H.323 community has been expecting an IETF RFC with Proposed Standard status to be approved prior to the November SG16 meeting sufficient to specify an RTP packetization format for use in H.323 systems to carry MPEG-4 video (and perhaps audio) elementary streams.
However, there are some discussions here at MPEG about how to ensure that any such specification is adequate not only for the needs of H.323 but also for MPEG-4 systems as well.
As a result, it appears that MPEG is poised to recommend tomorrow that the current Kikuchi-san Internet Draft not be promoted to Proposed Standard RFC status in the IETF. This seems to mean that we are unlikely to be able to reach Decision status for this feature in H.323 in November in SG16.
The SG16 community needs to understand this unfortunate situation and its impact on the progress of work for the SG 16 meeting in November.
Best Wishes,
Gary Sullivan
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
At 11:22 PM 10/26/00 +0200, Stephan Wenger wrote:
Gary, Experts,
The MPEG-ES I-D is in IESG last call since 10/17. I believe that it is neither to SG16 and certainly not to MPEG to decide of its movement forward. For SG16 it is, however, relevant, that the assignment of an RFC number follows the IESG approval at considerable delay, typically several weeks. Unless someone is pushing the RFC editor really hard, the ES-I-D will not have a RFC number assigned in time for the SG meeting. I don't know what the SG should do regarding the determined code points referencing the draft.
It can sometimes take several months for the RFC to be issued after IESG last call, depending on how long the RFC Editor's queue is.
There is at least one other example in ITU (SG13) of an ITU Recommendation being decided (I believe Y.1310) with normative references to several I-Ds with the understanding that these specifications would reach Proposed Standard at some point and that the Recommendation would not be published until the RFCs were published. You can even purchase a copy of the pre-published version of Y.1310 with the normative references to the I-Ds in it. So theoretically, you could do the same thing here. However, one person described this method of doing things as buying a pig in a poke. :-)
If someone wants to stop the progress of the I-D now, the right action would be to announce so, including technical reasons, on the rem-conf reflector.
Before doing so I would like you to consider the following:
MPEG systems wants, for their own reasons, to promote MPEG systems, not only the media coding schemes. Many (including me) believe that the current system specification cannot be delivered over lossy networks. For that reason, the I-D focusing on the transmission of MPEG systems (SL-draft by Civanlar et. al) will likely move forward as "experimental" only, and not as standards track. I'm not sure that MPEG knows the difference, and I'm also not sure whether we in the ITU allow to normatively reference an experimental RFC. Would be nice to see this clarified.
I believe A.5 only allows normative references to Standards-Track RFCs, but you could always change it to an informational reference. That also obviates the tedious task of filling out the A.5 forms that are required.
Stephan
At 01:50 PM 10/26/2000 -0700, Gary Sullivan wrote:
ITU-T Systems and Video Experts,
I am at an MPEG meeting in France. There has been a lot of recent discussion here and in the IETF on how to carry MPEG-4 data on IP networks. I was asked by some MPEG participants to help explain and understand the impact of this work on ITU-T SG16.
My understanding is that the H.323 community has been expecting an IETF RFC with Proposed Standard status to be approved prior to the November SG16 meeting sufficient to specify an RTP packetization format for use in H.323 systems to carry MPEG-4 video (and perhaps audio) elementary streams.
However, there are some discussions here at MPEG about how to ensure that any such specification is adequate not only for the needs of H.323 but also for MPEG-4 systems as well.
As a result, it appears that MPEG is poised to recommend tomorrow that the current Kikuchi-san Internet Draft not be promoted to Proposed Standard RFC status in the IETF. This seems to mean that we are unlikely to be able to reach Decision status for this feature in H.323 in November in SG16.
The SG16 community needs to understand this unfortunate situation and its impact on the progress of work for the SG 16 meeting in November.
Best Wishes,
Gary Sullivan
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems "The best way to pick a lock is with a key." http://www.netaid.org -------------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Chip Sharp -
Stephan Wenger