Re: [MMUSIC] Comments on ABNF in 4566bis
Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 12 January 2015 20:58 UTC
Return-Path: <prvs=0454da7ea7=pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220411ACD43 for <mmusic@ietfa.amsl.com>; Mon, 12 Jan 2015 12:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level:
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kQD3gWiS5lH for <mmusic@ietfa.amsl.com>; Mon, 12 Jan 2015 12:58:18 -0800 (PST)
Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB971A1A90 for <mmusic@ietf.org>; Mon, 12 Jan 2015 12:58:17 -0800 (PST)
X-AuditID: 1207440f-f792a6d000001284-ea-54b435672cf9
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id FD.FC.04740.76534B45; Mon, 12 Jan 2015 15:58:15 -0500 (EST)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0CKwEWT030592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Mon, 12 Jan 2015 15:58:15 -0500
Message-ID: <54B43566.9070002@alum.mit.edu>
Date: Mon, 12 Jan 2015 15:58:14 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <2F938AAE444ADB47AFEE6307955A30CE2EB98487@BGB01XUD1002.national.core.bbc.co.uk>, <5480898F.5020700@alum.mit.edu> <2F938AAE444ADB47AFEE6307955A30CE2EBB23AC@BGB01XUD1002.national.core.bbc.co.uk>
In-Reply-To: <2F938AAE444ADB47AFEE6307955A30CE2EBB23AC@BGB01XUD1002.national.core.bbc.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixO6iqJtuuiXE4MsxMYupyx+zODB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+PQ30/sBdtMKrZves3SwPhVo4uRk0NCwETi+vXVjBC2mMSF e+vZuhi5OIQELjNKXL5xjAXC+cskcaj3DitIFa+AtsS1WyBVnBwsAqoS81c1MYPYbAJaEnMO /WcBsUUFkiXWbJ3EDlEvKHFy5hOwuIiAsMSMt3/BeoUFDCXmdSxjh1hwhlHi39FZYIM4BWIk 9r3dB7SMg4NZwFri2+4ikDCzgLzE9rdzmCcw8s9CMnYWQtUsJFULGJlXMcol5pTm6uYmZuYU pybrFicn5uWlFuma6OVmluilppRuYoSEH/8Oxq71MocYBTgYlXh4J8hsDhFiTSwrrsw9xCjJ waQkypsjvSVEiC8pP6UyI7E4I76oNCe1+BCjBAezkggvkyJQjjclsbIqtSgfJiXNwaIkzqu+ RN1PSCA9sSQ1OzW1ILUIJivDwaEkwSttAtQoWJSanlqRlplTgpBm4uAEGc4lJVKcmpeSWpRY WpIRD4rI+GJgTIKkeID2njQG2VtckJgLFIVoPcWoKCXOGwUyVwAkkVGaBzcWllReMYoDfSnM 2whSxQNMSHDdr4AGMwENXty+GWRwSSJCSqqB0dTXemPk0gzWqrRLYp/b7KOyf0XXPpY+Eb34 8OqAqbn3lPNm3d8WIL1XiXeidu2xf/HZGXPOPmN8eGJGj6pyh1n+DpV9zy/smiu4WnOBhJpH 9+cD85bkfLhV3Gzge/GrweKLXnI3mxY12T5JeKXRE88l9aw0rGlRLeehG783Cger+J5Nqo39 psRSnJFoqMVcVJwIAAw9taUFAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/_vFcgzwbUp9PW4c9yOQaiHu8hHo>
Subject: Re: [MMUSIC] Comments on ABNF in 4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 20:58:22 -0000
On 1/12/15 12:51 PM, Peter Stevens wrote: > > Paul, > > Apologies for delayed response. > > I accept your comment of the case that we are concerned with here - > extensions with backward compatibility. > > In both the areas that I've cited, the same definition for both ptime > and maxptime is required and that is likely to generally be the most > desirable. > > Syntax 3 is likely to be the most flexible. > > The European Broadcasting Union - Audio Contribution overt IP (EBU ACIP) > generally uses whole numbers as integers (assuming that is what the > current RFC4566 definition is interpreted to mean), whereas an AES67 > node could send the same value as an integer or a decimal value, with > the decimal value at zero, e.g 4 or 4.000 Integer 4 would work with > both, whereas 4.000 may not work within ACIP. > > Within EBU ACIP Profiles work a new attribute to accommodate ptime for > each codec had to be defined - not yet registered with IANA and > mentioned recently here: https://www.ietf.org/mailman/listinfo/payload. > > I don't know of other users of this potential new ptime and maxptime > definition at the moment. > > If the definition in (the final) RFC4566 is updated to a new one, such > as syntax 3, then it would be backward compatible, and also allow newer > devices to also use a newer definition and maybe also allow older > devices to be updated to use the newer definition, in time. > > What procedure would be required for a change in this definition? Is > it just a request for a change from the organisations and support from > the general community reading this list? I have sent > > I see that your suggestion has popped up in > http://trac.tools.ietf.org/wg/mmusic/trac/ticket/21 on 10th January. Yes. This is already being dealt with as part of RFC4566bis. Looks like we will go with option 3. Thanks, Paul > Thanks > > Peter > > BBC R&D > > > ________________________________________ > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: 04 December 2014 16:19 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Comments on ABNF in 4566bis > > Peter, > > On 12/4/14 10:50 AM, Peter Stevens wrote: > > Hi Paul, > > > > I understand your position as scribe here and to have precise ABNF > definitions is a good thing. Colin's input has highlighted an issue of > which we were aware and backward compatibility and a common usage > between the EBU and AES (and probably others) is one of those, so being > able to possibly change the definition and at the same time keep > backward compatibility would be very useful. > > > > I've referred this back to both groups and I'm waiting for comments. > > Your case is one of doing extensions with backward compatibility. > That is related to, but slightly different from, trying to formally > specify a previously informal syntax that may or may not have included > decimal fractions. Depending on what we find currently deployed, we may > need different solutions for each parameter. > > I do expect that we will want the same definition for ptime and > maxptime, but the answer for the quality parameter might be different. > > For each, I see three candidate syntaxes to consider: > > 1) only whole-numbers > 2) optional fractional part > 3) optional fractional part only when the fraction is non-zero > > Going with (3) will help ensure that an implementation that supports > fractions will interwork with implementations that only support > whole-numbers as long as only integral values are used. But it's hard to > know whether that solves a real problem. > > Since you are defining new usage, I presume you could work with either > (2) or (3), right? > > Thanks, > Paul > > > Thanks > > > > Peter > > > > ________________________________________ > > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > > Sent: 01 December 2014 15:07 > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] Comments on ABNF in 4566bis > > > > On 11/27/14 4:12 AM, Peter Stevens wrote: > >> Hi, > >> > >> Colin has commented on this particular attribute: > >> > >> > a=ptime: and a=maxptime: > >> > - Are these always integers? > >> > >> This is a question within the EBU Audio Contribution over IP (ACIP) > >> group have noted that the ptime units are not specified within RFC4566. > >> If you were not already aware, within the AES, the AES67-2013 AES > >> Standard for audio applications of networks - High-performance streaming > >> audio-over-ip interoperability, packet time is defined with decimal > >> values as follows: > >> > >> a-ptime <milliseconds>[.<milliseconds decimal>] > >> a=maxptime <milliseconds>[.<milliseconds decimal>] > >> > >> Do ptime integers possibly conflict with decimal values? > >> It is unknown how manufacturers of products define their value of ptime > >> internally, such as 20ms, as either an integer of 20 (ms) or as 0.020 > > > > I am essentially just a scribe here. The point of working on the ABNF > > for these is to be precise where that wasn't previously the case. I made > > my best guess as to what was intended. If there are existing uses of > > fractional values, then we should specify that. > > > > My concern with this attribute is backward compatibility. If the > > definition was extended to allow decimal fractions, would that be > > backward compatible with existing implementations that might not expect > > to see fractional values? > > > > One possibility would be to allow the use of decimal fractions only when > > the fractional part is non-zero. E.g., > > > > ptime-value = packet-time > > packet-time = integer | non-zero-real > > non-zero-real = (integer / "0") "." *"0" integer > > > > (Note that in SDP ABNF "integer" never starts with a "0".) > > > > (This definition could also be used for framerate.) It would guarantee > > that values that are an integral number of milliseconds never have a > > fractional part, which would provide some compatibility with > > implementations that expect only integers. > > > > If there are no *existing* uses of fractional values, but a desire to > > use them, then another possibility is to define a new attribute. > > > > Thanks, > > Paul > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- [MMUSIC] Comments on ABNF in 4566bis Colin Perkins
- Re: [MMUSIC] Comments on ABNF in 4566bis Peter Stevens
- Re: [MMUSIC] Comments on ABNF in 4566bis Paul Kyzivat
- Re: [MMUSIC] Comments on ABNF in 4566bis Paul Kyzivat
- Re: [MMUSIC] Comments on ABNF in 4566bis Christian Groves
- Re: [MMUSIC] Comments on ABNF in 4566bis Colin Perkins
- Re: [MMUSIC] Comments on ABNF in 4566bis Paul Kyzivat
- Re: [MMUSIC] Comments on ABNF in 4566bis Paul Kyzivat
- Re: [MMUSIC] Comments on ABNF in 4566bis Paul Kyzivat
- Re: [MMUSIC] Comments on ABNF in 4566bis Colin Perkins
- Re: [MMUSIC] Comments on ABNF in 4566bis Colin Perkins
- Re: [MMUSIC] Comments on ABNF in 4566bis Paul Kyzivat
- Re: [MMUSIC] Comments on ABNF in 4566bis Peter Stevens
- Re: [MMUSIC] Comments on ABNF in 4566bis Paul Kyzivat
- Re: [MMUSIC] Comments on ABNF in 4566bis Peter Stevens
- Re: [MMUSIC] Comments on ABNF in 4566bis Paul Kyzivat
- Re: [MMUSIC] Comments on ABNF in 4566bis Peter Stevens