Subject: [MMUSIC] ptime and maxptime ABNF

From: Adam Roach <[email-masked]>
Date: Wed, 25 Mar 2015 10:36:25 -0500

From today's slide, I think this proposal isn't quite what we want:

   non-zero-real = (integer / "0") "." *"0" integer

"integer" is defined as "POS-DIGIT *DIGIT", which makes the above syntax 
a hack to work around the fact that "integer" is defined for a different 
purpose. A more practical consequence is that this allows for trailing 
zeros, which is (I think) not what we want.

In other words, what we're really trying to do here is reverse the sense 
of "integer" (i.e.: integer allows trailing zeros but forbids leading 
zeros; we want to forbid trailing zeros and allow leading zeros).

This suggests a definition more like:

   non-zero-real = (integer / "0") "." *DIGIT POS-DIGIT

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Mar 2015 17:48:13 -0400

WFM

On 3/25/15 11:36 AM, Adam Roach wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Mar 2015 16:50:49 +0100

On 03/25/2015 04:36 PM, Adam Roach wrote:
> "integer" is defined as "POS-DIGIT *DIGIT", which makes the above
> syntax a hack to work around the fact that "integer" is defined for a
> different purpose. A more practical consequence is that this allows
> for trailing zeros, which is (I think) not what we want.
>
> In other words, what we're really trying to do here is reverse the
> sense of "integer" (i.e.: integer allows trailing zeros but forbids
> leading zeros; we want to forbid trailing zeros and allow leading zeros).
>

Nit: if you want to allow 0.030, you need to say

  non-zero-real = (integer / "0") "." *DIGIT POS-DIGIT *DIGIT

Trailing zeros used to be troublesome in DER encoding of certificates,
but otherwise, I don't have a problem with allowing them.
(Real implementations would probably just parse the value and compare it
to zero, however; doing this with ABNF is really stretching ABNF... for
instance, there's no way of having both trailing zeros and a clear upper
bound on the number of decimals.

Do we really want to allow 0.0000000000000000000000000000000000000000001?)

-- 
Surveillance is pervasive. Go Dark.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Mar 2015 12:05:09 -0400

> Do we really want to allow 0.0000000000000000000000000000000000000000001?)

We have a long tradition of not bounding the size of integers or the 
precision of fractions. I don't know if we want to break with that 
tradition. :-)

It is less trouble for reals. It is quite easy/common for numeric 
parsers to ignore extra precision beyond what they can represent.

In the case where we find ABNF incapable of representing what we want 
the fallback is to normative text.

This is all nits and taste.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Mar 2015 11:09:49 -0500

On 3/27/15 10:50, Harald Alvestrand wrote:
> Nit: if you want to allow 0.030...

I don't. Do you?

/a

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 Mar 2015 11:25:24 -0500

> On Mar 27, 2015, at 11:05 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> We have a long tradition of not bounding the size of integers or the precision of fractions. I don't know if we want to break with that tradition. :-)

Yes - most definitely. It's not possible to implement.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Mar 2015 12:28:35 -0400

>> Nit: if you want to allow 0.030...

In general I prefer to allow it. But I don't think it is *important* to 
allow it in *this* context.

While this might preclude reusing some encoding techniques, the 
requirement to only put in the fraction when it is non-zero also 
precludes some encoding techniques, but is important here to ease 
backward compatibility.

(When writing *code* that needs to include tables of values I often like 
to use leading zeros on integers and trailing zeros on fractions, 
together with tabular formatting, to make the tables easier to read. I 
hate the "leading zero means octal" of C/C++ for that reason. But those 
arguments don't apply in this context.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Mar 2015 12:56:28 -0400

> Yes - most definitely. It's not possible to implement.

We can do that in ABNF if we don't allow leading or trailing zeros. 
Picking an arbitrary limit:

       bounded-non-zero-integer = POS-DIGIT *10DIGIT
       bounded-non-zero-real =
           (bounded-non-zero-integer / "0") "." *10DIGIT POS-DIGIT
       packet-time = bounded-non-zero-integer | bounded-non-zero-real

But I don't know any way to do it *in ABNF* while also allowing leading 
and/or trailing zeros.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Mar 2015 06:26:17 +0200

>> Nit: if you want to allow 0.030...

Well... in the hierarchy of constituencies, I regard software developers
as more important than standards developers (and users higher than either).

If 0.030 is allowed, I can generate it as

printf("%.3", number).

If 0.030 is not allowed, I have to generate it as

buffer=sprintf("%.3", number);
while (buffer(buffer.end) == '0') {
  buffer.end--;
}
print buffer

OTOH, this is all moot if nobody needs fractions.