Re: [MMUSIC] Comments on ABNF in 4566bis

[Peter Stevens <[e-mail]>]

Hi Paul,

Thank you for the update.

Peter

________________________________________
From: Paul Kyzivat [[e-mail]]
Sent: 12 January 2015 20:58
To: [e-mail]
Subject: Re: [MMUSIC] Comments on ABNF in 4566bis

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 [[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
>  >
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>