Subject: Re: [MMUSIC] Comments on ABNF in 4566bis

From: Peter Stevens <[email-masked]>
Date: Thu, 4 Dec 2014 15:50:43 +0000

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.

Thanks

Peter

________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: 01 December 2014 15:07
To: [email-masked]
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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Dec 2014 11:19:27 -0500

Peter,

> 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

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Dec 2014 11:22:07 -0500

One more thing:

These cases where questions arise about the syntax of attributes are 
precisely why this work needed to be done. If forces us to confront 
issues we didn't know we had.

	Thanks,
	Paul