[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