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
>