[resending with trimmed CC list, as the IETF mailing list processor will delay the message otherwise.] On Oct 29, 2019, at 15:16, Pete Resnick <resnick@xxxxxxxxxxxx> wrote: > > Add the scale column to the main registry and use one registry. The two registries have different policies (not in RFC 8228 nomenclature but in DE practice). If we treat entries with scale different from entries without scale, this is exactly equivalent to having two registries. Except that it is trivial to write a program to curl the second registry and convert a random SenML file to a clean main-registry-only file. If these are muddled, you of course can write a slightly longer program. The main difference remains one of signaling. How the signals emanating from a standards document actually influence the world is usually not very well understood, so I can see why different people would have different opinions here. I’d still prefer to signal that there is a clear difference between using SI base units and furlongs per fortnight, and decent SenML processors, given a choice, should do the former. (And I definitely want to signal that SenML is open for business, but I think we are discussing alternatives that are roughly equivalent in that respect, not sending away those other SDOs at the door.) > There's no upside to keeping two, as far as I can tell, and there's definitely the potential for interoperability problems. I think Ari’s point stands. What we could do is make it more explicit that a SenML implementation now has to heed both registries. But there never was a MUST on actually being able to process all registry 1 entries anyway, so I don’t quite know what that would mean for registry 2. We did everything that is needed to make it *easy* to implement registry 2, apart maybe from asking IANA to provide a JSON file with the registrations. Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
