[Cc'ing last-call.]
I have to agree with Cullen. In fact, the paragraph at the bottom of
section 4 shows the confusion and harm:
SenML packs MAY, but SHOULD NOT, use secondary units in place of
SenML units, where the exception of the "SHOULD NOT" lies in the
context of specific existing data models that are based on these
secondary units.
You can't "MAY" do something and "SHOULD NOT" do it. Those are
contradictory terms.
Either register these (and all SI prefixes) in the existing registry, or
don't register these at all. Implementations are perfectly capable of
multiplying and adding.
pr
On 22 Oct 2019, at 23:05, Cullen Jennings wrote:
I am strongly opposed to the secondary registry - it will
significantly harm interoperability. This could be resolved by not
adding the items in the secondary repository or by adding them to the
main repository.
Having a registry of stuff that may or may not work simply means that
we will have less interoperability because what you can not decide
what is valid SenML or not. Sure some of the device vendors making
things that produce SenML have thought this was a good idea in the
past but I’d like to hear from a bunch of the people that have to
process the SenML data that is produced and see if they think it is a
good idea.
The working group discussed this for a long time and was against the
items that are being added to the secondary repository.
If there is a large group of people that agree the consensus has
changed, then this should simply be put in the main registry. Many
people believe that since SenML is not meant to be human readable,
having a canonical form of just meters with a floating point number is
better than having both km, mm, and god only knows what else.
I note the secondary repository add mm but not cm. How is this
insanity going to work out? How will analytics code trying to process
this data know what it can use or not use. If we are going down this
path, this is the wrong way to do it. The right way is to define a set
of all SI prefixes and say they can be used with any unit.
On Oct 16, 2019, at 11:42 AM, The IESG <iesg-secretary@xxxxxxxx>
wrote:
The IESG has received a request from the Constrained RESTful
Environments WG
(core) to consider the following document: - 'Additional Units for
SenML'
<draft-ietf-core-senml-more-units-02.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2019-10-30. Exceptionally, comments
may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of
the Subject line to allow automated sorting.
Abstract
The Sensor Measurement Lists (SenML) media type supports the
indication of units for a quantity represented. This short
document
registers a number of additional unit names in the IANA registry
for
Units in SenML. It also defines a registry for secondary units
that
cannot be in SenML's main registry as they are derived by linear
transformation from units already in that registry; RFC 8428 is
updated to also accept these units.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
core mailing list
core@xxxxxxxx
https://www.ietf.org/mailman/listinfo/core
--
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
