Re: [MMUSIC] Comments on ABNF in 4566bis

[Peter Stevens <[e-mail]>]

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.



Thanks



Peter

BBC R&D

________________________________________
From: Paul Kyzivat [[e-mail]]
Sent: 04 December 2014 16:19
To: [e-mail]
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 [[e-mail]]
> Sent: 01 December 2014 15:07
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>