On 8/12/13 2:37 PM, "Carsten Bormann" <[email protected]> wrote:
> If section 3.6 stays, the numerics need more work. +/- Infinity >should be > treated like NaN. > >(Why?) Having more than one way to encode +/- Infinity seems like a recipe for generating slightly different canonical output. For example, in my code right now, I think I'm always generating a half-precision Infinity, and I'm thinking about changing that to always be the 4-byte version. I now see that this section is just a recipe for how to define a canonicalization, not the actual rules you need to follow, and my comment may be moot. However, I suggest that section 3.6 is therefore not terribly useful, and it might be removed without harming the document. > In Appendix D, shouldn't the input be unsigned or an array of >bytes? > >It could also be unsigned short (which would be widened to int >anyway), but in this case it shouldn't matter. >(Array of bytes would just be slightly more tedious.) Agree that it's merely a tedious transformation, but I think it would be a lot more clear. Semantically, the input isn't an integer of any size. It's two bytes in a specific order. > Add PER. > >PER does need schema information even for parsing and would require >its own little dissertation, so we left this off. I think it's useful to call out an example that is explicitly schema-ridden, particularly since it has been called out in this conversation as something relevant. -- Joe Hildebrand _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
