Draft: draft-ietf-core-senml

Commentary: This should now consider and . There are no perfect solutions for these , but the solutions chosen should be close . 
 I do n't agree wth some of this but agree with a bunch . I took carsten 's changes for all the parts I agree with and put them in 
 I might suggest we pull that PR and then look at what is left ( on a bunch of them it is simply if there should be an * suggesting do n't use or not ) then we can rebase this PR and see what is left to resolve . 
 Oops , I just changed my PR to react to your comments before seeing 
 Pushed another version that has both / and % for the same thing , where % is marked with a * 
 Now , instead of delete , it 's " not recommend " and mentions kg as exception . I think this is good to merge . 
 The following units are questionable : % -- this looks like a percentage ( 0 .. 100 ) , but it is not ( 0 .. 1 ) . count -- what ? This is about a dimensionless quantity ? % RH , % EL appear to be percentages , but imply a quantity . EL may be a quantity , but the unit is second . In SI , we do n't do new units for new quantities ( there is no " millimeter radius " or " nanometer wavelength " ) . Bspl -- this really should be in dB ( see ) , SPL is the quantity again . beat / min , beats -- these should be 1 / min ( but see ) and 1 ( dimensionless ) ; how is beats different from count ? We do n't have bit ( but bit / s ) , byte . 1 / min is there only for heartbeats , not for revolutions ( " rpm " ) . Should really be 1 / s ( but see ) . lat and lon are a bit weird , too . (  is also questionable -- the rationale of should call for all measurements being expressed in  . ) 
 on on kevin vs C , every thermostat manufacture I can find has said they want C over  . bunch of implementation are using 0 to 1 for light levels but imagine we could change % to 0 to 100 count - yep count :-) Bunch of sensors simply count pulses of who knows what . Totally agree this is not a unit but this is the pragmatic sort of thing needed EL is a great example of something that many sensors in sports have to deal with in common way . They use this and it works well for them 
 So I changed % to mean percentage . Cel of course stays in ( even though it is wrong wrong wrong :-) . I have marked count and EL with the " not so recommended for new producers " range . But we do n't really have a base unit for " 1 " ( dimensionless ) either . The problem remains that giving a unit does n't tell you what quantity actually has been measured , and the trend to make more and more finer grained units for the same kinds quantities measured in different ways ( as in psi vs. psig etc . ) leads into the woods . 
 just finding all the email now … I think the thing that people like about this is it ’s not a SI unit , it ’s something that tells you something useful about what you are measuring across a wide range of devices . I think we need to think of these from a point of view of broadly useful than are they a SI unit . Agree with your slippery slope psi , psig , etc argument but all of those exist for a reason . 
 The SI unit for mass is kg . 1 says : That leads to being unable to use the SI unit for mass , instead , we are using g. But then we are using derived units such as l ( dm3 ) and l / s ( dm3 / s ) . So : need to decide the above TODO . need to decide whether to stick with SI units or allow simple names for derived units ( gram , minute , liter ) . Domain - specific units are often weird ( 1 / min = " rpm " , mmHg or mol / dl in medicine , ... ) . 
 I think a key part of the registry vs existing SI unit tables was to be able to use things that were not proper units but agree things can be cleaned up . Clearly rpm and bpm have the same unit in the sense of what the dimensions are but what they are used to measure are pretty different and knowing that it is bpm often provides a level of information about how to process the information . As related to our whole conversation on why we needed the IANA table , the ability to have things in this that are not really a classic SI unit is the key value of SenML . The rules are just guidelines . If we want to change the unit of mass from g to kg , we can do that but the point on the prefixes was not to have both g and  as that just reduces interoperability
IANA will create a registry of SenML unit symbols.  The primary
purpose of this registry is to make sure that symbols uniquely map to
give type of measurement.  Definitions for many of these units can be
found in location such as NIST811 and BIPM.
Note 1: A value of 0.0 indicates the switch is off while 1.0
indicates on and 0.5 would be half on.
IANA will create a registry of SenML unit symbols.  The primary
purpose of this registry is to make sure that symbols uniquely map to
give type of measurement.  Definitions for many of these units can be
found in location such as NIST811 and BIPM.  Units marked with an
asterisk are NOT RECOMMENDED to be produced by new implementations,
but are in active use and SHOULD be implemented by consumers that can
use the related base units.
Use of SI prefixes such as "k" before the unit is not allowed.
Instead one can represent the value using scientific notation such
a 1.2e3.  TODO - Open Issue.  Some people would like to have SI
prefixes to improve human readability.
Use of SI prefixes such as "k" before the unit is not recommended.
Instead one can represent the value using scientific notation such
a 1.2e3.  The "kg" unit is exception to this rule since it is an
SI base unit; the "g" unit is provided for legacy compatibility.