[AVT] RFC 2833bis: open issues
Henning Schulzrinne <hgs@cs.columbia.edu> Fri, 04 July 2003 15:27 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29471 for <avt-archive@odin.ietf.org>; Fri, 4 Jul 2003 11:27:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSSk-0004A6-Bo for avt-archive@odin.ietf.org; Fri, 04 Jul 2003 11:27:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64FR2Xl015973 for avt-archive@odin.ietf.org; Fri, 4 Jul 2003 11:27:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSSj-00049Q-At; Fri, 04 Jul 2003 11:27:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSRu-00044X-1K for avt@optimus.ietf.org; Fri, 04 Jul 2003 11:26:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29370 for <avt@ietf.org>; Fri, 4 Jul 2003 11:26:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YSRt-0006jc-00 for avt@ietf.org; Fri, 04 Jul 2003 11:26:09 -0400
Received: from romaine.cc.columbia.edu ([128.59.59.210] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19YSRs-0006jX-00 for avt@ietf.org; Fri, 04 Jul 2003 11:26:08 -0400
Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by romaine.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h64FQ64M013477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <avt@ietf.org>; Fri, 4 Jul 2003 11:26:06 -0400 (EDT)
Message-ID: <3F059C7D.8070304@cs.columbia.edu>
Date: Fri, 04 Jul 2003 11:25:49 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Subject: [AVT] RFC 2833bis: open issues
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
As requested by Colin, the Vienna discussion items for 2833bis (named events and tones): There have been no major changes, except a cleanup of MF description based on ITU and other documents. I believe this is now essentially correct. The example was extended to include a sequence of packets, not just one. Based on feedback from a number of readers, editorial changes were made to make the document easier to read. I believe the draft would be ready for last call if we weren't blocked on interop statements to progress the document to Draft Standard. There has been essentially no progress on this, unfortunately. There are two choices: (1) Cycle at Proposed and hope that somebody else has the energy to drum up interop reports so that the document can progress to Draft at some later point. I wouldn't hold my breath, so this means that 2833bis joins the list of Proposed Standards that run the Internet. (2) Try to come up with a reasonably small list of items to test, such as - support for end-of-event indication - support for end-of-event replication - support for long events - RFC 2198 - frequency generation - list of events supported and hope that people will step up and report. Finding pairs of implementations that, say, support a particular code point is going to be rather challenging, unless we define support as "printf the correct number". I would suggest that a report of usage (transmit & receive) of an event type should be considered sufficient here since there's no dependency on the sender. Henning _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] RFC 2833bis: open issues Henning Schulzrinne