├── .gitignore ├── Dockerfile ├── Makefile ├── README.md ├── TODO.md ├── archive ├── draft-jennings-senml-00.html ├── draft-jennings-senml-00.txt ├── draft-jennings-senml-00.xml ├── draft-jennings-senml-01.html ├── draft-jennings-senml-01.txt ├── draft-jennings-senml-02.txt ├── draft-jennings-senml-03.html ├── draft-jennings-senml-03.txt ├── draft-jennings-senml-03.xml ├── draft-jennings-senml-04.html ├── draft-jennings-senml-04.txt ├── draft-jennings-senml-04.xml ├── draft-jennings-senml-05.html ├── draft-jennings-senml-05.txt ├── draft-jennings-senml-05.xml ├── draft-jennings-senml-06.html ├── draft-jennings-senml-06.txt ├── draft-jennings-senml-07.html ├── draft-jennings-senml-07.txt ├── draft-jennings-senml-07.xml ├── draft-jennings-senml-08.html ├── draft-jennings-senml-08.txt ├── draft-jennings-senml-08.xml ├── draft-jennings-senml-09.txt ├── draft-jennings-senml-09.xml ├── draft-jennings-senml-10.txt └── draft-jennings-senml-10.xml ├── bin ├── exificient.jar ├── jing.jar ├── trang.jar └── xercesImpl.jar ├── check-cddl-table-against-tbl-cbor-labels.rb ├── draft-ietf-core-senml.md ├── ex1.gen.exi ├── ex1.gen.exi.hex ├── ex1.gen.json ├── ex1.gen.resolved.json ├── ex1.gen.xml ├── ex1.json ├── ex10.gen.json ├── ex10.gen.resolved.json ├── ex10.gen.wrap.json ├── ex10.json ├── ex11.gen.json ├── ex11.gen.resolved.json ├── ex11.gen.wrap.json ├── ex11.json ├── ex12.gen.json ├── ex12.gen.resolved.json ├── ex12.json ├── ex13.gen.json ├── ex13.json ├── ex2.gen.exi ├── ex2.gen.exi.hex ├── ex2.gen.json ├── ex2.gen.resolved.json ├── ex2.gen.xml ├── ex2.json ├── ex3.gen.cbor ├── ex3.gen.cbor.diag ├── ex3.gen.cbor.hex ├── ex3.gen.cbor.txt ├── ex3.gen.json ├── ex3.gen.resolved.json ├── ex3.gen.wrap.json ├── ex3.gen.xml ├── ex3.json ├── ex4.gen.json ├── ex4.gen.json-trim ├── ex4.gen.resolved.json ├── ex4.gen.wrap.json ├── ex4.json ├── ex5.gen.cbor ├── ex5.gen.exi ├── ex5.gen.exi.hex ├── ex5.gen.json ├── ex5.gen.resolved.json ├── ex5.gen.resolved.wrap.json ├── ex5.gen.wrap.json ├── ex5.gen.xml ├── ex5.json ├── ex6.gen.json ├── ex6.gen.resolved.json ├── ex6.gen.wrap.json ├── ex6.json ├── ex7.gen.json ├── ex7.gen.resolved.json ├── ex7.json ├── ex8.gen.json ├── ex8.gen.resolved.json ├── ex8.gen.wrap.json ├── ex8.gen.xml ├── ex8.json ├── ex9.gen.json ├── ex9.gen.resolved.json ├── ex9.json ├── example ├── ExiProcessor.jar ├── Makefile ├── jing.jar ├── senml-simple.exi ├── senml-simple.xml ├── senml-temp.exi ├── senml-temp.xml ├── senml.exi ├── senml.json ├── senml.rnc ├── senml.rng ├── senml.xml ├── senml.xsd └── trang.jar ├── lib ├── addstyle.sed └── style.css ├── rfc8428.txt ├── senml-cbor.cddl ├── senml-json.cddl ├── senml-json2cbor.rb ├── senml.cddl ├── senml.gen.xsd ├── senml.rnc └── size.md /.gitignore: -------------------------------------------------------------------------------- 1 | draft*.redxml 2 | draft*.txt 3 | draft*.html 4 | draft*.pdf 5 | a 6 | *~ 7 | draft*.xml 8 | .refcache 9 | .i-d-template 10 | old 11 | old? 12 | ex*.chk 13 | ex*.Z 14 | foo.html 15 | bar.html 16 | senml.tmp.xsd 17 | 18 | -------------------------------------------------------------------------------- /Dockerfile: -------------------------------------------------------------------------------- 1 | # Set up a docker machine that has all the tools to build teh senml spec 2 | 3 | FROM ubuntu:latest 4 | MAINTAINER Cullen Jennings 5 | 6 | # set up basic build machine 7 | RUN apt-get -y update 8 | 9 | RUN apt-get -y upgrade 10 | 11 | RUN apt-get -y install tcsh 12 | 13 | RUN apt-get install -y gcc make 14 | 15 | # RUN apt-get install -y build-essential 16 | 17 | RUN apt-get install -y python-pip python-dev 18 | RUN pip install --upgrade pip 19 | 20 | RUN apt-get install -y default-jre default-jdk 21 | 22 | RUN apt-get install -y rubygems ruby-full ruby-json 23 | RUN gem install bundle 24 | 25 | RUN apt-get install -y golang git 26 | 27 | # install XML2RFC 28 | RUN pip install xml2rfc 29 | 30 | # install Kramdown 31 | RUN gem install kramdown-rfc2629 32 | 33 | # install senmlCat 34 | RUN mkdir /go 35 | ENV PATH /go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 36 | ENV GOPATH /go 37 | RUN go get github.com/cisco/senml 38 | RUN ( cd /go/src/github.com/cisco/senml/cmd/senmlCat/ ; go install ) 39 | 40 | # install cddl to check cbor files 41 | RUN gem install cddl 42 | 43 | # instally tidy to relow XML 44 | RUN apt-get install -y tidy 45 | 46 | RUN gem install libcbor cbor 47 | 48 | # get hexdump 49 | RUN apt-get install -y bsdmainutils 50 | 51 | VOLUME /senml 52 | WORKDIR /senml 53 | 54 | CMD [ "/usr/bin/make", "draft" ] 55 | 56 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | 2 | # https://pypi.python.org/pypi/xml2rfc 3 | xml2rfc ?= xml2rfc 4 | # https://github.com/cabo/kramdown-rfc2629 5 | kramdown-rfc2629 ?= kramdown-rfc2629 6 | 7 | 8 | DRAFT = draft-ietf-core-senml 9 | VERSION = 15 10 | 11 | .PHONY: draft txt html pdf clean check check2 12 | 13 | draft: txt html 14 | 15 | diff: $(DRAFT).diff.html 16 | 17 | gen: check check2 check3 ex1.gen.exi.hex ex1.gen.xml ex1.json ex10.json ex11.json ex2.gen.exi.hex ex2.gen.xml ex2.json ex3.json ex4.gen.json-trim ex5.json ex6.json senml.gen.xsd senml.rnc ex8.json ex3.gen.xml ex3.gen.cbor.hex ex3.gen.cbor.diag size.md ex3.gen.cbor.txt ex3.gen.cbor ex8.gen.xml ex1.gen.json ex10.gen.json ex11.gen.json ex2.gen.json ex3.gen.json ex5.gen.json ex6.gen.json ex8.gen.json ex3.gen.wrap.json ex6.gen.wrap.json ex8.gen.wrap.json ex7.gen.json ex5.gen.resolved.json ex9.gen.json ex12.gen.json ex13.gen.json ex5.gen.wrap.json ex5.gen.resolved.wrap.json ex10.gen.wrap.json ex11.gen.wrap.json ex4.gen.wrap.json ex1.gen.json ex5.gen.exi.hex 18 | 19 | check: ex11.gen.chk ex10.gen.chk ex6.gen.chk ex5.gen.chk ex4.gen.chk ex3.gen.chk ex2.gen.chk ex1.gen.chk ex9.gen.chk ex12.gen.chk ex13.gen.chk 20 | 21 | check2: ex11.chk ex10.chk ex8.chk ex6.chk ex5.chk ex4.chk ex3.chk ex2.chk ex1.chk ex3.gen.cbor.chk ex3.gen.cbor.txt ex9.chk ex12.chk ex13.chk 22 | 23 | check3: ex1.gen.resolved.json ex2.gen.resolved.json ex3.gen.resolved.json ex4.gen.resolved.json ex5.gen.resolved.json ex6.gen.resolved.json ex7.gen.resolved.json ex8.gen.resolved.json ex9.gen.resolved.json ex10.gen.resolved.json ex11.gen.resolved.json ex12.gen.resolved.json 24 | 25 | all: gen draft 26 | 27 | $(DRAFT).diff.html: $(DRAFT)-$(VERSION).txt $(DRAFT)-old.txt 28 | htmlwdiff $(DRAFT)-old.txt $(DRAFT)-$(VERSION).txt > $(DRAFT).diff.html 29 | 30 | 31 | txt: $(DRAFT)-$(VERSION).txt 32 | html: $(DRAFT)-$(VERSION).html 33 | pdf: $(DRAFT)-$(VERSION).pdf 34 | 35 | 36 | clean: 37 | -rm -f $(DRAFT)-$(VERSION).{txt,html,xml,pdf} ex*.gen* ex*.chk axs senml.gen.xsd size.md draft-ietf-core-senml-??.* 38 | 39 | size: ex5.json ex5.gen.xml ex5.gen.exi ex5.gen.cbor ex5.json.Z ex5.gen.xml.Z ex5.gen.exi.Z ex5.gen.cbor.Z 40 | 41 | .INTERMEDIATE: $(draft).xml 42 | 43 | %.Z: % 44 | gzip -n -c -9 < $< > $@ 45 | 46 | 47 | $(DRAFT)-$(VERSION).xml: $(DRAFT).md 48 | $(kramdown-rfc2629) $< > $@ 49 | 50 | #$(DRAFT)-$(VERSION).xml: $(DRAFT).md ex1.gen.exi.hex ex1.gen.xml ex1.json ex10.json ex11.json ex2.gen.exi.hex ex2.gen.xml ex2.json ex3.json ex4.gen.json-trim ex5.json ex6.json senml.gen.xsd senml.rnc ex8.json ex3.gen.xml ex3.gen.cbor.hex size.md ex3.gen.cbor.txt 51 | # $(kramdown-rfc2629) $< > $@ 52 | 53 | 54 | %.txt: %.xml 55 | $(xml2rfc) $< -o $@ --text 56 | 57 | %.html: %.xml 58 | $(xml2rfc) $< -o $@ --html 59 | 60 | %.gen.xml: %.json 61 | senmlCat -xml -ijson -i -print $< | tidy -xml -i -wrap 68 -q -o $@ 62 | 63 | %.gen.json: %.json 64 | senmlCat -json -ijson -i -print $< > $@ 65 | 66 | %.gen.resolved.json: %.json 67 | senmlCat -json -ijson -resolve -i -print $< | sed -e 's/"bver"\:.,//' > $@ 68 | 69 | 70 | 71 | %.gen.cbor: %.json senml-json2cbor.rb 72 | ruby senml-json2cbor.rb $< > $@ 73 | 74 | %.gen.cbor.diag: %.gen.cbor 75 | cbor2diag.rb $< > $@ 76 | 77 | %.gen.cbor.txt: %.gen.cbor 78 | cbor2pretty.rb $< | sed -e "s/6465763a6f773a3130653230373361303130383/ ... /" > $@ 79 | 80 | %.chk: %.xml senml.rnc 81 | java -jar bin/jing.jar -c senml.rnc $< > $@ 82 | 83 | %.chk: %.json senml.cddl senml-json.cddl 84 | cat senml.cddl senml-json.cddl | cddl - validate $< > $@ 85 | 86 | %.gen.cbor.chk: %.gen.cbor senml.cddl senml-cbor.cddl 87 | cat senml.cddl senml-cbor.cddl | cddl - validate $< > $@ 88 | 89 | %.tmp.xsd: %.rnc 90 | java -jar bin/trang.jar $< $@ 91 | 92 | %.gen.xsd: %.tmp.xsd 93 | cat $< | tidy -xml -q -i -wrap 68 -o $@ 94 | 95 | 96 | ex4.gen.json-trim: ex4.gen.wrap.json 97 | head -11 < $< > $@ 98 | 99 | ex3.gen.wrap.json: ex3.gen.json 100 | cat ex3.gen.json | sed -e 's/,"bu"/,# "bu"/' | sed -e 's/,"n"/,# "n"/' | tr "#" "\n" > ex3.gen.wrap.json 101 | 102 | ex10.gen.wrap.json: ex10.gen.json 103 | cat ex10.gen.json | sed -e 's/,"v"/,# "v"/' | tr "#" "\n" > ex10.gen.wrap.json 104 | 105 | ex11.gen.wrap.json: ex11.gen.json 106 | cat ex11.gen.json | sed -e 's/,"v"/,# "v"/' | tr "#" "\n" > ex11.gen.wrap.json 107 | 108 | ex4.gen.wrap.json: ex4.gen.json 109 | cat ex4.gen.json | sed -e 's/,"bu"/,# "bu"/' | tr "#" "\n" > ex4.gen.wrap.json 110 | 111 | ex5.gen.wrap.json: ex5.gen.json 112 | cat ex5.gen.json | sed -e 's/,"bu"/,# "bu"/' | tr "#" "\n" > ex5.gen.wrap.json 113 | 114 | ex5.gen.resolved.wrap.json: ex5.gen.resolved.json 115 | cat ex5.gen.resolved.json | sed -e 's/,"v"/,# "v"/' | tr "#" "\n" > ex5.gen.resolved.wrap.json 116 | 117 | ex6.gen.wrap.json: ex6.gen.json 118 | cat ex6.gen.json | sed -e 's/\+09,/\+09,# /' | sed -e 's/\:1",/\:1",# /' | tr "#" "\n" > ex6.gen.wrap.json 119 | 120 | ex8.gen.wrap.json: ex8.gen.json 121 | cat ex8.gen.json | sed -e 's/,"l"/,# "l"/' | sed -e 's/,"n"/,# "n"/' | tr "#" "\n" > ex8.gen.wrap.json 122 | 123 | %.hex: % 124 | hexdump -C $< | sed -e "s/0000//" | sed -e "s/ |/ |/" | sed -e "s/ / /" | sed -e "s/ / /" > $@ 125 | 126 | 127 | ex5.gen.exi: ex5.gen.xml senml.gen.xsd 128 | cp senml.gen.xsd a 129 | java -cp "bin/xercesImpl.jar:bin/exificient.jar" com.siemens.ct.exi.cmd.EXIficientCMD -encode -i ex5.gen.xml -o ex5.gen.exi -schema a -strict -includeOptions -includeSchemaId 130 | 131 | ex2.gen.exi: ex2.gen.xml senml.gen.xsd 132 | cp senml.gen.xsd a 133 | java -cp "bin/xercesImpl.jar:bin/exificient.jar" com.siemens.ct.exi.cmd.EXIficientCMD -encode -i ex2.gen.xml -o ex2.gen.exi -schema a -strict -includeOptions -includeSchemaId 134 | 135 | ex1.gen.exi: ex1.gen.xml senml.gen.xsd 136 | cp senml.gen.xsd a 137 | java -cp "bin/xercesImpl.jar:bin/exificient.jar" com.siemens.ct.exi.cmd.EXIficientCMD -encode -i ex1.gen.xml -o ex1.gen.exi -schema a -strict -includeOptions -includeSchemaId -bytePacked 138 | 139 | 140 | size.md: ex5.gen.cbor ex5.gen.cbor.Z ex5.gen.exi ex5.gen.exi.Z ex5.gen.xml ex5.gen.xml.Z ex5.json ex5.json.Z 141 | echo "| Encoding | Size | Compressed Size |" > size.md 142 | echo "| JSON | " `cat ex5.json | wc -c ` "|" `cat ex5.json.Z | wc -c` "|" >> size.md 143 | echo "| XML | " `cat ex5.gen.xml | wc -c ` "|" `cat ex5.gen.xml.Z | wc -c` "|" >> size.md 144 | echo "| CBOR | " `cat ex5.gen.cbor | wc -c ` "|" `cat ex5.gen.cbor.Z | wc -c` "|" >> size.md 145 | echo "| EXI | " `cat ex5.gen.exi | wc -c ` "|" `cat ex5.gen.exi.Z | wc -c` "|" >> size.md 146 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # senml-spec 2 | Specification for SenML 3 | ======= 4 | # draft-ietf-core-senml 5 | 6 | This is the working area for the [IETF CORE Working 7 | Group](https://trac.tools.ietf.org/wg/core/trac/wiki) draft of Media Types for Sensor Markup Language (SENML) 8 | 9 | * [Working Group Draft] (https://tools.ietf.org/html/draft-ietf-core-senml) 10 | 11 | ## Contributing 12 | 13 | Before submitting feedback, please familiarize yourself with our current issues 14 | list and review the [working group home page](http://datatracker.ietf.org/wg/core/documents/). If you're 15 | new to this, you may also want to read the [Tao of the 16 | IETF](https://www.ietf.org/tao.html). 17 | 18 | Be aware that all contributions to the specification fall under the "NOTE WELL" 19 | terms outlined below. 20 | 21 | 1. The best way to provide feedback (editorial or design) and ask questions is 22 | sending an e-mail to [our mailing 23 | list](https://www.ietf.org/mailman/listinfo/core). This will ensure that 24 | the entire Working Group sees your input in a timely fashion. 25 | 26 | 2. If you have **editorial** suggestions (i.e., those that do not change the 27 | meaning of the specification), you can either: 28 | 29 | a) Fork this repository and submit a pull request; this is the lowest 30 | friction way to get editorial changes in. 31 | 32 | b) Submit a new issue to Github, and mention that you believe it is editorial 33 | in the issue body. It is not necessary to notify the mailing list for 34 | editorial issues. 35 | 36 | c) Make comments on individual commits in Github. Note that this feedback is 37 | processed only with best effort by the editors, so it should only be used for 38 | quick editorial suggestions or questions. 39 | 40 | 3. For non-editorial (i.e., **design**) issues, you can also create an issue on 41 | Github. However, you **must notify the mailing list** when creating such issues, 42 | providing a link to the issue in the message body. 43 | 44 | Note that **github issues are not for substantial discussions**; the only 45 | appropriate place to discuss design issues is on the mailing list itself. 46 | 47 | 48 | ## Building the Draft 49 | 50 | A docker image can be created with 51 | 52 | ```sh 53 | docker build -t senml . 54 | ``` 55 | 56 | Then the docker images can be run to build the draft with 57 | ```sh 58 | docker run -v `pwd`:/senml senml 59 | ``` 60 | 61 | Another usefull command to get a shell in in the docker image is 62 | ```sh 63 | docker run -it -v `pwd`:/senml senml /usr/bin/tcsh 64 | ``` 65 | 66 | ## NOTE WELL 67 | 68 | Any submission to the [IETF](https://www.ietf.org/) intended by the Contributor 69 | for publication as all or part of an IETF Internet-Draft or RFC and any 70 | statement made within the context of an IETF activity is considered an "IETF 71 | Contribution". Such statements include oral statements in IETF sessions, as 72 | well as written and electronic communications made at any time or place, which 73 | are addressed to: 74 | 75 | * The IETF plenary session 76 | * The IESG, or any member thereof on behalf of the IESG 77 | * Any IETF mailing list, including the IETF list itself, any working group 78 | or design team list, or any other list functioning under IETF auspices 79 | * Any IETF working group or portion thereof 80 | * Any Birds of a Feather (BOF) session 81 | * The IAB or any member thereof on behalf of the IAB 82 | * The RFC Editor or the Internet-Drafts function 83 | * All IETF Contributions are subject to the rules of 84 | [RFC 5378](https://tools.ietf.org/html/rfc5378) and 85 | [RFC 3979](https://tools.ietf.org/html/rfc3979) 86 | (updated by [RFC 4879](https://tools.ietf.org/html/rfc4879)). 87 | 88 | Statements made outside of an IETF session, mailing list or other function, 89 | that are clearly not intended to be input to an IETF activity, group or 90 | function, are not IETF Contributions in the context of this notice. 91 | 92 | Please consult [RFC 5378](https://tools.ietf.org/html/rfc5378) and [RFC 93 | 3979](https://tools.ietf.org/html/rfc3979) for details. 94 | 95 | A participant in any IETF activity is deemed to accept all IETF rules of 96 | process, as documented in Best Current Practices RFCs and IESG Statements. 97 | 98 | A participant in any IETF activity acknowledges that written, audio and video 99 | records of meetings may be made and may be available to the public. 100 | -------------------------------------------------------------------------------- /TODO.md: -------------------------------------------------------------------------------- 1 | # TODO List 2 | 3 | ? make base values only allowed in first record 4 | 5 | ? make the base and other values mutuall exclusive 6 | 7 | ? define a "expanded" document as no base names and no releative (negative) times 8 | 9 | -------------------------------------------------------------------------------- /archive/draft-jennings-senml-00.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Network Working Group C. Jennings 5 | Internet-Draft Cisco 6 | Intended status: Experimental June 30, 2010 7 | Expires: January 1, 2011 8 | 9 | 10 | Media Types for Sensor Markup Language (SENML) 11 | draft-jennings-senml-00 12 | 13 | Abstract 14 | 15 | This specification defines media types for representing simple sensor 16 | measurements in JSON. A simple sensor, such as a temperature sensor, 17 | could use this media type in protocols such as HTTP to transport the 18 | values of a sensor. 19 | 20 | Status of this Memo 21 | 22 | This Internet-Draft is submitted in full conformance with the 23 | provisions of BCP 78 and BCP 79. 24 | 25 | Internet-Drafts are working documents of the Internet Engineering 26 | Task Force (IETF). Note that other groups may also distribute 27 | working documents as Internet-Drafts. The list of current Internet- 28 | Drafts is at http://datatracker.ietf.org/drafts/current/. 29 | 30 | Internet-Drafts are draft documents valid for a maximum of six months 31 | and may be updated, replaced, or obsoleted by other documents at any 32 | time. It is inappropriate to use Internet-Drafts as reference 33 | material or to cite them other than as "work in progress." 34 | 35 | This Internet-Draft will expire on January 1, 2011. 36 | 37 | Copyright Notice 38 | 39 | Copyright (c) 2010 IETF Trust and the persons identified as the 40 | document authors. All rights reserved. 41 | 42 | This document is subject to BCP 78 and the IETF Trust's Legal 43 | Provisions Relating to IETF Documents 44 | (http://trustee.ietf.org/license-info) in effect on the date of 45 | publication of this document. Please review these documents 46 | carefully, as they describe your rights and restrictions with respect 47 | to this document. Code Components extracted from this document must 48 | include Simplified BSD License text as described in Section 4.e of 49 | the Trust Legal Provisions and are provided without warranty as 50 | described in the Simplified BSD License. 51 | 52 | 53 | 54 | 55 | Jennings Expires January 1, 2011 [Page 1] 56 | 57 | Internet-Draft Sensor Markup June 2010 58 | 59 | 60 | Table of Contents 61 | 62 | 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 | 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 3 64 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 | 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 | 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 | 5.1. Simple Example . . . . . . . . . . . . . . . . . . . . . . 6 68 | 5.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 6 69 | 6. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 | 7.1. Units Registry . . . . . . . . . . . . . . . . . . . . . . 8 72 | 7.2. Media Type Registration . . . . . . . . . . . . . . . . . 11 73 | 7.2.1. senml+json Media Type Registration . . . . . . . . . . 11 74 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 | 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 76 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | Jennings Expires January 1, 2011 [Page 2] 112 | 113 | Internet-Draft Sensor Markup June 2010 114 | 115 | 116 | 1. Overview 117 | 118 | Connecting sensors to the internet is not new, and there have been 119 | many protocols designed to facilitate it. This specification defines 120 | new media types for carrying simple sensor information in a protocol 121 | such as HTTP or CoAP[I-D.shelby-core-coap]. This format was designed 122 | so that processors with very limited capabilities could easily encode 123 | a sensor reading into the media type, while at the same time a server 124 | parsing the data could relatively efficiently collect a large number 125 | of sensor readings. There are many types of more complex 126 | measurements and readings that this media type would not be suitable 127 | for. A decision was made not to carry most of the meta data about 128 | the sensor in this media type to help reduce the size of the data and 129 | improve efficiency in decoding. 130 | 131 | JSON[RFC4627] was selected as a basis for the encoding as it 132 | represents a widely understood way of encoding data that is popular 133 | in current web based APIs and represents reasonable trade-offs 134 | between extensibility, simplicity, and efficiency. 135 | 136 | The data is structured as a single JSON object (with attributes) that 137 | contains an array of measurements. Each measurement is a JSON object 138 | that has attributes such as a unique identifier for the sensor, the 139 | time the measurement was made, and the current value. For example, 140 | the following shows a measurement from a temperature gauge in JSON 141 | syntax. 142 | 143 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5, "u":"C" }]} 144 | 145 | In the example above, the array in the object has a single 146 | measurement for a sensor named "0017f202a5c5-Temp" with a temperature 147 | of 23.5 degrees Celsius. 148 | 149 | 150 | 2. Requirements and Design Goals 151 | 152 | The design goal is to be able to send simple sensor measurements in 153 | small packets on mesh networks from large numbers of constrained 154 | devices. Keeping the total size under 80 bytes makes this easy to 155 | use on a wireless mesh network. It is always difficult to define 156 | what small code is, but there is a desire to be able to implement 157 | this in roughly 1 KB of flash on a 8 bit microprocessor. Experience 158 | with Google power meter and other large scale deployments has 159 | indicated strongly that the solution needs to support allowing 160 | multiple measurements to be batched into a single HTTP request. This 161 | "batch" upload capability allows the server side to efficiently 162 | support a large number of devices. The multiple measurements could 163 | be from multiple related sensors or from the same sensor but at 164 | 165 | 166 | 167 | Jennings Expires January 1, 2011 [Page 3] 168 | 169 | Internet-Draft Sensor Markup June 2010 170 | 171 | 172 | different times. 173 | 174 | 175 | 3. Terminology 176 | 177 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 | document are to be interpreted as described in RFC 2119 [RFC2119]. 180 | 181 | 182 | 4. Semantics 183 | 184 | Each media type caries a single JSON object that represents a set of 185 | measurements. This object contains several optional attributes 186 | described below, followed by an mandatory array of one or more 187 | measurements. 188 | 189 | bn: This is a base name string that is perpended to the names found 190 | in the measurements. This attribute is optional. 191 | bt: A base time that is added to the time found in a measurement. 192 | This attribute is optional. 193 | ver: Version number of media type format. This attribute is 194 | optional positive integer and defaults to 1 if not present. 195 | m: Array of measurements. Required, and there must be at least one 196 | measurement in the array. 197 | 198 | Each measurement contains several attributes, some of which are 199 | optional and some of which are mandatory. 200 | 201 | n: Name of sensor. When appended to the "bn" attribute, this must 202 | result in a globally unique identifier for the sensor. 203 | u: Units for the sensor value. Optional. Acceptable values are 204 | specified in Section 7.1 205 | v: Value of sensor. Optional if an s value is present, otherwise 206 | required. 207 | s: Integrated sum of the sensor values over time. Optional. This 208 | attribute is in the units specified in the u value multiplied by 209 | seconds. 210 | t: Time when measurement was made. Optional. 211 | 212 | Open Issue: Ongoing conversations around Privacy, Accuracy/ 213 | Confidence, Valid time, and tags. 214 | 215 | The bt, v, s, and t attributes are floating point numbers. Systems 216 | receiving measurements MUST be able to process these as IEEE double- 217 | precision floating-point numbers [IEEE.754.1985]. The number of 218 | significant digits in any measurement is not relevant, so a reading 219 | of 1.1 has exactly the same semantic meaning as 1.10. If the value 220 | 221 | 222 | 223 | Jennings Expires January 1, 2011 [Page 4] 224 | 225 | Internet-Draft Sensor Markup June 2010 226 | 227 | 228 | has an exponent, the "e" MUST be in lower case. The mantissa SHOULD 229 | be less than 19 characters long and the exponent SHOULD be less than 230 | 5 characters long. 231 | 232 | Systems reading one of the JSON objects MUST check for the ver 233 | attribute. If this value is a version number larger than the version 234 | which system understands, the system SHOULD NOT use this JSON object. 235 | This allows the version number to indicate that the object contains 236 | mandatory to understand attributes. New version numbers can only be 237 | defined in RFC which update this specification or it successors. 238 | 239 | The n value is concatenated to the bn value to get the name of the 240 | sensor. The resulting name needs to uniquely identity and 241 | differentiate the sensor from all others. If the name contains 48 242 | bits of random material, or 48 bits of material that is procedurally 243 | assigned in a unique way, it is considered to be good enough 244 | uniqueness. One way to achieve this uniqueness is to include a 245 | EUI-48 identifier (A MAC address) or some other 48 bit identifier 246 | that is guaranteed uniqueness (such as a 1-wire address) that is 247 | assigned to the device. UUIDs [RFC4122] are another way to generate 248 | a unique name. 249 | 250 | The resulting concatenated name MUST consist only of characters out 251 | of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 252 | and it MUST start with a character out of the set "A" to "Z", "a" to 253 | "z", or "0" to "9". This restricted character set was chosen so that 254 | these names can be directly used as in other types of URI including 255 | segments of an HTTP path with no special encoding. 256 | [I-D.ietf-6man-text-addr-representation] contains advice on encoding 257 | an IPv6 address in a name. 258 | 259 | If either the bt or t value is missing, the missing attribute is 260 | considered to have a value of zero. The bt and t values are added 261 | together to get the time of measurement. A time of zero is 262 | considered to mean that the sensor does not know the time and the 263 | measurement was made roughly "now". A negative value is used to 264 | indicate seconds in the past from roughly "now". A positive value is 265 | used to indicate the number of seconds since the start of the year 266 | 1970 in UTC excluding leap seconds. 267 | 268 | Open Issue: Should this be atomic seconds instead of "Unix" style 269 | time? 270 | 271 | Open Issue: What about NaN and Infinity in the floating point 272 | numbers? 273 | 274 | Open Issue: If bt & t where floating point, this would allow sub 275 | second precision. What time precision is needed? 276 | 277 | 278 | 279 | Jennings Expires January 1, 2011 [Page 5] 280 | 281 | Internet-Draft Sensor Markup June 2010 282 | 283 | 284 | Open Issue: What to do about Y2K38 problem? This is coming up very 285 | soon and will no doubt impact devices using this. Would it be better 286 | to use an epoch of 2010 instead of 1970? There does not seem to be 287 | any need to represent values before 2010. Would using a floating 288 | point double work better? 289 | 290 | 291 | 5. Syntax 292 | 293 | All of the data is UTF-8, but since this is for machine to machine 294 | communications on constrained systems, only characters with code 295 | points between U+0001 and U+007F are allowed. 296 | 297 | The contents MUST consist of exactly one JSON object as specified by 298 | [RFC4627]. This object MAY contain a "bn" attribute with a value of 299 | type string. This object MAY contain a "bt" attribute with a value 300 | of type number. The object MAY contain other attribute value pairs. 301 | The object MUST contain exactly one "m" attribute with a value of 302 | type array. The array MUST have one or more measurement objects. 303 | 304 | Inside each measurement object the "n" and "u" attribute are of type 305 | string and the "t", "v", and "s" attributes are of type number. 306 | 307 | 5.1. Simple Example 308 | 309 | The following shows a temperature reading taken approximately "now": 310 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5 }]} 311 | 312 | 5.2. Complex Example 313 | 314 | The following example show the voltage at Tue Jun 8 18:01:16 UTC 2010 315 | along with the current at that time and at each second for the 316 | previous 5 seconds. 317 | {"m":[ 318 | { "n": "voltage", "u": "V", 319 | "v": 120.1, "anExtension": 0.0 }, 320 | { "n": "current", "t": -5, "v": 1.2 }, 321 | { "n": "current", "t": -4, "v": 1.30 }, 322 | { "n": "current", "t": -3, "v": 0.14e1 }, 323 | { "n": "current", "t": -2, "v": 1.5 }, 324 | { "n": "current", "t": -1, "v": 1.6 }, 325 | { "n": "current", "t": 0 "v": 1.7 }, 326 | ] 327 | "bn": "0017f202a5c5", 328 | "bt": 1276020076, 329 | "someExtensions": "a value", 330 | } 331 | 332 | 333 | 334 | 335 | Jennings Expires January 1, 2011 [Page 6] 336 | 337 | Internet-Draft Sensor Markup June 2010 338 | 339 | 340 | 6. Usage Considerations 341 | 342 | The measurements support sending both the current value of a sensor 343 | as well as the an integrated sum. For many types of measurements, 344 | the sum is more useful than the current value. For example, an 345 | electrical meter that measures the energy a given computer uses will 346 | typically want to measure the cumulative amount of energy used. This 347 | is less prone to error than reporting the power each second and 348 | trying to have something on the server side sum together all the 349 | power measurements. If the network between the sensor and the meter 350 | goes down over some period of time, when it comes back up, the 351 | cumulative sum helps reflect what happened while the network was 352 | down. A meter like this would typically report a measurement with 353 | the units set to watts, but it would put the sum of energy used in 354 | the "s" attribute of the measurement. It might optionally include 355 | the current power in the "v" attribute. 356 | 357 | While the benefit of using the integrated sum is fairly clear for 358 | measurements like power and energy, it is less obvious for something 359 | like voltage. Reporting the sum of the temperatures makes it easy to 360 | compute averages even when the individual temperature values are not 361 | reported frequently enough to compute accurate averages. 362 | Implementors are encouraged to report the cumulative sum as well as 363 | the raw value of a given sensor. 364 | 365 | Applications that use the cumulative sum values need to understand 366 | they are very loosely defined by this specification, and depending on 367 | the particular sensor implementation may behave in unexpected ways. 368 | Applications should be able to deal with the following issues: 369 | 370 | 1. Many sensors will allow the cumulative sums to "wrap" back to 371 | zero after the value gets sufficiently large. 372 | 2. Some sensors will reset the cumulative sum back to zero when the 373 | device is reset, loses power, or is replaced with a different 374 | sensor. 375 | 3. Applications cannot make assumptions about when the device 376 | started accumulating values into the sum. 377 | 378 | Typically applications can make some assumptions about specific 379 | sensors that will allow them to deal with these problems. A common 380 | assumption is that for sensors whose measurement values are always 381 | positive, the sum should never get smaller; so if the sum does get 382 | smaller, the application will know that one of the situations listed 383 | above has happened. 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | Jennings Expires January 1, 2011 [Page 7] 392 | 393 | Internet-Draft Sensor Markup June 2010 394 | 395 | 396 | 7. IANA Considerations 397 | 398 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 399 | with the RFC number of this specification. 400 | 401 | 7.1. Units Registry 402 | 403 | IANA will create a registry of unit symbols. The primary purpose of 404 | this registry is to make sure that symbols uniquely map to give type 405 | of measurement. 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | Jennings Expires January 1, 2011 [Page 8] 448 | 449 | Internet-Draft Sensor Markup June 2010 450 | 451 | 452 | +--------+----------------------------------------------+-----------+ 453 | | Symbol | Description | Reference | 454 | +--------+----------------------------------------------+-----------+ 455 | | m | meter | RFC-AAAA | 456 | | kg | kilogram | RFC-AAAA | 457 | | s | second | RFC-AAAA | 458 | | A | ampere | RFC-AAAA | 459 | | K | kelvin | RFC-AAAA | 460 | | cd | candela | RFC-AAAA | 461 | | mol | mole | RFC-AAAA | 462 | | Hz | hertz | RFC-AAAA | 463 | | rad | radian | RFC-AAAA | 464 | | sr | steradian | RFC-AAAA | 465 | | N | newton | RFC-AAAA | 466 | | Pa | pascal | RFC-AAAA | 467 | | J | joule | RFC-AAAA | 468 | | W | watt | RFC-AAAA | 469 | | C | coulomb | RFC-AAAA | 470 | | V | volt | RFC-AAAA | 471 | | F | farad | RFC-AAAA | 472 | | Ohm | ohm | RFC-AAAA | 473 | | S | siemens | RFC-AAAA | 474 | | Wb | weber | RFC-AAAA | 475 | | T | tesla | RFC-AAAA | 476 | | H | henry | RFC-AAAA | 477 | | C | degrees Celsius | RFC-AAAA | 478 | | lm | lumen | RFC-AAAA | 479 | | lx | lux | RFC-AAAA | 480 | | Bq | becquerel | RFC-AAAA | 481 | | Gy | gray | RFC-AAAA | 482 | | Sv | sievert | RFC-AAAA | 483 | | kat | katal | RFC-AAAA | 484 | | pH | pH acidity | RFC-AAAA | 485 | | % | Value of a switch. A value of 0.0 indicates | RFC-AAAA | 486 | | | the switch is off while 100.0 indicates on. | | 487 | | count | counter value | RFC-AAAA | 488 | | %RH | Relative Humidity | RFC-AAAA | 489 | | m2 | area | RFC-AAAA | 490 | | l | volume in liters | RFC-AAAA | 491 | | m/s | velocity | RFC-AAAA | 492 | | m/s2 | acceleration | RFC-AAAA | 493 | | l/s | flow rate in liters per second | RFC-AAAA | 494 | | W/m2 | irradiance | RFC-AAAA | 495 | | cd/m2 | luminance | RFC-AAAA | 496 | | Bspl | bel sound pressure level | RFC-AAAA | 497 | | b/s | bits per second | RFC-AAAA | 498 | 499 | 500 | 501 | 502 | 503 | Jennings Expires January 1, 2011 [Page 9] 504 | 505 | Internet-Draft Sensor Markup June 2010 506 | 507 | 508 | | lat | degrees latitude. Assumed to be in WGS84 | RFC-AAAA | 509 | | | unless another reference frame is known for | | 510 | | | the sensor. | | 511 | | lon | degrees longitude. Assumed to be in WGS84 | RFC-AAAA | 512 | | | unless another reference frame is known for | | 513 | | | the sensor. | | 514 | +--------+----------------------------------------------+-----------+ 515 | 516 | New entries can be added to the registration by either Expert Review 517 | or IESG Approval as defined in [RFC5226]. Experts should exercise 518 | their own good judgement but need to consider the following 519 | guidelines: 520 | 521 | 1. There needs to be a real and compelling use for any new unit to 522 | be added. 523 | 2. Units should define the semantic information and be chosen 524 | carefully. Implementors need to remember that the same word may 525 | be used in different real-life contexts. For example, degrees 526 | when measuring latitude have no semantic relation to degrees 527 | when measuring temperature; thus two different units are needed. 528 | 3. These measurements are produced by computers for consumption by 529 | computers. The principle is that conversion has to be easily be 530 | done when both reading and writing the media type. The value of 531 | a single canonical representation outweighs the convenience of 532 | easy human representations or loss of precision in a conversion. 533 | 4. Use of SI prefixes such as "k" before the unit is not allowed. 534 | Instead one can represent the value using scientific notation 535 | such a 1.2e3. 536 | 5. For a given type of measurement, there will only be one unit 537 | type defined. So for length, meters are defined and other 538 | lengths such as mile, foot, light year are not allowed. For 539 | most cases, the SI unit is preferred. 540 | 6. Symbol names that could be easily confused with existing common 541 | units or units combined with prefixes should be avoided. For 542 | example, selecting a unit name of "mph" to indicate something 543 | that had nothing to do with velocity would be a bad choice, as 544 | "mph" is commonly used to mean mile per hour. 545 | 7. The following should not be used because the are common SI 546 | prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, n, p, f, 547 | a, z, y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 548 | 8. The following units should not be used as they are commonly used 549 | to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 550 | Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 551 | BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 552 | 9. The unit names are case sensitive and the correct case needs to 553 | be used, but symbols that differ only in case should not be 554 | allocated. 555 | 556 | 557 | 558 | 559 | Jennings Expires January 1, 2011 [Page 10] 560 | 561 | Internet-Draft Sensor Markup June 2010 562 | 563 | 564 | 10. A number after a unit typically indicates the previous unit 565 | raised to that power, and the / indicates that the units that 566 | follow are the reciprocal. A unit should have only one / in the 567 | name. 568 | 569 | 7.2. Media Type Registration 570 | 571 | The following registrations are done following the procedure 572 | specified in [RFC4288] and [RFC3023]. 573 | 574 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 575 | with the RFC number of this specification. 576 | 577 | 7.2.1. senml+json Media Type Registration 578 | 579 | To: ietf-types@iana.org 580 | 581 | Subject: Registration of media type application/senml+json 582 | 583 | Type name: application 584 | 585 | Subtype name: senml+json 586 | 587 | Required parameters: none 588 | 589 | Optional parameters: none 590 | 591 | Encoding considerations: Must be encoded as binary. See additional 592 | constraints in [RFC4627]. 593 | 594 | Security considerations: Sensor data can contain a wide range of 595 | information ranging from information that is very public, such the 596 | outside temperature in a given city, to very private information that 597 | requires integrity and confidentiality protection, such as patient 598 | health information. This format does not provide any security and 599 | instead relies on the transport protocol that carries it to provide 600 | security. Given applications need to look at the overall context of 601 | how this media type will be used to decide if the security is 602 | adequate. 603 | 604 | Interoperability considerations: JSON allows new fields to be 605 | defined and applications should be able to ignore fields they do not 606 | understand to ensure forward compatibility with extensions to this 607 | specification. 608 | 609 | Published specification: RFC-AAAA 610 | 611 | Applications that use this media type: N/A 612 | 613 | 614 | 615 | Jennings Expires January 1, 2011 [Page 11] 616 | 617 | Internet-Draft Sensor Markup June 2010 618 | 619 | 620 | Additional information: 621 | 622 | Magic number(s): none 623 | 624 | File extension(s): senml 625 | 626 | Macintosh file type code(s): none 627 | 628 | Person & email address to contact for further information: Cullen 629 | Jennings 630 | 631 | Intended usage: COMMON 632 | 633 | Restrictions on usage: None 634 | 635 | Author: Cullen Jennings 636 | 637 | Change controller: Cullen Jennings 638 | 639 | 640 | 8. Security Considerations 641 | 642 | Sensor data can range from information with almost no security 643 | considerations, such as the current temperature in a given city, to 644 | highly sensitive medical or location data. This specification 645 | provides no security protection for the data but is meant to be used 646 | inside another container or transport protocol such as S/MIME or HTTP 647 | with TLS that can provide integrity, confidentiality, and 648 | authentication information about the source of the data. 649 | 650 | Further discussion of security proprieties can be found in 651 | Section 7.2. 652 | 653 | 654 | 9. Acknowledgement 655 | 656 | I would like to thank Lisa Dusseault, Joe Hildebrand, and Lyndsay 657 | Campbell for the review comments. 658 | 659 | 660 | 10. References 661 | 662 | 10.1. Normative References 663 | 664 | [RFC4627] Crockford, D., "The application/json Media Type for 665 | JavaScript Object Notation (JSON)", RFC 4627, July 2006. 666 | 667 | [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 668 | 669 | 670 | 671 | Jennings Expires January 1, 2011 [Page 12] 672 | 673 | Internet-Draft Sensor Markup June 2010 674 | 675 | 676 | Types", RFC 3023, January 2001. 677 | 678 | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 679 | Registration Procedures", BCP 13, RFC 4288, December 2005. 680 | 681 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 | Requirement Levels", BCP 14, RFC 2119, March 1997. 683 | 684 | [IEEE.754.1985] 685 | Institute of Electrical and Electronics Engineers, 686 | "Standard for Binary Floating-Point Arithmetic", 687 | IEEE Standard 754, August 1985. 688 | 689 | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 690 | IANA Considerations Section in RFCs", BCP 26, RFC 5226, 691 | May 2008. 692 | 693 | 10.2. Informative References 694 | 695 | [I-D.shelby-core-coap] 696 | Shelby, Z., Frank, B., and D. Sturek, "Constrained 697 | Application Protocol (CoAP)", draft-shelby-core-coap-01 698 | (work in progress), May 2010. 699 | 700 | [I-D.ietf-6man-text-addr-representation] 701 | Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 702 | Address Text Representation", 703 | draft-ietf-6man-text-addr-representation-07 (work in 704 | progress), February 2010. 705 | 706 | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 707 | Unique IDentifier (UUID) URN Namespace", RFC 4122, 708 | July 2005. 709 | 710 | 711 | Author's Address 712 | 713 | Cullen Jennings 714 | Cisco 715 | 170 West Tasman Drive 716 | San Jose, CA 95134 717 | USA 718 | 719 | Phone: +1 408 421-9990 720 | Email: fluffy@cisco.com 721 | 722 | 723 | 724 | 725 | 726 | 727 | Jennings Expires January 1, 2011 [Page 13] 728 | 729 | -------------------------------------------------------------------------------- /archive/draft-jennings-senml-01.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Network Working Group C. Jennings 5 | Internet-Draft Cisco 6 | Intended status: Experimental July 9, 2010 7 | Expires: January 10, 2011 8 | 9 | 10 | Media Type for Sensor Markup Language (SENML) 11 | draft-jennings-senml-01 12 | 13 | Abstract 14 | 15 | This specification defines media types for representing simple sensor 16 | measurements in JSON. A simple sensor, such as a temperature sensor, 17 | could use this media type in protocols such as HTTP to transport the 18 | values of a sensor. 19 | 20 | Status of this Memo 21 | 22 | This Internet-Draft is submitted in full conformance with the 23 | provisions of BCP 78 and BCP 79. 24 | 25 | Internet-Drafts are working documents of the Internet Engineering 26 | Task Force (IETF). Note that other groups may also distribute 27 | working documents as Internet-Drafts. The list of current Internet- 28 | Drafts is at http://datatracker.ietf.org/drafts/current/. 29 | 30 | Internet-Drafts are draft documents valid for a maximum of six months 31 | and may be updated, replaced, or obsoleted by other documents at any 32 | time. It is inappropriate to use Internet-Drafts as reference 33 | material or to cite them other than as "work in progress." 34 | 35 | This Internet-Draft will expire on January 10, 2011. 36 | 37 | Copyright Notice 38 | 39 | Copyright (c) 2010 IETF Trust and the persons identified as the 40 | document authors. All rights reserved. 41 | 42 | This document is subject to BCP 78 and the IETF Trust's Legal 43 | Provisions Relating to IETF Documents 44 | (http://trustee.ietf.org/license-info) in effect on the date of 45 | publication of this document. Please review these documents 46 | carefully, as they describe your rights and restrictions with respect 47 | to this document. Code Components extracted from this document must 48 | include Simplified BSD License text as described in Section 4.e of 49 | the Trust Legal Provisions and are provided without warranty as 50 | described in the Simplified BSD License. 51 | 52 | 53 | 54 | 55 | Jennings Expires January 10, 2011 [Page 1] 56 | 57 | Internet-Draft Sensor Markup July 2010 58 | 59 | 60 | Table of Contents 61 | 62 | 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 | 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 3 64 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 | 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 | 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 | 5.1. Simple Example . . . . . . . . . . . . . . . . . . . . . . 6 68 | 5.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 6 69 | 6. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 | 7.1. Units Registry . . . . . . . . . . . . . . . . . . . . . . 8 72 | 7.2. Media Type Registration . . . . . . . . . . . . . . . . . 11 73 | 7.2.1. senml+json Media Type Registration . . . . . . . . . . 11 74 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 | 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 76 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | Jennings Expires January 10, 2011 [Page 2] 112 | 113 | Internet-Draft Sensor Markup July 2010 114 | 115 | 116 | 1. Overview 117 | 118 | Connecting sensors to the internet is not new, and there have been 119 | many protocols designed to facilitate it. This specification defines 120 | new media types for carrying simple sensor information in a protocol 121 | such as HTTP or CoAP[I-D.shelby-core-coap]. This format was designed 122 | so that processors with very limited capabilities could easily encode 123 | a sensor reading into the media type, while at the same time a server 124 | parsing the data could relatively efficiently collect a large number 125 | of sensor readings. There are many types of more complex 126 | measurements and readings that this media type would not be suitable 127 | for. A decision was made not to carry most of the meta data about 128 | the sensor in this media type to help reduce the size of the data and 129 | improve efficiency in decoding. 130 | 131 | JSON[RFC4627] was selected as a basis for the encoding as it 132 | represents a widely understood way of encoding data that is popular 133 | in current web based APIs and represents reasonable trade-offs 134 | between extensibility, simplicity, and efficiency. 135 | 136 | The data is structured as a single JSON object (with attributes) that 137 | contains an array of measurements. Each measurement is a JSON object 138 | that has attributes such as a unique identifier for the sensor, the 139 | time the measurement was made, and the current value. For example, 140 | the following shows a measurement from a temperature gauge in JSON 141 | syntax. 142 | 143 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5, "u":"degC" }]} 144 | 145 | In the example above, the array in the object has a single 146 | measurement for a sensor named "0017f202a5c5-Temp" with a temperature 147 | of 23.5 degrees Celsius. 148 | 149 | 150 | 2. Requirements and Design Goals 151 | 152 | The design goal is to be able to send simple sensor measurements in 153 | small packets on mesh networks from large numbers of constrained 154 | devices. Keeping the total size under 80 bytes makes this easy to 155 | use on a wireless mesh network. It is always difficult to define 156 | what small code is, but there is a desire to be able to implement 157 | this in roughly 1 KB of flash on a 8 bit microprocessor. Experience 158 | with Google power meter and other large scale deployments has 159 | indicated strongly that the solution needs to support allowing 160 | multiple measurements to be batched into a single HTTP request. This 161 | "batch" upload capability allows the server side to efficiently 162 | support a large number of devices. The multiple measurements could 163 | be from multiple related sensors or from the same sensor but at 164 | 165 | 166 | 167 | Jennings Expires January 10, 2011 [Page 3] 168 | 169 | Internet-Draft Sensor Markup July 2010 170 | 171 | 172 | different times. 173 | 174 | 175 | 3. Terminology 176 | 177 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 | document are to be interpreted as described in RFC 2119 [RFC2119]. 180 | 181 | 182 | 4. Semantics 183 | 184 | Each media type caries a single JSON object that represents a set of 185 | measurements. This object contains several optional attributes 186 | described below, followed by an mandatory array of one or more 187 | measurements. 188 | 189 | bn: This is a base name string that is perpended to the names found 190 | in the measurements. This attribute is optional. 191 | bt: A base time that is added to the time found in a measurement. 192 | This attribute is optional. 193 | ver: Version number of media type format. This attribute is 194 | optional positive integer and defaults to 1 if not present. 195 | m: Array of measurements. Required, and there must be at least one 196 | measurement in the array. 197 | 198 | Each measurement contains several attributes, some of which are 199 | optional and some of which are mandatory. 200 | 201 | n: Name of sensor. When appended to the "bn" attribute, this must 202 | result in a globally unique identifier for the sensor. 203 | u: Units for the sensor value. Optional. Acceptable values are 204 | specified in Section 7.1 205 | v: Value of sensor. Optional if an s value is present, otherwise 206 | required. 207 | s: Integrated sum of the sensor values over time. Optional. This 208 | attribute is in the units specified in the u value multiplied by 209 | seconds. 210 | t: Time when measurement was made. Optional. 211 | 212 | Open Issue: Ongoing conversations around Privacy, Accuracy/ 213 | Confidence, Valid time, and tags. 214 | 215 | The bt, v, s, and t attributes are floating point numbers. Systems 216 | receiving measurements MUST be able to process the range of numbers 217 | that are representable as an IEEE double-precision floating-point 218 | numbers [IEEE.754.1985]. The number of significant digits in any 219 | measurement is not relevant, so a reading of 1.1 has exactly the same 220 | 221 | 222 | 223 | Jennings Expires January 10, 2011 [Page 4] 224 | 225 | Internet-Draft Sensor Markup July 2010 226 | 227 | 228 | semantic meaning as 1.10. If the value has an exponent, the "e" MUST 229 | be in lower case. The mantissa SHOULD be less than 19 characters 230 | long and the exponent SHOULD be less than 5 characters long. 231 | 232 | Systems reading one of the JSON objects MUST check for the ver 233 | attribute. If this value is a version number larger than the version 234 | which system understands, the system SHOULD NOT use this JSON object. 235 | This allows the version number to indicate that the object contains 236 | mandatory to understand attributes. New version numbers can only be 237 | defined in RFC which update this specification or it successors. 238 | 239 | The n value is concatenated to the bn value to get the name of the 240 | sensor. The resulting name needs to uniquely identity and 241 | differentiate the sensor from all others. If the name contains 48 242 | bits of random material, or 48 bits of material that is procedurally 243 | assigned in a unique way, it is considered to be good enough 244 | uniqueness. One way to achieve this uniqueness is to include a 245 | EUI-48 identifier (A MAC address) or some other 48 bit identifier 246 | that is guaranteed uniqueness (such as a 1-wire address) that is 247 | assigned to the device. UUIDs [RFC4122] are another way to generate 248 | a unique name. 249 | 250 | The resulting concatenated name MUST consist only of characters out 251 | of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 252 | and it MUST start with a character out of the set "A" to "Z", "a" to 253 | "z", or "0" to "9". This restricted character set was chosen so that 254 | these names can be directly used as in other types of URI including 255 | segments of an HTTP path with no special encoding. 256 | [I-D.ietf-6man-text-addr-representation] contains advice on encoding 257 | an IPv6 address in a name. 258 | 259 | If either the bt or t value is missing, the missing attribute is 260 | considered to have a value of zero. The bt and t values are added 261 | together to get the time of measurement. A time of zero is 262 | considered to mean that the sensor does not know the time and the 263 | measurement was made roughly "now". A negative value is used to 264 | indicate seconds in the past from roughly "now". A positive value is 265 | used to indicate the number of seconds since the start of the year 266 | 1970 in UTC excluding leap seconds. 267 | 268 | Open Issue: Should this be atomic seconds instead of "Unix" style 269 | time? 270 | 271 | Open Issue: What about NaN and Infinity in the floating point 272 | numbers? 273 | 274 | Open Issue: If bt & t where floating point, this would allow sub 275 | second precision. What time precision is needed? 276 | 277 | 278 | 279 | Jennings Expires January 10, 2011 [Page 5] 280 | 281 | Internet-Draft Sensor Markup July 2010 282 | 283 | 284 | Open Issue: What to do about Y2K38 problem that comes form 285 | representing time in this way? This is coming up very soon and will 286 | no doubt impact devices using this. Would it be better to use an 287 | epoch of 2010 instead of 1970? There does not seem to be any need to 288 | represent values before 2010. Would using a floating point double 289 | work better? 290 | 291 | 292 | 5. Syntax 293 | 294 | All of the data is UTF-8, but since this is for machine to machine 295 | communications on constrained systems, only characters with code 296 | points between U+0001 and U+007F are allowed. 297 | 298 | The contents MUST consist of exactly one JSON object as specified by 299 | [RFC4627]. This object MAY contain a "bn" attribute with a value of 300 | type string. This object MAY contain a "bt" attribute with a value 301 | of type number. The object MAY contain other attribute value pairs. 302 | The object MUST contain exactly one "m" attribute with a value of 303 | type array. The array MUST have one or more measurement objects. 304 | 305 | Inside each measurement object the "n" and "u" attribute are of type 306 | string and the "t", "v", and "s" attributes are of type number. 307 | 308 | 5.1. Simple Example 309 | 310 | The following shows a temperature reading taken approximately "now": 311 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5 }]} 312 | 313 | 5.2. Complex Example 314 | 315 | The following example show the voltage at Tue Jun 8 18:01:16 UTC 2010 316 | along with the current at that time and at each second for the 317 | previous 5 seconds. 318 | {"m":[ 319 | { "n": "voltage", "u": "V", 320 | "v": 120.1, "anExtension": 0.0 }, 321 | { "n": "current", "t": -5, "v": 1.2 }, 322 | { "n": "current", "t": -4, "v": 1.30 }, 323 | { "n": "current", "t": -3, "v": 0.14e1 }, 324 | { "n": "current", "t": -2, "v": 1.5 }, 325 | { "n": "current", "t": -1, "v": 1.6 }, 326 | { "n": "current", "t": 0 "v": 1.7 }, 327 | ] 328 | "bn": "0017f202a5c5", 329 | "bt": 1276020076, 330 | "someExtensions": "a value", 331 | } 332 | 333 | 334 | 335 | Jennings Expires January 10, 2011 [Page 6] 336 | 337 | Internet-Draft Sensor Markup July 2010 338 | 339 | 340 | 6. Usage Considerations 341 | 342 | The measurements support sending both the current value of a sensor 343 | as well as the an integrated sum. For many types of measurements, 344 | the sum is more useful than the current value. For example, an 345 | electrical meter that measures the energy a given computer uses will 346 | typically want to measure the cumulative amount of energy used. This 347 | is less prone to error than reporting the power each second and 348 | trying to have something on the server side sum together all the 349 | power measurements. If the network between the sensor and the meter 350 | goes down over some period of time, when it comes back up, the 351 | cumulative sum helps reflect what happened while the network was 352 | down. A meter like this would typically report a measurement with 353 | the units set to watts, but it would put the sum of energy used in 354 | the "s" attribute of the measurement. It might optionally include 355 | the current power in the "v" attribute. 356 | 357 | While the benefit of using the integrated sum is fairly clear for 358 | measurements like power and energy, it is less obvious for something 359 | like voltage. Reporting the sum of the temperatures makes it easy to 360 | compute averages even when the individual temperature values are not 361 | reported frequently enough to compute accurate averages. 362 | Implementors are encouraged to report the cumulative sum as well as 363 | the raw value of a given sensor. 364 | 365 | Applications that use the cumulative sum values need to understand 366 | they are very loosely defined by this specification, and depending on 367 | the particular sensor implementation may behave in unexpected ways. 368 | Applications should be able to deal with the following issues: 369 | 370 | 1. Many sensors will allow the cumulative sums to "wrap" back to 371 | zero after the value gets sufficiently large. 372 | 2. Some sensors will reset the cumulative sum back to zero when the 373 | device is reset, loses power, or is replaced with a different 374 | sensor. 375 | 3. Applications cannot make assumptions about when the device 376 | started accumulating values into the sum. 377 | 378 | Typically applications can make some assumptions about specific 379 | sensors that will allow them to deal with these problems. A common 380 | assumption is that for sensors whose measurement values are always 381 | positive, the sum should never get smaller; so if the sum does get 382 | smaller, the application will know that one of the situations listed 383 | above has happened. 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | Jennings Expires January 10, 2011 [Page 7] 392 | 393 | Internet-Draft Sensor Markup July 2010 394 | 395 | 396 | 7. IANA Considerations 397 | 398 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 399 | with the RFC number of this specification. 400 | 401 | 7.1. Units Registry 402 | 403 | IANA will create a registry of unit symbols. The primary purpose of 404 | this registry is to make sure that symbols uniquely map to give type 405 | of measurement. Definitions for many of these units can be found in 406 | [NIST822] and [BIPM]. 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | Jennings Expires January 10, 2011 [Page 8] 448 | 449 | Internet-Draft Sensor Markup July 2010 450 | 451 | 452 | +--------+----------------------------------------------+-----------+ 453 | | Symbol | Description | Reference | 454 | +--------+----------------------------------------------+-----------+ 455 | | m | meter | RFC-AAAA | 456 | | kg | kilogram | RFC-AAAA | 457 | | s | second | RFC-AAAA | 458 | | A | ampere | RFC-AAAA | 459 | | K | kelvin | RFC-AAAA | 460 | | cd | candela | RFC-AAAA | 461 | | mol | mole | RFC-AAAA | 462 | | Hz | hertz | RFC-AAAA | 463 | | rad | radian | RFC-AAAA | 464 | | sr | steradian | RFC-AAAA | 465 | | N | newton | RFC-AAAA | 466 | | Pa | pascal | RFC-AAAA | 467 | | J | joule | RFC-AAAA | 468 | | W | watt | RFC-AAAA | 469 | | C | coulomb | RFC-AAAA | 470 | | V | volt | RFC-AAAA | 471 | | F | farad | RFC-AAAA | 472 | | Ohm | ohm | RFC-AAAA | 473 | | S | siemens | RFC-AAAA | 474 | | Wb | weber | RFC-AAAA | 475 | | T | tesla | RFC-AAAA | 476 | | H | henry | RFC-AAAA | 477 | | degC | degrees Celsius | RFC-AAAA | 478 | | lm | lumen | RFC-AAAA | 479 | | lx | lux | RFC-AAAA | 480 | | Bq | becquerel | RFC-AAAA | 481 | | Gy | gray | RFC-AAAA | 482 | | Sv | sievert | RFC-AAAA | 483 | | kat | katal | RFC-AAAA | 484 | | pH | pH acidity | RFC-AAAA | 485 | | % | Value of a switch. A value of 0.0 indicates | RFC-AAAA | 486 | | | the switch is off while 100.0 indicates on. | | 487 | | count | counter value | RFC-AAAA | 488 | | %RH | Relative Humidity | RFC-AAAA | 489 | | m2 | area | RFC-AAAA | 490 | | l | volume in liters | RFC-AAAA | 491 | | m/s | velocity | RFC-AAAA | 492 | | m/s2 | acceleration | RFC-AAAA | 493 | | l/s | flow rate in liters per second | RFC-AAAA | 494 | | W/m2 | irradiance | RFC-AAAA | 495 | | cd/m2 | luminance | RFC-AAAA | 496 | | Bspl | bel sound pressure level | RFC-AAAA | 497 | | b/s | bits per second | RFC-AAAA | 498 | 499 | 500 | 501 | 502 | 503 | Jennings Expires January 10, 2011 [Page 9] 504 | 505 | Internet-Draft Sensor Markup July 2010 506 | 507 | 508 | | lat | degrees latitude. Assumed to be in WGS84 | RFC-AAAA | 509 | | | unless another reference frame is known for | | 510 | | | the sensor. | | 511 | | lon | degrees longitude. Assumed to be in WGS84 | RFC-AAAA | 512 | | | unless another reference frame is known for | | 513 | | | the sensor. | | 514 | +--------+----------------------------------------------+-----------+ 515 | 516 | New entries can be added to the registration by either Expert Review 517 | or IESG Approval as defined in [RFC5226]. Experts should exercise 518 | their own good judgement but need to consider the following 519 | guidelines: 520 | 521 | 1. There needs to be a real and compelling use for any new unit to 522 | be added. 523 | 2. Units should define the semantic information and be chosen 524 | carefully. Implementors need to remember that the same word may 525 | be used in different real-life contexts. For example, degrees 526 | when measuring latitude have no semantic relation to degrees 527 | when measuring temperature; thus two different units are needed. 528 | 3. These measurements are produced by computers for consumption by 529 | computers. The principle is that conversion has to be easily be 530 | done when both reading and writing the media type. The value of 531 | a single canonical representation outweighs the convenience of 532 | easy human representations or loss of precision in a conversion. 533 | 4. Use of SI prefixes such as "k" before the unit is not allowed. 534 | Instead one can represent the value using scientific notation 535 | such a 1.2e3. 536 | 5. For a given type of measurement, there will only be one unit 537 | type defined. So for length, meters are defined and other 538 | lengths such as mile, foot, light year are not allowed. For 539 | most cases, the SI unit is preferred. 540 | 6. Symbol names that could be easily confused with existing common 541 | units or units combined with prefixes should be avoided. For 542 | example, selecting a unit name of "mph" to indicate something 543 | that had nothing to do with velocity would be a bad choice, as 544 | "mph" is commonly used to mean mile per hour. 545 | 7. The following should not be used because the are common SI 546 | prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, n, p, f, 547 | a, z, y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 548 | 8. The following units should not be used as they are commonly used 549 | to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 550 | Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 551 | BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 552 | 9. The unit names are case sensitive and the correct case needs to 553 | be used, but symbols that differ only in case should not be 554 | allocated. 555 | 556 | 557 | 558 | 559 | Jennings Expires January 10, 2011 [Page 10] 560 | 561 | Internet-Draft Sensor Markup July 2010 562 | 563 | 564 | 10. A number after a unit typically indicates the previous unit 565 | raised to that power, and the / indicates that the units that 566 | follow are the reciprocal. A unit should have only one / in the 567 | name. 568 | 569 | 7.2. Media Type Registration 570 | 571 | The following registrations are done following the procedure 572 | specified in [RFC4288] and [RFC3023]. 573 | 574 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 575 | with the RFC number of this specification. 576 | 577 | 7.2.1. senml+json Media Type Registration 578 | 579 | To: ietf-types@iana.org 580 | 581 | Subject: Registration of media type application/senml+json 582 | 583 | Type name: application 584 | 585 | Subtype name: senml+json 586 | 587 | Required parameters: none 588 | 589 | Optional parameters: none 590 | 591 | Encoding considerations: Must be encoded as binary. See additional 592 | constraints in [RFC4627]. 593 | 594 | Security considerations: Sensor data can contain a wide range of 595 | information ranging from information that is very public, such the 596 | outside temperature in a given city, to very private information that 597 | requires integrity and confidentiality protection, such as patient 598 | health information. This format does not provide any security and 599 | instead relies on the transport protocol that carries it to provide 600 | security. Given applications need to look at the overall context of 601 | how this media type will be used to decide if the security is 602 | adequate. 603 | 604 | Interoperability considerations: JSON allows new fields to be 605 | defined and applications should be able to ignore fields they do not 606 | understand to ensure forward compatibility with extensions to this 607 | specification. 608 | 609 | Published specification: RFC-AAAA 610 | 611 | Applications that use this media type: N/A 612 | 613 | 614 | 615 | Jennings Expires January 10, 2011 [Page 11] 616 | 617 | Internet-Draft Sensor Markup July 2010 618 | 619 | 620 | Additional information: 621 | 622 | Magic number(s): none 623 | 624 | File extension(s): senml 625 | 626 | Macintosh file type code(s): none 627 | 628 | Person & email address to contact for further information: Cullen 629 | Jennings 630 | 631 | Intended usage: COMMON 632 | 633 | Restrictions on usage: None 634 | 635 | Author: Cullen Jennings 636 | 637 | Change controller: Cullen Jennings 638 | 639 | 640 | 8. Security Considerations 641 | 642 | Sensor data can range from information with almost no security 643 | considerations, such as the current temperature in a given city, to 644 | highly sensitive medical or location data. This specification 645 | provides no security protection for the data but is meant to be used 646 | inside another container or transport protocol such as S/MIME or HTTP 647 | with TLS that can provide integrity, confidentiality, and 648 | authentication information about the source of the data. 649 | 650 | Further discussion of security proprieties can be found in 651 | Section 7.2. 652 | 653 | 654 | 9. Acknowledgement 655 | 656 | I would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay 657 | Campbell and Carsten Bormann for their review comments. 658 | 659 | 660 | 10. References 661 | 662 | 10.1. Normative References 663 | 664 | [RFC4627] Crockford, D., "The application/json Media Type for 665 | JavaScript Object Notation (JSON)", RFC 4627, July 2006. 666 | 667 | [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 668 | 669 | 670 | 671 | Jennings Expires January 10, 2011 [Page 12] 672 | 673 | Internet-Draft Sensor Markup July 2010 674 | 675 | 676 | Types", RFC 3023, January 2001. 677 | 678 | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 679 | Registration Procedures", BCP 13, RFC 4288, December 2005. 680 | 681 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 | Requirement Levels", BCP 14, RFC 2119, March 1997. 683 | 684 | [IEEE.754.1985] 685 | Institute of Electrical and Electronics Engineers, 686 | "Standard for Binary Floating-Point Arithmetic", 687 | IEEE Standard 754, August 1985. 688 | 689 | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 690 | IANA Considerations Section in RFCs", BCP 26, RFC 5226, 691 | May 2008. 692 | 693 | [NIST822] Thompson, A. and B. Taylor, "Guide for the Use of the 694 | International System of Units (SI)", NIST Special 695 | Publication 811, 2008 Edition . 696 | 697 | [BIPM] Bureau International des Poids et Mesures, "The 698 | International System of Units (SI)", 8th edition, 2006 . 699 | 700 | 10.2. Informative References 701 | 702 | [I-D.shelby-core-coap] 703 | Shelby, Z., Frank, B., and D. Sturek, "Constrained 704 | Application Protocol (CoAP)", draft-shelby-core-coap-01 705 | (work in progress), May 2010. 706 | 707 | [I-D.ietf-6man-text-addr-representation] 708 | Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 709 | Address Text Representation", 710 | draft-ietf-6man-text-addr-representation-07 (work in 711 | progress), February 2010. 712 | 713 | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 714 | Unique IDentifier (UUID) URN Namespace", RFC 4122, 715 | July 2005. 716 | 717 | 718 | 719 | 720 | 721 | 722 | 723 | 724 | 725 | 726 | 727 | Jennings Expires January 10, 2011 [Page 13] 728 | 729 | Internet-Draft Sensor Markup July 2010 730 | 731 | 732 | Author's Address 733 | 734 | Cullen Jennings 735 | Cisco 736 | 170 West Tasman Drive 737 | San Jose, CA 95134 738 | USA 739 | 740 | Phone: +1 408 421-9990 741 | Email: fluffy@cisco.com 742 | 743 | 744 | 745 | 746 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | 763 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 | Jennings Expires January 10, 2011 [Page 14] 784 | 785 | -------------------------------------------------------------------------------- /archive/draft-jennings-senml-02.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Network Working Group C. Jennings 5 | Internet-Draft Cisco 6 | Intended status: Experimental July 10, 2010 7 | Expires: January 11, 2011 8 | 9 | 10 | Media Type for Sensor Markup Language (SENML) 11 | draft-jennings-senml-02 12 | 13 | Abstract 14 | 15 | This specification defines media types for representing simple sensor 16 | measurements in JSON. A simple sensor, such as a temperature sensor, 17 | could use this media type in protocols such as HTTP to transport the 18 | values of a sensor. 19 | 20 | Status of this Memo 21 | 22 | This Internet-Draft is submitted in full conformance with the 23 | provisions of BCP 78 and BCP 79. 24 | 25 | Internet-Drafts are working documents of the Internet Engineering 26 | Task Force (IETF). Note that other groups may also distribute 27 | working documents as Internet-Drafts. The list of current Internet- 28 | Drafts is at http://datatracker.ietf.org/drafts/current/. 29 | 30 | Internet-Drafts are draft documents valid for a maximum of six months 31 | and may be updated, replaced, or obsoleted by other documents at any 32 | time. It is inappropriate to use Internet-Drafts as reference 33 | material or to cite them other than as "work in progress." 34 | 35 | This Internet-Draft will expire on January 11, 2011. 36 | 37 | Copyright Notice 38 | 39 | Copyright (c) 2010 IETF Trust and the persons identified as the 40 | document authors. All rights reserved. 41 | 42 | This document is subject to BCP 78 and the IETF Trust's Legal 43 | Provisions Relating to IETF Documents 44 | (http://trustee.ietf.org/license-info) in effect on the date of 45 | publication of this document. Please review these documents 46 | carefully, as they describe your rights and restrictions with respect 47 | to this document. Code Components extracted from this document must 48 | include Simplified BSD License text as described in Section 4.e of 49 | the Trust Legal Provisions and are provided without warranty as 50 | described in the Simplified BSD License. 51 | 52 | 53 | 54 | 55 | Jennings Expires January 11, 2011 [Page 1] 56 | 57 | Internet-Draft Sensor Markup July 2010 58 | 59 | 60 | Table of Contents 61 | 62 | 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 | 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 3 64 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 | 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 | 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 | 5.1. Simple Example . . . . . . . . . . . . . . . . . . . . . . 6 68 | 5.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 6 69 | 6. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 | 7.1. Units Registry . . . . . . . . . . . . . . . . . . . . . . 8 72 | 7.2. Media Type Registration . . . . . . . . . . . . . . . . . 11 73 | 7.2.1. senml+json Media Type Registration . . . . . . . . . . 11 74 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 | 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 76 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | Jennings Expires January 11, 2011 [Page 2] 112 | 113 | Internet-Draft Sensor Markup July 2010 114 | 115 | 116 | 1. Overview 117 | 118 | Connecting sensors to the internet is not new, and there have been 119 | many protocols designed to facilitate it. This specification defines 120 | new media types for carrying simple sensor information in a protocol 121 | such as HTTP or CoAP[I-D.shelby-core-coap]. This format was designed 122 | so that processors with very limited capabilities could easily encode 123 | a sensor reading into the media type, while at the same time a server 124 | parsing the data could relatively efficiently collect a large number 125 | of sensor readings. There are many types of more complex 126 | measurements and readings that this media type would not be suitable 127 | for. A decision was made not to carry most of the meta data about 128 | the sensor in this media type to help reduce the size of the data and 129 | improve efficiency in decoding. 130 | 131 | JSON[RFC4627] was selected as a basis for the encoding as it 132 | represents a widely understood way of encoding data that is popular 133 | in current web based APIs and represents reasonable trade-offs 134 | between extensibility, simplicity, and efficiency. 135 | 136 | The data is structured as a single JSON object (with attributes) that 137 | contains an array of measurements. Each measurement is a JSON object 138 | that has attributes such as a unique identifier for the sensor, the 139 | time the measurement was made, and the current value. For example, 140 | the following shows a measurement from a temperature gauge in JSON 141 | syntax. 142 | 143 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5, "u":"degC" }]} 144 | 145 | In the example above, the array in the object has a single 146 | measurement for a sensor named "0017f202a5c5-Temp" with a temperature 147 | of 23.5 degrees Celsius. 148 | 149 | 150 | 2. Requirements and Design Goals 151 | 152 | The design goal is to be able to send simple sensor measurements in 153 | small packets on mesh networks from large numbers of constrained 154 | devices. Keeping the total size under 80 bytes makes this easy to 155 | use on a wireless mesh network. It is always difficult to define 156 | what small code is, but there is a desire to be able to implement 157 | this in roughly 1 KB of flash on a 8 bit microprocessor. Experience 158 | with Google power meter and other large scale deployments has 159 | indicated strongly that the solution needs to support allowing 160 | multiple measurements to be batched into a single HTTP request. This 161 | "batch" upload capability allows the server side to efficiently 162 | support a large number of devices. The multiple measurements could 163 | be from multiple related sensors or from the same sensor but at 164 | 165 | 166 | 167 | Jennings Expires January 11, 2011 [Page 3] 168 | 169 | Internet-Draft Sensor Markup July 2010 170 | 171 | 172 | different times. 173 | 174 | 175 | 3. Terminology 176 | 177 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 | document are to be interpreted as described in RFC 2119 [RFC2119]. 180 | 181 | 182 | 4. Semantics 183 | 184 | Each media type caries a single JSON object that represents a set of 185 | measurements. This object contains several optional attributes 186 | described below, followed by an mandatory array of one or more 187 | measurements. 188 | 189 | bn: This is a base name string that is perpended to the names found 190 | in the measurements. This attribute is optional. 191 | bt: A base time that is added to the time found in a measurement. 192 | This attribute is optional. 193 | ver: Version number of media type format. This attribute is 194 | optional positive integer and defaults to 1 if not present. 195 | m: Array of measurements. Required, and there must be at least one 196 | measurement in the array. 197 | 198 | Each measurement contains several attributes, some of which are 199 | optional and some of which are mandatory. 200 | 201 | n: Name of sensor. When appended to the "bn" attribute, this must 202 | result in a globally unique identifier for the sensor. 203 | u: Units for the sensor value. Optional. Acceptable values are 204 | specified in Section 7.1 205 | v: Value of sensor. Optional if an s value is present, otherwise 206 | required. 207 | s: Integrated sum of the sensor values over time. Optional. This 208 | attribute is in the units specified in the u value multiplied by 209 | seconds. 210 | t: Time when measurement was made. Optional. 211 | 212 | Open Issue: Ongoing conversations around Privacy, Accuracy/ 213 | Confidence, Valid time, and tags. 214 | 215 | The bt, v, s, and t attributes are floating point numbers. Systems 216 | receiving measurements MUST be able to process the range of numbers 217 | that are representable as an IEEE double-precision floating-point 218 | numbers [IEEE.754.1985]. The number of significant digits in any 219 | measurement is not relevant, so a reading of 1.1 has exactly the same 220 | 221 | 222 | 223 | Jennings Expires January 11, 2011 [Page 4] 224 | 225 | Internet-Draft Sensor Markup July 2010 226 | 227 | 228 | semantic meaning as 1.10. If the value has an exponent, the "e" MUST 229 | be in lower case. The mantissa SHOULD be less than 19 characters 230 | long and the exponent SHOULD be less than 5 characters long. 231 | 232 | Systems reading one of the JSON objects MUST check for the ver 233 | attribute. If this value is a version number larger than the version 234 | which system understands, the system SHOULD NOT use this JSON object. 235 | This allows the version number to indicate that the object contains 236 | mandatory to understand attributes. New version numbers can only be 237 | defined in RFC which update this specification or it successors. 238 | 239 | The n value is concatenated to the bn value to get the name of the 240 | sensor. The resulting name needs to uniquely identity and 241 | differentiate the sensor from all others. If the name contains 48 242 | bits of random material, or 48 bits of material that is procedurally 243 | assigned in a unique way, it is considered to be good enough 244 | uniqueness. One way to achieve this uniqueness is to include a 245 | EUI-48 identifier (A MAC address) or some other 48 bit identifier 246 | that is guaranteed uniqueness (such as a 1-wire address) that is 247 | assigned to the device. UUIDs [RFC4122] are another way to generate 248 | a unique name. 249 | 250 | The resulting concatenated name MUST consist only of characters out 251 | of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 252 | and it MUST start with a character out of the set "A" to "Z", "a" to 253 | "z", or "0" to "9". This restricted character set was chosen so that 254 | these names can be directly used as in other types of URI including 255 | segments of an HTTP path with no special encoding. 256 | [I-D.ietf-6man-text-addr-representation] contains advice on encoding 257 | an IPv6 address in a name. 258 | 259 | If either the bt or t value is missing, the missing attribute is 260 | considered to have a value of zero. The bt and t values are added 261 | together to get the time of measurement. A time of zero is 262 | considered to mean that the sensor does not know the time and the 263 | measurement was made roughly "now". A negative value is used to 264 | indicate seconds in the past from roughly "now". A positive value is 265 | used to indicate the number of seconds since the start of the year 266 | 1970 in UTC excluding leap seconds. 267 | 268 | Open Issue: Should this be atomic seconds instead of "Unix" style 269 | time? 270 | 271 | Open Issue: What about NaN and Infinity in the floating point 272 | numbers? 273 | 274 | Open Issue: If bt & t where floating point, this would allow sub 275 | second precision. What time precision is needed? 276 | 277 | 278 | 279 | Jennings Expires January 11, 2011 [Page 5] 280 | 281 | Internet-Draft Sensor Markup July 2010 282 | 283 | 284 | Open Issue: What to do about Y2K38 problem that comes form 285 | representing time in this way? This is coming up very soon and will 286 | no doubt impact devices using this. Would it be better to use an 287 | epoch of 2010 instead of 1970? There does not seem to be any need to 288 | represent values before 2010. Would using a floating point double 289 | work better? 290 | 291 | 292 | 5. Syntax 293 | 294 | All of the data is UTF-8, but since this is for machine to machine 295 | communications on constrained systems, only characters with code 296 | points between U+0001 and U+007F are allowed. 297 | 298 | The contents MUST consist of exactly one JSON object as specified by 299 | [RFC4627]. This object MAY contain a "bn" attribute with a value of 300 | type string. This object MAY contain a "bt" attribute with a value 301 | of type number. The object MAY contain other attribute value pairs. 302 | The object MUST contain exactly one "m" attribute with a value of 303 | type array. The array MUST have one or more measurement objects. 304 | 305 | Inside each measurement object the "n" and "u" attribute are of type 306 | string and the "t", "v", and "s" attributes are of type number. 307 | 308 | 5.1. Simple Example 309 | 310 | The following shows a temperature reading taken approximately "now": 311 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5 }]} 312 | 313 | 5.2. Complex Example 314 | 315 | The following example show the voltage at Tue Jun 8 18:01:16 UTC 2010 316 | along with the current at that time and at each second for the 317 | previous 5 seconds. 318 | {"m":[ 319 | { "n": "voltage", "u": "V", 320 | "v": 120.1, "anExtension": 0.0 }, 321 | { "n": "current", "t": -5, "v": 1.2 }, 322 | { "n": "current", "t": -4, "v": 1.30 }, 323 | { "n": "current", "t": -3, "v": 0.14e1 }, 324 | { "n": "current", "t": -2, "v": 1.5 }, 325 | { "n": "current", "t": -1, "v": 1.6 }, 326 | { "n": "current", "t": 0 "v": 1.7 }, 327 | ] 328 | "bn": "0017f202a5c5", 329 | "bt": 1276020076, 330 | "someExtensions": "a value", 331 | } 332 | 333 | 334 | 335 | Jennings Expires January 11, 2011 [Page 6] 336 | 337 | Internet-Draft Sensor Markup July 2010 338 | 339 | 340 | 6. Usage Considerations 341 | 342 | The measurements support sending both the current value of a sensor 343 | as well as the an integrated sum. For many types of measurements, 344 | the sum is more useful than the current value. For example, an 345 | electrical meter that measures the energy a given computer uses will 346 | typically want to measure the cumulative amount of energy used. This 347 | is less prone to error than reporting the power each second and 348 | trying to have something on the server side sum together all the 349 | power measurements. If the network between the sensor and the meter 350 | goes down over some period of time, when it comes back up, the 351 | cumulative sum helps reflect what happened while the network was 352 | down. A meter like this would typically report a measurement with 353 | the units set to watts, but it would put the sum of energy used in 354 | the "s" attribute of the measurement. It might optionally include 355 | the current power in the "v" attribute. 356 | 357 | While the benefit of using the integrated sum is fairly clear for 358 | measurements like power and energy, it is less obvious for something 359 | like voltage. Reporting the sum of the temperatures makes it easy to 360 | compute averages even when the individual temperature values are not 361 | reported frequently enough to compute accurate averages. 362 | Implementors are encouraged to report the cumulative sum as well as 363 | the raw value of a given sensor. 364 | 365 | Applications that use the cumulative sum values need to understand 366 | they are very loosely defined by this specification, and depending on 367 | the particular sensor implementation may behave in unexpected ways. 368 | Applications should be able to deal with the following issues: 369 | 370 | 1. Many sensors will allow the cumulative sums to "wrap" back to 371 | zero after the value gets sufficiently large. 372 | 2. Some sensors will reset the cumulative sum back to zero when the 373 | device is reset, loses power, or is replaced with a different 374 | sensor. 375 | 3. Applications cannot make assumptions about when the device 376 | started accumulating values into the sum. 377 | 378 | Typically applications can make some assumptions about specific 379 | sensors that will allow them to deal with these problems. A common 380 | assumption is that for sensors whose measurement values are always 381 | positive, the sum should never get smaller; so if the sum does get 382 | smaller, the application will know that one of the situations listed 383 | above has happened. 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | Jennings Expires January 11, 2011 [Page 7] 392 | 393 | Internet-Draft Sensor Markup July 2010 394 | 395 | 396 | 7. IANA Considerations 397 | 398 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 399 | with the RFC number of this specification. 400 | 401 | 7.1. Units Registry 402 | 403 | IANA will create a registry of unit symbols. The primary purpose of 404 | this registry is to make sure that symbols uniquely map to give type 405 | of measurement. Definitions for many of these units can be found in 406 | [NIST822] and [BIPM]. 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | Jennings Expires January 11, 2011 [Page 8] 448 | 449 | Internet-Draft Sensor Markup July 2010 450 | 451 | 452 | +--------+----------------------------------------------+-----------+ 453 | | Symbol | Description | Reference | 454 | +--------+----------------------------------------------+-----------+ 455 | | m | meter | RFC-AAAA | 456 | | kg | kilogram | RFC-AAAA | 457 | | s | second | RFC-AAAA | 458 | | A | ampere | RFC-AAAA | 459 | | K | kelvin | RFC-AAAA | 460 | | cd | candela | RFC-AAAA | 461 | | mol | mole | RFC-AAAA | 462 | | Hz | hertz | RFC-AAAA | 463 | | rad | radian | RFC-AAAA | 464 | | sr | steradian | RFC-AAAA | 465 | | N | newton | RFC-AAAA | 466 | | Pa | pascal | RFC-AAAA | 467 | | J | joule | RFC-AAAA | 468 | | W | watt | RFC-AAAA | 469 | | C | coulomb | RFC-AAAA | 470 | | V | volt | RFC-AAAA | 471 | | F | farad | RFC-AAAA | 472 | | Ohm | ohm | RFC-AAAA | 473 | | S | siemens | RFC-AAAA | 474 | | Wb | weber | RFC-AAAA | 475 | | T | tesla | RFC-AAAA | 476 | | H | henry | RFC-AAAA | 477 | | degC | degrees Celsius | RFC-AAAA | 478 | | lm | lumen | RFC-AAAA | 479 | | lx | lux | RFC-AAAA | 480 | | Bq | becquerel | RFC-AAAA | 481 | | Gy | gray | RFC-AAAA | 482 | | Sv | sievert | RFC-AAAA | 483 | | kat | katal | RFC-AAAA | 484 | | pH | pH acidity | RFC-AAAA | 485 | | % | Value of a switch. A value of 0.0 indicates | RFC-AAAA | 486 | | | the switch is off while 100.0 indicates on. | | 487 | | count | counter value | RFC-AAAA | 488 | | %RH | Relative Humidity | RFC-AAAA | 489 | | m2 | area | RFC-AAAA | 490 | | l | volume in liters | RFC-AAAA | 491 | | m/s | velocity | RFC-AAAA | 492 | | m/s2 | acceleration | RFC-AAAA | 493 | | l/s | flow rate in liters per second | RFC-AAAA | 494 | | W/m2 | irradiance | RFC-AAAA | 495 | | cd/m2 | luminance | RFC-AAAA | 496 | | Bspl | bel sound pressure level | RFC-AAAA | 497 | | bit/s | bits per second | RFC-AAAA | 498 | 499 | 500 | 501 | 502 | 503 | Jennings Expires January 11, 2011 [Page 9] 504 | 505 | Internet-Draft Sensor Markup July 2010 506 | 507 | 508 | | lat | degrees latitude. Assumed to be in WGS84 | RFC-AAAA | 509 | | | unless another reference frame is known for | | 510 | | | the sensor. | | 511 | | lon | degrees longitude. Assumed to be in WGS84 | RFC-AAAA | 512 | | | unless another reference frame is known for | | 513 | | | the sensor. | | 514 | +--------+----------------------------------------------+-----------+ 515 | 516 | New entries can be added to the registration by either Expert Review 517 | or IESG Approval as defined in [RFC5226]. Experts should exercise 518 | their own good judgement but need to consider the following 519 | guidelines: 520 | 521 | 1. There needs to be a real and compelling use for any new unit to 522 | be added. 523 | 2. Units should define the semantic information and be chosen 524 | carefully. Implementors need to remember that the same word may 525 | be used in different real-life contexts. For example, degrees 526 | when measuring latitude have no semantic relation to degrees 527 | when measuring temperature; thus two different units are needed. 528 | 3. These measurements are produced by computers for consumption by 529 | computers. The principle is that conversion has to be easily be 530 | done when both reading and writing the media type. The value of 531 | a single canonical representation outweighs the convenience of 532 | easy human representations or loss of precision in a conversion. 533 | 4. Use of SI prefixes such as "k" before the unit is not allowed. 534 | Instead one can represent the value using scientific notation 535 | such a 1.2e3. 536 | 5. For a given type of measurement, there will only be one unit 537 | type defined. So for length, meters are defined and other 538 | lengths such as mile, foot, light year are not allowed. For 539 | most cases, the SI unit is preferred. 540 | 6. Symbol names that could be easily confused with existing common 541 | units or units combined with prefixes should be avoided. For 542 | example, selecting a unit name of "mph" to indicate something 543 | that had nothing to do with velocity would be a bad choice, as 544 | "mph" is commonly used to mean mile per hour. 545 | 7. The following should not be used because the are common SI 546 | prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, 547 | z, y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 548 | 8. The following units should not be used as they are commonly used 549 | to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 550 | Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 551 | BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 552 | 9. The unit names are case sensitive and the correct case needs to 553 | be used, but symbols that differ only in case should not be 554 | allocated. 555 | 556 | 557 | 558 | 559 | Jennings Expires January 11, 2011 [Page 10] 560 | 561 | Internet-Draft Sensor Markup July 2010 562 | 563 | 564 | 10. A number after a unit typically indicates the previous unit 565 | raised to that power, and the / indicates that the units that 566 | follow are the reciprocal. A unit should have only one / in the 567 | name. 568 | 569 | 7.2. Media Type Registration 570 | 571 | The following registrations are done following the procedure 572 | specified in [RFC4288] and [RFC3023]. 573 | 574 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 575 | with the RFC number of this specification. 576 | 577 | 7.2.1. senml+json Media Type Registration 578 | 579 | To: ietf-types@iana.org 580 | 581 | Subject: Registration of media type application/senml+json 582 | 583 | Type name: application 584 | 585 | Subtype name: senml+json 586 | 587 | Required parameters: none 588 | 589 | Optional parameters: none 590 | 591 | Encoding considerations: Must be encoded as binary. See additional 592 | constraints in [RFC4627]. 593 | 594 | Security considerations: Sensor data can contain a wide range of 595 | information ranging from information that is very public, such the 596 | outside temperature in a given city, to very private information that 597 | requires integrity and confidentiality protection, such as patient 598 | health information. This format does not provide any security and 599 | instead relies on the transport protocol that carries it to provide 600 | security. Given applications need to look at the overall context of 601 | how this media type will be used to decide if the security is 602 | adequate. 603 | 604 | Interoperability considerations: JSON allows new fields to be 605 | defined and applications should be able to ignore fields they do not 606 | understand to ensure forward compatibility with extensions to this 607 | specification. 608 | 609 | Published specification: RFC-AAAA 610 | 611 | Applications that use this media type: N/A 612 | 613 | 614 | 615 | Jennings Expires January 11, 2011 [Page 11] 616 | 617 | Internet-Draft Sensor Markup July 2010 618 | 619 | 620 | Additional information: 621 | 622 | Magic number(s): none 623 | 624 | File extension(s): senml 625 | 626 | Macintosh file type code(s): none 627 | 628 | Person & email address to contact for further information: Cullen 629 | Jennings 630 | 631 | Intended usage: COMMON 632 | 633 | Restrictions on usage: None 634 | 635 | Author: Cullen Jennings 636 | 637 | Change controller: Cullen Jennings 638 | 639 | 640 | 8. Security Considerations 641 | 642 | Sensor data can range from information with almost no security 643 | considerations, such as the current temperature in a given city, to 644 | highly sensitive medical or location data. This specification 645 | provides no security protection for the data but is meant to be used 646 | inside another container or transport protocol such as S/MIME or HTTP 647 | with TLS that can provide integrity, confidentiality, and 648 | authentication information about the source of the data. 649 | 650 | Further discussion of security proprieties can be found in 651 | Section 7.2. 652 | 653 | 654 | 9. Acknowledgement 655 | 656 | I would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay 657 | Campbell and Carsten Bormann for their review comments. 658 | 659 | 660 | 10. References 661 | 662 | 10.1. Normative References 663 | 664 | [RFC4627] Crockford, D., "The application/json Media Type for 665 | JavaScript Object Notation (JSON)", RFC 4627, July 2006. 666 | 667 | [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 668 | 669 | 670 | 671 | Jennings Expires January 11, 2011 [Page 12] 672 | 673 | Internet-Draft Sensor Markup July 2010 674 | 675 | 676 | Types", RFC 3023, January 2001. 677 | 678 | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 679 | Registration Procedures", BCP 13, RFC 4288, December 2005. 680 | 681 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 | Requirement Levels", BCP 14, RFC 2119, March 1997. 683 | 684 | [IEEE.754.1985] 685 | Institute of Electrical and Electronics Engineers, 686 | "Standard for Binary Floating-Point Arithmetic", 687 | IEEE Standard 754, August 1985. 688 | 689 | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 690 | IANA Considerations Section in RFCs", BCP 26, RFC 5226, 691 | May 2008. 692 | 693 | [NIST822] Thompson, A. and B. Taylor, "Guide for the Use of the 694 | International System of Units (SI)", NIST Special 695 | Publication 811, 2008 Edition . 696 | 697 | [BIPM] Bureau International des Poids et Mesures, "The 698 | International System of Units (SI)", 8th edition, 2006 . 699 | 700 | 10.2. Informative References 701 | 702 | [I-D.shelby-core-coap] 703 | Shelby, Z., Frank, B., and D. Sturek, "Constrained 704 | Application Protocol (CoAP)", draft-shelby-core-coap-01 705 | (work in progress), May 2010. 706 | 707 | [I-D.ietf-6man-text-addr-representation] 708 | Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 709 | Address Text Representation", 710 | draft-ietf-6man-text-addr-representation-07 (work in 711 | progress), February 2010. 712 | 713 | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 714 | Unique IDentifier (UUID) URN Namespace", RFC 4122, 715 | July 2005. 716 | 717 | 718 | 719 | 720 | 721 | 722 | 723 | 724 | 725 | 726 | 727 | Jennings Expires January 11, 2011 [Page 13] 728 | 729 | Internet-Draft Sensor Markup July 2010 730 | 731 | 732 | Author's Address 733 | 734 | Cullen Jennings 735 | Cisco 736 | 170 West Tasman Drive 737 | San Jose, CA 95134 738 | USA 739 | 740 | Phone: +1 408 421-9990 741 | Email: fluffy@cisco.com 742 | 743 | 744 | 745 | 746 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | 763 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 | Jennings Expires January 11, 2011 [Page 14] 784 | 785 | -------------------------------------------------------------------------------- /archive/draft-jennings-senml-03.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Network Working Group C. Jennings 5 | Internet-Draft Cisco 6 | Intended status: Experimental September 21, 2010 7 | Expires: March 25, 2011 8 | 9 | 10 | Media Type for Sensor Markup Language (SENML) 11 | draft-jennings-senml-03 12 | 13 | Abstract 14 | 15 | This specification defines media types for representing simple sensor 16 | measurements in JSON. A simple sensor, such as a temperature sensor, 17 | could use this media type in protocols such as HTTP to transport the 18 | values of a sensor. 19 | 20 | Status of this Memo 21 | 22 | This Internet-Draft is submitted in full conformance with the 23 | provisions of BCP 78 and BCP 79. 24 | 25 | Internet-Drafts are working documents of the Internet Engineering 26 | Task Force (IETF). Note that other groups may also distribute 27 | working documents as Internet-Drafts. The list of current Internet- 28 | Drafts is at http://datatracker.ietf.org/drafts/current/. 29 | 30 | Internet-Drafts are draft documents valid for a maximum of six months 31 | and may be updated, replaced, or obsoleted by other documents at any 32 | time. It is inappropriate to use Internet-Drafts as reference 33 | material or to cite them other than as "work in progress." 34 | 35 | This Internet-Draft will expire on March 25, 2011. 36 | 37 | Copyright Notice 38 | 39 | Copyright (c) 2010 IETF Trust and the persons identified as the 40 | document authors. All rights reserved. 41 | 42 | This document is subject to BCP 78 and the IETF Trust's Legal 43 | Provisions Relating to IETF Documents 44 | (http://trustee.ietf.org/license-info) in effect on the date of 45 | publication of this document. Please review these documents 46 | carefully, as they describe your rights and restrictions with respect 47 | to this document. Code Components extracted from this document must 48 | include Simplified BSD License text as described in Section 4.e of 49 | the Trust Legal Provisions and are provided without warranty as 50 | described in the Simplified BSD License. 51 | 52 | 53 | 54 | 55 | Jennings Expires March 25, 2011 [Page 1] 56 | 57 | Internet-Draft Sensor Markup September 2010 58 | 59 | 60 | Table of Contents 61 | 62 | 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 | 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 3 64 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 | 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 | 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 | 5.1. Simple Example . . . . . . . . . . . . . . . . . . . . . . 6 68 | 5.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 6 69 | 6. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 | 7.1. Units Registry . . . . . . . . . . . . . . . . . . . . . . 8 72 | 7.2. Media Type Registration . . . . . . . . . . . . . . . . . 11 73 | 7.2.1. senml+json Media Type Registration . . . . . . . . . . 11 74 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 | 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 76 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | Jennings Expires March 25, 2011 [Page 2] 112 | 113 | Internet-Draft Sensor Markup September 2010 114 | 115 | 116 | 1. Overview 117 | 118 | Connecting sensors to the internet is not new, and there have been 119 | many protocols designed to facilitate it. This specification defines 120 | new media types for carrying simple sensor information in a protocol 121 | such as HTTP or CoAP[I-D.shelby-core-coap]. This format was designed 122 | so that processors with very limited capabilities could easily encode 123 | a sensor reading into the media type, while at the same time a server 124 | parsing the data could relatively efficiently collect a large number 125 | of sensor readings. There are many types of more complex 126 | measurements and readings that this media type would not be suitable 127 | for. A decision was made not to carry most of the meta data about 128 | the sensor in this media type to help reduce the size of the data and 129 | improve efficiency in decoding. 130 | 131 | JSON[RFC4627] was selected as a basis for the encoding as it 132 | represents a widely understood way of encoding data that is popular 133 | in current web based APIs and represents reasonable trade-offs 134 | between extensibility, simplicity, and efficiency. 135 | 136 | The data is structured as a single JSON object (with attributes) that 137 | contains an array of measurements. Each measurement is a JSON object 138 | that has attributes such as a unique identifier for the sensor, the 139 | time the measurement was made, and the current value. For example, 140 | the following shows a measurement from a temperature gauge in JSON 141 | syntax. 142 | 143 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5, "u":"degC" }]} 144 | 145 | In the example above, the array in the object has a single 146 | measurement for a sensor named "0017f202a5c5-Temp" with a temperature 147 | of 23.5 degrees Celsius. 148 | 149 | 150 | 2. Requirements and Design Goals 151 | 152 | The design goal is to be able to send simple sensor measurements in 153 | small packets on mesh networks from large numbers of constrained 154 | devices. Keeping the total size under 80 bytes makes this easy to 155 | use on a wireless mesh network. It is always difficult to define 156 | what small code is, but there is a desire to be able to implement 157 | this in roughly 1 KB of flash on a 8 bit microprocessor. Experience 158 | with Google power meter and other large scale deployments has 159 | indicated strongly that the solution needs to support allowing 160 | multiple measurements to be batched into a single HTTP request. This 161 | "batch" upload capability allows the server side to efficiently 162 | support a large number of devices. The multiple measurements could 163 | be from multiple related sensors or from the same sensor but at 164 | 165 | 166 | 167 | Jennings Expires March 25, 2011 [Page 3] 168 | 169 | Internet-Draft Sensor Markup September 2010 170 | 171 | 172 | different times. 173 | 174 | 175 | 3. Terminology 176 | 177 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 | document are to be interpreted as described in RFC 2119 [RFC2119]. 180 | 181 | 182 | 4. Semantics 183 | 184 | Each media type caries a single JSON object that represents a set of 185 | measurements. This object contains several optional attributes 186 | described below, followed by an mandatory array of one or more 187 | measurements. 188 | 189 | bn: This is a base name string that is perpended to the names found 190 | in the measurements. This attribute is optional. 191 | bt: A base time that is added to the time found in a measurement. 192 | This attribute is optional. 193 | ver: Version number of media type format. This attribute is 194 | optional positive integer and defaults to 1 if not present. 195 | m: Array of measurements. Required, and there must be at least one 196 | measurement in the array. 197 | 198 | Each measurement contains several attributes, some of which are 199 | optional and some of which are mandatory. 200 | 201 | n: Name of sensor. When appended to the "bn" attribute, this must 202 | result in a globally unique identifier for the sensor. 203 | u: Units for the sensor value. Optional. Acceptable values are 204 | specified in Section 7.1 205 | v: Value of sensor. Optional if an s value is present, otherwise 206 | required. 207 | s: Integrated sum of the sensor values over time. Optional. This 208 | attribute is in the units specified in the u value multiplied by 209 | seconds. 210 | t: Time when measurement was made. Optional. 211 | 212 | Open Issue: Ongoing conversations around Privacy, Accuracy/ 213 | Confidence, Valid time, and tags. 214 | 215 | The bt, v, s, and t attributes are floating point numbers. Systems 216 | receiving measurements MUST be able to process the range of numbers 217 | that are representable as an IEEE double-precision floating-point 218 | numbers [IEEE.754.1985]. The number of significant digits in any 219 | measurement is not relevant, so a reading of 1.1 has exactly the same 220 | 221 | 222 | 223 | Jennings Expires March 25, 2011 [Page 4] 224 | 225 | Internet-Draft Sensor Markup September 2010 226 | 227 | 228 | semantic meaning as 1.10. If the value has an exponent, the "e" MUST 229 | be in lower case. The mantissa SHOULD be less than 19 characters 230 | long and the exponent SHOULD be less than 5 characters long. 231 | 232 | Systems reading one of the JSON objects MUST check for the ver 233 | attribute. If this value is a version number larger than the version 234 | which system understands, the system SHOULD NOT use this JSON object. 235 | This allows the version number to indicate that the object contains 236 | mandatory to understand attributes. New version numbers can only be 237 | defined in RFC which update this specification or it successors. 238 | 239 | The n value is concatenated to the bn value to get the name of the 240 | sensor. The resulting name needs to uniquely identity and 241 | differentiate the sensor from all others. If the name contains 48 242 | bits of random material, or 48 bits of material that is procedurally 243 | assigned in a unique way, it is considered to be good enough 244 | uniqueness. One way to achieve this uniqueness is to include a 245 | EUI-48 identifier (A MAC address) or some other 48 bit identifier 246 | that is guaranteed uniqueness (such as a 1-wire address) that is 247 | assigned to the device. UUIDs [RFC4122] are another way to generate 248 | a unique name. 249 | 250 | The resulting concatenated name MUST consist only of characters out 251 | of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 252 | and it MUST start with a character out of the set "A" to "Z", "a" to 253 | "z", or "0" to "9". This restricted character set was chosen so that 254 | these names can be directly used as in other types of URI including 255 | segments of an HTTP path with no special encoding. 256 | [I-D.ietf-6man-text-addr-representation] contains advice on encoding 257 | an IPv6 address in a name. 258 | 259 | If either the bt or t value is missing, the missing attribute is 260 | considered to have a value of zero. The bt and t values are added 261 | together to get the time of measurement. A time of zero is 262 | considered to mean that the sensor does not know the time and the 263 | measurement was made roughly "now". A negative value is used to 264 | indicate seconds in the past from roughly "now". A positive value is 265 | used to indicate the number of seconds since the start of the year 266 | 1970 in UTC excluding leap seconds. 267 | 268 | Open Issue: Should this be atomic seconds instead of "Unix" style 269 | time? 270 | 271 | Open Issue: What about NaN and Infinity in the floating point 272 | numbers? 273 | 274 | Open Issue: If bt & t where floating point, this would allow sub 275 | second precision. What time precision is needed? 276 | 277 | 278 | 279 | Jennings Expires March 25, 2011 [Page 5] 280 | 281 | Internet-Draft Sensor Markup September 2010 282 | 283 | 284 | Open Issue: What to do about Y2K38 problem that comes form 285 | representing time in this way? This is coming up very soon and will 286 | no doubt impact devices using this. Would it be better to use an 287 | epoch of 2010 instead of 1970? There does not seem to be any need to 288 | represent values before 2010. Would using a floating point double 289 | work better? 290 | 291 | 292 | 5. Syntax 293 | 294 | All of the data is UTF-8, but since this is for machine to machine 295 | communications on constrained systems, only characters with code 296 | points between U+0001 and U+007F are allowed. 297 | 298 | The contents MUST consist of exactly one JSON object as specified by 299 | [RFC4627]. This object MAY contain a "bn" attribute with a value of 300 | type string. This object MAY contain a "bt" attribute with a value 301 | of type number. The object MAY contain other attribute value pairs. 302 | The object MUST contain exactly one "m" attribute with a value of 303 | type array. The array MUST have one or more measurement objects. 304 | 305 | Inside each measurement object the "n" and "u" attribute are of type 306 | string and the "t", "v", and "s" attributes are of type number. 307 | 308 | 5.1. Simple Example 309 | 310 | The following shows a temperature reading taken approximately "now": 311 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5 }]} 312 | 313 | 5.2. Complex Example 314 | 315 | The following example show the voltage at Tue Jun 8 18:01:16 UTC 2010 316 | along with the current at that time and at each second for the 317 | previous 5 seconds. 318 | {"m":[ 319 | { "n": "voltage", "u": "V", 320 | "v": 120.1, "anExtension": 0.0 }, 321 | { "n": "current", "t": -5, "v": 1.2 }, 322 | { "n": "current", "t": -4, "v": 1.30 }, 323 | { "n": "current", "t": -3, "v": 0.14e1 }, 324 | { "n": "current", "t": -2, "v": 1.5 }, 325 | { "n": "current", "t": -1, "v": 1.6 }, 326 | { "n": "current", "t": 0 "v": 1.7 }, 327 | ] 328 | "bn": "0017f202a5c5", 329 | "bt": 1276020076, 330 | "someExtensions": "a value", 331 | } 332 | 333 | 334 | 335 | Jennings Expires March 25, 2011 [Page 6] 336 | 337 | Internet-Draft Sensor Markup September 2010 338 | 339 | 340 | 6. Usage Considerations 341 | 342 | The measurements support sending both the current value of a sensor 343 | as well as the an integrated sum. For many types of measurements, 344 | the sum is more useful than the current value. For example, an 345 | electrical meter that measures the energy a given computer uses will 346 | typically want to measure the cumulative amount of energy used. This 347 | is less prone to error than reporting the power each second and 348 | trying to have something on the server side sum together all the 349 | power measurements. If the network between the sensor and the meter 350 | goes down over some period of time, when it comes back up, the 351 | cumulative sum helps reflect what happened while the network was 352 | down. A meter like this would typically report a measurement with 353 | the units set to watts, but it would put the sum of energy used in 354 | the "s" attribute of the measurement. It might optionally include 355 | the current power in the "v" attribute. 356 | 357 | While the benefit of using the integrated sum is fairly clear for 358 | measurements like power and energy, it is less obvious for something 359 | like voltage. Reporting the sum of the temperatures makes it easy to 360 | compute averages even when the individual temperature values are not 361 | reported frequently enough to compute accurate averages. 362 | Implementors are encouraged to report the cumulative sum as well as 363 | the raw value of a given sensor. 364 | 365 | Applications that use the cumulative sum values need to understand 366 | they are very loosely defined by this specification, and depending on 367 | the particular sensor implementation may behave in unexpected ways. 368 | Applications should be able to deal with the following issues: 369 | 370 | 1. Many sensors will allow the cumulative sums to "wrap" back to 371 | zero after the value gets sufficiently large. 372 | 2. Some sensors will reset the cumulative sum back to zero when the 373 | device is reset, loses power, or is replaced with a different 374 | sensor. 375 | 3. Applications cannot make assumptions about when the device 376 | started accumulating values into the sum. 377 | 378 | Typically applications can make some assumptions about specific 379 | sensors that will allow them to deal with these problems. A common 380 | assumption is that for sensors whose measurement values are always 381 | positive, the sum should never get smaller; so if the sum does get 382 | smaller, the application will know that one of the situations listed 383 | above has happened. 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | Jennings Expires March 25, 2011 [Page 7] 392 | 393 | Internet-Draft Sensor Markup September 2010 394 | 395 | 396 | 7. IANA Considerations 397 | 398 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 399 | with the RFC number of this specification. 400 | 401 | 7.1. Units Registry 402 | 403 | IANA will create a registry of unit symbols. The primary purpose of 404 | this registry is to make sure that symbols uniquely map to give type 405 | of measurement. Definitions for many of these units can be found in 406 | [NIST822] and [BIPM]. 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | Jennings Expires March 25, 2011 [Page 8] 448 | 449 | Internet-Draft Sensor Markup September 2010 450 | 451 | 452 | +--------+----------------------------------------------+-----------+ 453 | | Symbol | Description | Reference | 454 | +--------+----------------------------------------------+-----------+ 455 | | m | meter | RFC-AAAA | 456 | | kg | kilogram | RFC-AAAA | 457 | | s | second | RFC-AAAA | 458 | | A | ampere | RFC-AAAA | 459 | | K | kelvin | RFC-AAAA | 460 | | cd | candela | RFC-AAAA | 461 | | mol | mole | RFC-AAAA | 462 | | Hz | hertz | RFC-AAAA | 463 | | rad | radian | RFC-AAAA | 464 | | sr | steradian | RFC-AAAA | 465 | | N | newton | RFC-AAAA | 466 | | Pa | pascal | RFC-AAAA | 467 | | J | joule | RFC-AAAA | 468 | | W | watt | RFC-AAAA | 469 | | C | coulomb | RFC-AAAA | 470 | | V | volt | RFC-AAAA | 471 | | F | farad | RFC-AAAA | 472 | | Ohm | ohm | RFC-AAAA | 473 | | S | siemens | RFC-AAAA | 474 | | Wb | weber | RFC-AAAA | 475 | | T | tesla | RFC-AAAA | 476 | | H | henry | RFC-AAAA | 477 | | degC | degrees Celsius | RFC-AAAA | 478 | | lm | lumen | RFC-AAAA | 479 | | lx | lux | RFC-AAAA | 480 | | Bq | becquerel | RFC-AAAA | 481 | | Gy | gray | RFC-AAAA | 482 | | Sv | sievert | RFC-AAAA | 483 | | kat | katal | RFC-AAAA | 484 | | pH | pH acidity | RFC-AAAA | 485 | | % | Value of a switch. A value of 0.0 indicates | RFC-AAAA | 486 | | | the switch is off while 100.0 indicates on. | | 487 | | count | counter value | RFC-AAAA | 488 | | %RH | Relative Humidity | RFC-AAAA | 489 | | m2 | area | RFC-AAAA | 490 | | l | volume in liters | RFC-AAAA | 491 | | m/s | velocity | RFC-AAAA | 492 | | m/s2 | acceleration | RFC-AAAA | 493 | | l/s | flow rate in liters per second | RFC-AAAA | 494 | | W/m2 | irradiance | RFC-AAAA | 495 | | cd/m2 | luminance | RFC-AAAA | 496 | | Bspl | bel sound pressure level | RFC-AAAA | 497 | | bit/s | bits per second | RFC-AAAA | 498 | 499 | 500 | 501 | 502 | 503 | Jennings Expires March 25, 2011 [Page 9] 504 | 505 | Internet-Draft Sensor Markup September 2010 506 | 507 | 508 | | lat | degrees latitude. Assumed to be in WGS84 | RFC-AAAA | 509 | | | unless another reference frame is known for | | 510 | | | the sensor. | | 511 | | lon | degrees longitude. Assumed to be in WGS84 | RFC-AAAA | 512 | | | unless another reference frame is known for | | 513 | | | the sensor. | | 514 | +--------+----------------------------------------------+-----------+ 515 | 516 | New entries can be added to the registration by either Expert Review 517 | or IESG Approval as defined in [RFC5226]. Experts should exercise 518 | their own good judgement but need to consider the following 519 | guidelines: 520 | 521 | 1. There needs to be a real and compelling use for any new unit to 522 | be added. 523 | 2. Units should define the semantic information and be chosen 524 | carefully. Implementors need to remember that the same word may 525 | be used in different real-life contexts. For example, degrees 526 | when measuring latitude have no semantic relation to degrees 527 | when measuring temperature; thus two different units are needed. 528 | 3. These measurements are produced by computers for consumption by 529 | computers. The principle is that conversion has to be easily be 530 | done when both reading and writing the media type. The value of 531 | a single canonical representation outweighs the convenience of 532 | easy human representations or loss of precision in a conversion. 533 | 4. Use of SI prefixes such as "k" before the unit is not allowed. 534 | Instead one can represent the value using scientific notation 535 | such a 1.2e3. 536 | 5. For a given type of measurement, there will only be one unit 537 | type defined. So for length, meters are defined and other 538 | lengths such as mile, foot, light year are not allowed. For 539 | most cases, the SI unit is preferred. 540 | 6. Symbol names that could be easily confused with existing common 541 | units or units combined with prefixes should be avoided. For 542 | example, selecting a unit name of "mph" to indicate something 543 | that had nothing to do with velocity would be a bad choice, as 544 | "mph" is commonly used to mean mile per hour. 545 | 7. The following should not be used because the are common SI 546 | prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, 547 | z, y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 548 | 8. The following units should not be used as they are commonly used 549 | to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 550 | Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 551 | BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 552 | 9. The unit names are case sensitive and the correct case needs to 553 | be used, but symbols that differ only in case should not be 554 | allocated. 555 | 556 | 557 | 558 | 559 | Jennings Expires March 25, 2011 [Page 10] 560 | 561 | Internet-Draft Sensor Markup September 2010 562 | 563 | 564 | 10. A number after a unit typically indicates the previous unit 565 | raised to that power, and the / indicates that the units that 566 | follow are the reciprocal. A unit should have only one / in the 567 | name. 568 | 569 | 7.2. Media Type Registration 570 | 571 | The following registrations are done following the procedure 572 | specified in [RFC4288] and [RFC3023]. 573 | 574 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 575 | with the RFC number of this specification. 576 | 577 | 7.2.1. senml+json Media Type Registration 578 | 579 | To: ietf-types@iana.org 580 | 581 | Subject: Registration of media type application/senml+json 582 | 583 | Type name: application 584 | 585 | Subtype name: senml+json 586 | 587 | Required parameters: none 588 | 589 | Optional parameters: none 590 | 591 | Encoding considerations: Must be encoded as binary. See additional 592 | constraints in [RFC4627]. 593 | 594 | Security considerations: Sensor data can contain a wide range of 595 | information ranging from information that is very public, such the 596 | outside temperature in a given city, to very private information that 597 | requires integrity and confidentiality protection, such as patient 598 | health information. This format does not provide any security and 599 | instead relies on the transport protocol that carries it to provide 600 | security. Given applications need to look at the overall context of 601 | how this media type will be used to decide if the security is 602 | adequate. 603 | 604 | Interoperability considerations: JSON allows new fields to be 605 | defined and applications should be able to ignore fields they do not 606 | understand to ensure forward compatibility with extensions to this 607 | specification. 608 | 609 | Published specification: RFC-AAAA 610 | 611 | Applications that use this media type: N/A 612 | 613 | 614 | 615 | Jennings Expires March 25, 2011 [Page 11] 616 | 617 | Internet-Draft Sensor Markup September 2010 618 | 619 | 620 | Additional information: 621 | 622 | Magic number(s): none 623 | 624 | File extension(s): senml 625 | 626 | Macintosh file type code(s): none 627 | 628 | Person & email address to contact for further information: Cullen 629 | Jennings 630 | 631 | Intended usage: COMMON 632 | 633 | Restrictions on usage: None 634 | 635 | Author: Cullen Jennings 636 | 637 | Change controller: Cullen Jennings 638 | 639 | 640 | 8. Security Considerations 641 | 642 | Sensor data can range from information with almost no security 643 | considerations, such as the current temperature in a given city, to 644 | highly sensitive medical or location data. This specification 645 | provides no security protection for the data but is meant to be used 646 | inside another container or transport protocol such as S/MIME or HTTP 647 | with TLS that can provide integrity, confidentiality, and 648 | authentication information about the source of the data. 649 | 650 | Further discussion of security proprieties can be found in 651 | Section 7.2. 652 | 653 | 654 | 9. Acknowledgement 655 | 656 | I would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay 657 | Campbell and Carsten Bormann for their review comments. 658 | 659 | 660 | 10. References 661 | 662 | 10.1. Normative References 663 | 664 | [RFC4627] Crockford, D., "The application/json Media Type for 665 | JavaScript Object Notation (JSON)", RFC 4627, July 2006. 666 | 667 | [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 668 | 669 | 670 | 671 | Jennings Expires March 25, 2011 [Page 12] 672 | 673 | Internet-Draft Sensor Markup September 2010 674 | 675 | 676 | Types", RFC 3023, January 2001. 677 | 678 | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 679 | Registration Procedures", BCP 13, RFC 4288, December 2005. 680 | 681 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 | Requirement Levels", BCP 14, RFC 2119, March 1997. 683 | 684 | [IEEE.754.1985] 685 | Institute of Electrical and Electronics Engineers, 686 | "Standard for Binary Floating-Point Arithmetic", 687 | IEEE Standard 754, August 1985. 688 | 689 | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 690 | IANA Considerations Section in RFCs", BCP 26, RFC 5226, 691 | May 2008. 692 | 693 | [NIST822] Thompson, A. and B. Taylor, "Guide for the Use of the 694 | International System of Units (SI)", NIST Special 695 | Publication 811, 2008 Edition . 696 | 697 | [BIPM] Bureau International des Poids et Mesures, "The 698 | International System of Units (SI)", 8th edition, 2006 . 699 | 700 | 10.2. Informative References 701 | 702 | [I-D.shelby-core-coap] 703 | Shelby, Z., Frank, B., and D. Sturek, "Constrained 704 | Application Protocol (CoAP)", draft-shelby-core-coap-01 705 | (work in progress), May 2010. 706 | 707 | [I-D.ietf-6man-text-addr-representation] 708 | Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 709 | Address Text Representation", 710 | draft-ietf-6man-text-addr-representation-07 (work in 711 | progress), February 2010. 712 | 713 | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 714 | Unique IDentifier (UUID) URN Namespace", RFC 4122, 715 | July 2005. 716 | 717 | 718 | 719 | 720 | 721 | 722 | 723 | 724 | 725 | 726 | 727 | Jennings Expires March 25, 2011 [Page 13] 728 | 729 | Internet-Draft Sensor Markup September 2010 730 | 731 | 732 | Author's Address 733 | 734 | Cullen Jennings 735 | Cisco 736 | 170 West Tasman Drive 737 | San Jose, CA 95134 738 | USA 739 | 740 | Phone: +1 408 421-9990 741 | Email: fluffy@cisco.com 742 | 743 | 744 | 745 | 746 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | 763 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 | Jennings Expires March 25, 2011 [Page 14] 784 | 785 | -------------------------------------------------------------------------------- /archive/draft-jennings-senml-04.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Network Working Group C. Jennings 5 | Internet-Draft Cisco 6 | Intended status: Experimental October 24, 2010 7 | Expires: April 27, 2011 8 | 9 | 10 | Media Type for Sensor Markup Language (SENML) 11 | draft-jennings-senml-04 12 | 13 | Abstract 14 | 15 | This specification defines media types for representing simple sensor 16 | measurements in JSON. A simple sensor, such as a temperature sensor, 17 | could use this media type in protocols such as HTTP to transport the 18 | values of a sensor. 19 | 20 | Status of this Memo 21 | 22 | This Internet-Draft is submitted in full conformance with the 23 | provisions of BCP 78 and BCP 79. 24 | 25 | Internet-Drafts are working documents of the Internet Engineering 26 | Task Force (IETF). Note that other groups may also distribute 27 | working documents as Internet-Drafts. The list of current Internet- 28 | Drafts is at http://datatracker.ietf.org/drafts/current/. 29 | 30 | Internet-Drafts are draft documents valid for a maximum of six months 31 | and may be updated, replaced, or obsoleted by other documents at any 32 | time. It is inappropriate to use Internet-Drafts as reference 33 | material or to cite them other than as "work in progress." 34 | 35 | This Internet-Draft will expire on April 27, 2011. 36 | 37 | Copyright Notice 38 | 39 | Copyright (c) 2010 IETF Trust and the persons identified as the 40 | document authors. All rights reserved. 41 | 42 | This document is subject to BCP 78 and the IETF Trust's Legal 43 | Provisions Relating to IETF Documents 44 | (http://trustee.ietf.org/license-info) in effect on the date of 45 | publication of this document. Please review these documents 46 | carefully, as they describe your rights and restrictions with respect 47 | to this document. Code Components extracted from this document must 48 | include Simplified BSD License text as described in Section 4.e of 49 | the Trust Legal Provisions and are provided without warranty as 50 | described in the Simplified BSD License. 51 | 52 | 53 | 54 | 55 | Jennings Expires April 27, 2011 [Page 1] 56 | 57 | Internet-Draft Sensor Markup October 2010 58 | 59 | 60 | Table of Contents 61 | 62 | 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 | 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 3 64 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 | 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 | 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 | 5.1. Simple Example . . . . . . . . . . . . . . . . . . . . . . 6 68 | 5.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 6 69 | 6. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 | 7.1. Units Registry . . . . . . . . . . . . . . . . . . . . . . 8 72 | 7.2. Media Type Registration . . . . . . . . . . . . . . . . . 11 73 | 7.2.1. senml+json Media Type Registration . . . . . . . . . . 11 74 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 | 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 76 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | Jennings Expires April 27, 2011 [Page 2] 112 | 113 | Internet-Draft Sensor Markup October 2010 114 | 115 | 116 | 1. Overview 117 | 118 | Connecting sensors to the internet is not new, and there have been 119 | many protocols designed to facilitate it. This specification defines 120 | new media types for carrying simple sensor information in a protocol 121 | such as HTTP or CoAP[I-D.ietf-core-coap]. This format was designed 122 | so that processors with very limited capabilities could easily encode 123 | a sensor reading into the media type, while at the same time a server 124 | parsing the data could relatively efficiently collect a large number 125 | of sensor readings. There are many types of more complex 126 | measurements and readings that this media type would not be suitable 127 | for. A decision was made not to carry most of the meta data about 128 | the sensor in this media type to help reduce the size of the data and 129 | improve efficiency in decoding. 130 | 131 | JSON[RFC4627] was selected as a basis for the encoding as it 132 | represents a widely understood way of encoding data that is popular 133 | in current web based APIs and represents reasonable trade-offs 134 | between extensibility, simplicity, and efficiency. 135 | 136 | The data is structured as a single JSON object (with attributes) that 137 | contains an array of measurements. Each measurement is a JSON object 138 | that has attributes such as a unique identifier for the sensor, the 139 | time the measurement was made, and the current value. For example, 140 | the following shows a measurement from a temperature gauge in JSON 141 | syntax. 142 | 143 | {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5, "u":"degC" }]} 144 | 145 | In the example above, the array in the object has a single 146 | measurement for a sensor named "0017f202a5c5-Temp" with a temperature 147 | of 23.5 degrees Celsius. 148 | 149 | 150 | 2. Requirements and Design Goals 151 | 152 | The design goal is to be able to send simple sensor measurements in 153 | small packets on mesh networks from large numbers of constrained 154 | devices. Keeping the total size under 80 bytes makes this easy to 155 | use on a wireless mesh network. It is always difficult to define 156 | what small code is, but there is a desire to be able to implement 157 | this in roughly 1 KB of flash on a 8 bit microprocessor. Experience 158 | with Google power meter and other large scale deployments has 159 | indicated strongly that the solution needs to support allowing 160 | multiple measurements to be batched into a single HTTP request. This 161 | "batch" upload capability allows the server side to efficiently 162 | support a large number of devices. The multiple measurements could 163 | be from multiple related sensors or from the same sensor but at 164 | 165 | 166 | 167 | Jennings Expires April 27, 2011 [Page 3] 168 | 169 | Internet-Draft Sensor Markup October 2010 170 | 171 | 172 | different times. 173 | 174 | 175 | 3. Terminology 176 | 177 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 | document are to be interpreted as described in RFC 2119 [RFC2119]. 180 | 181 | 182 | 4. Semantics 183 | 184 | Each media type caries a single JSON object that represents a set of 185 | measurements. This object contains several optional attributes 186 | described below and a mandatory array of one or more measurements. 187 | 188 | bn: This is a base name string that is perpended to the names found 189 | in the measurements. This attribute is optional. 190 | bt: A base time that is added to the time found in a measurement. 191 | This attribute is optional. 192 | ver: Version number of media type format. This attribute is 193 | optional positive integer and defaults to 1 if not present. 194 | m: Array of measurements. Mandatory and there must be at least one 195 | measurement in the array. 196 | 197 | Each measurement contains several attributes, some of which are 198 | optional and some of which are mandatory. 199 | 200 | n: Name of sensor. When appended to the "bn" attribute, this must 201 | result in a globally unique identifier for the sensor. 202 | u: Units for the sensor value. Optional. Acceptable values are 203 | specified in Section 7.1 204 | v: Value of the sensor. Optional if an s value is present, otherwise 205 | required. 206 | s: Integrated sum of the sensor values over time. Optional. This 207 | attribute is in the units specified in the u value multiplied by 208 | seconds. 209 | t: Time when measurement was made. Optional. 210 | unc: The uncertainty in the measurement, that uses the same units as 211 | the base; if absent, the value is unknown (i.e., don't assume that 212 | this is zero). Optional. 213 | c: The confidence of the measurement, as a probability between 0.0 214 | and 1.0; if absent, this can be considered approximately 1. 215 | Optional. 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | Jennings Expires April 27, 2011 [Page 4] 224 | 225 | Internet-Draft Sensor Markup October 2010 226 | 227 | 228 | ut Update time. A time in seconds that represents the maximum time 229 | before this sensor will provide an updated reading. This can be 230 | used to detect the failure of sensors or communications path from 231 | the sensor. Optional. 232 | 233 | Open Issue: Ongoing conversations around Privacy and tags. Should 234 | there be a base version of unc & c? 235 | 236 | The bt, v, s, and t attributes are floating point numbers. Systems 237 | receiving measurements MUST be able to process the range of numbers 238 | that are representable as an IEEE double-precision floating-point 239 | numbers [IEEE.754.1985]. The number of significant digits in any 240 | measurement is not relevant, so a reading of 1.1 has exactly the same 241 | semantic meaning as 1.10. If the value has an exponent, the "e" MUST 242 | be in lower case. The mantissa SHOULD be less than 19 characters 243 | long and the exponent SHOULD be less than 5 characters long. This 244 | allows time values to have better than micro second precision over 245 | the next 100 years. 246 | 247 | Systems reading one of the JSON objects MUST check for the ver 248 | attribute. If this value is a version number larger than the version 249 | which system understands, the system SHOULD NOT use this JSON object. 250 | This allows the version number to indicate that the object contains 251 | mandatory to understand attributes. New version numbers can only be 252 | defined in RFC which updates this specification or it successors. 253 | 254 | The n value is concatenated to the bn value to get the name of the 255 | sensor. The resulting name needs to uniquely identity and 256 | differentiate the sensor from all others. If the name contains 48 257 | bits of random material, or 48 bits of material that is procedurally 258 | assigned in a unique way, it is considered to be good enough 259 | uniqueness. One way to achieve this uniqueness is to include a 260 | EUI-48 identifier (A MAC address) or some other 48 bit identifier 261 | that is guaranteed uniqueness (such as a 1-wire address) that is 262 | assigned to the device. UUIDs [RFC4122] are another way to generate 263 | a unique name. 264 | 265 | The resulting concatenated name MUST consist only of characters out 266 | of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 267 | and it MUST start with a character out of the set "A" to "Z", "a" to 268 | "z", or "0" to "9". This restricted character set was chosen so that 269 | these names can be directly used as in other types of URI including 270 | segments of an HTTP path with no special encoding. [RFC5952] 271 | contains advice on encoding an IPv6 address in a name. 272 | 273 | If either the bt or t value is missing, the missing attribute is 274 | considered to have a value of zero. The bt and t values are added 275 | together to get the time of measurement. A time of zero indicates 276 | 277 | 278 | 279 | Jennings Expires April 27, 2011 [Page 5] 280 | 281 | Internet-Draft Sensor Markup October 2010 282 | 283 | 284 | that the sensor does not know the absolute time and the measurement 285 | was made roughly "now". A negative value is used to indicate seconds 286 | in the past from roughly "now". A positive value is used to indicate 287 | the number of seconds, excluding leap seconds, since the start of the 288 | year 1970 in UTC . 289 | 290 | Open Issue: Should this be atomic seconds instead of "Unix" style 291 | time? 292 | 293 | Open Issue: What about NaN and Infinity in the floating point 294 | numbers? 295 | 296 | Open Issue: Do we need nanosecond precision for the t value? What 297 | device would know that? 298 | 299 | 300 | 5. Syntax 301 | 302 | All of the data is UTF-8, but since this is for machine to machine 303 | communications on constrained systems, only characters with code 304 | points between U+0001 and U+007F are allowed which corresponds to the 305 | ASCII[RFC0020] subset of UTF-8. 306 | 307 | The contents MUST consist of exactly one JSON object as specified by 308 | [RFC4627]. This object MAY contain a "bn" attribute with a value of 309 | type string. This object MAY contain a "bt" attribute with a value 310 | of type number. The object MAY contain other attribute value pairs. 311 | The object MUST contain exactly one "m" attribute with a value of 312 | type array. The array MUST have one or more measurement objects. 313 | 314 | Inside each measurement object the "n" and "u" attribute are of type 315 | string and the "t", "v", and "s" attributes are of type number. 316 | 317 | 5.1. Simple Example 318 | 319 | The following shows a temperature reading taken approximately "now" 320 | by a 1-wire sensor device that was assigned the unique 1-wire address 321 | of 0x000801EF221E: 322 | {"m":[{ "n": "000801EF221E-Temp", "v":23.5 }]} 323 | 324 | 5.2. Complex Example 325 | 326 | The following example show the voltage at Tue Jun 8 18:01:16 UTC 2010 327 | along with the current at that time and at each second for the 328 | previous 5 seconds. The device has a MAC address of 0017f202b5c4. 329 | 330 | 331 | 332 | 333 | 334 | 335 | Jennings Expires April 27, 2011 [Page 6] 336 | 337 | Internet-Draft Sensor Markup October 2010 338 | 339 | 340 | {"m":[ 341 | { "n": "voltage", "u": "V", 342 | "v": 120.1, "anExtension": 0.0 }, 343 | { "n": "current", "t": -5, "v": 1.2 }, 344 | { "n": "current", "t": -4, "v": 1.30 }, 345 | { "n": "current", "t": -3, "v": 0.14e1 }, 346 | { "n": "current", "t": -2, "v": 1.5 }, 347 | { "n": "current", "t": -1, "v": 1.6 }, 348 | { "n": "current", "t": 0, "v": 1.7 } 349 | ], 350 | "bn": "0017f202a5c4-", 351 | "bt": 1276020076, 352 | "someExtensions": "a value" 353 | } 354 | 355 | 356 | 6. Usage Considerations 357 | 358 | The measurements support sending both the current value of a sensor 359 | as well as the an integrated sum. For many types of measurements, 360 | the sum is more useful than the current value. For example, an 361 | electrical meter that measures the energy a given computer uses will 362 | typically want to measure the cumulative amount of energy used. This 363 | is less prone to error than reporting the power each second and 364 | trying to have something on the server side sum together all the 365 | power measurements. If the network between the sensor and the meter 366 | goes down over some period of time, when it comes back up, the 367 | cumulative sum helps reflect what happened while the network was 368 | down. A meter like this would typically report a measurement with 369 | the units set to watts, but it would put the sum of energy used in 370 | the "s" attribute of the measurement. It might optionally include 371 | the current power in the "v" attribute. 372 | 373 | While the benefit of using the integrated sum is fairly clear for 374 | measurements like power and energy, it is less obvious for something 375 | like temperature. Reporting the sum of the temperature makes it easy 376 | to compute averages even when the individual temperature values are 377 | not reported frequently enough to compute accurate averages. 378 | Implementors are encouraged to report the cumulative sum as well as 379 | the raw value of a given sensor. 380 | 381 | Applications that use the cumulative sum values need to understand 382 | they are very loosely defined by this specification, and depending on 383 | the particular sensor implementation may behave in unexpected ways. 384 | Applications should be able to deal with the following issues: 385 | 386 | 387 | 388 | 389 | 390 | 391 | Jennings Expires April 27, 2011 [Page 7] 392 | 393 | Internet-Draft Sensor Markup October 2010 394 | 395 | 396 | 1. Many sensors will allow the cumulative sums to "wrap" back to 397 | zero after the value gets sufficiently large. 398 | 2. Some sensors will reset the cumulative sum back to zero when the 399 | device is reset, loses power, or is replaced with a different 400 | sensor. 401 | 3. Applications cannot make assumptions about when the device 402 | started accumulating values into the sum. 403 | 404 | Typically applications can make some assumptions about specific 405 | sensors that will allow them to deal with these problems. A common 406 | assumption is that for sensors whose measurement values are always 407 | positive, the sum should never get smaller; so if the sum does get 408 | smaller, the application will know that one of the situations listed 409 | above has happened. 410 | 411 | 412 | 7. IANA Considerations 413 | 414 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 415 | with the RFC number of this specification. 416 | 417 | 7.1. Units Registry 418 | 419 | IANA will create a registry of unit symbols. The primary purpose of 420 | this registry is to make sure that symbols uniquely map to give type 421 | of measurement. Definitions for many of these units can be found in 422 | [NIST822] and [BIPM]. 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | Jennings Expires April 27, 2011 [Page 8] 448 | 449 | Internet-Draft Sensor Markup October 2010 450 | 451 | 452 | +--------+----------------------------------------------+-----------+ 453 | | Symbol | Description | Reference | 454 | +--------+----------------------------------------------+-----------+ 455 | | m | meter | RFC-AAAA | 456 | | kg | kilogram | RFC-AAAA | 457 | | s | second | RFC-AAAA | 458 | | A | ampere | RFC-AAAA | 459 | | K | kelvin | RFC-AAAA | 460 | | cd | candela | RFC-AAAA | 461 | | mol | mole | RFC-AAAA | 462 | | Hz | hertz | RFC-AAAA | 463 | | rad | radian | RFC-AAAA | 464 | | sr | steradian | RFC-AAAA | 465 | | N | newton | RFC-AAAA | 466 | | Pa | pascal | RFC-AAAA | 467 | | J | joule | RFC-AAAA | 468 | | W | watt | RFC-AAAA | 469 | | C | coulomb | RFC-AAAA | 470 | | V | volt | RFC-AAAA | 471 | | F | farad | RFC-AAAA | 472 | | Ohm | ohm | RFC-AAAA | 473 | | S | siemens | RFC-AAAA | 474 | | Wb | weber | RFC-AAAA | 475 | | T | tesla | RFC-AAAA | 476 | | H | henry | RFC-AAAA | 477 | | degC | degrees Celsius | RFC-AAAA | 478 | | lm | lumen | RFC-AAAA | 479 | | lx | lux | RFC-AAAA | 480 | | Bq | becquerel | RFC-AAAA | 481 | | Gy | gray | RFC-AAAA | 482 | | Sv | sievert | RFC-AAAA | 483 | | kat | katal | RFC-AAAA | 484 | | pH | pH acidity | RFC-AAAA | 485 | | % | Value of a switch. A value of 0.0 indicates | RFC-AAAA | 486 | | | the switch is off while 100.0 indicates on. | | 487 | | count | counter value | RFC-AAAA | 488 | | %RH | Relative Humidity | RFC-AAAA | 489 | | m2 | area | RFC-AAAA | 490 | | l | volume in liters | RFC-AAAA | 491 | | m/s | velocity | RFC-AAAA | 492 | | m/s2 | acceleration | RFC-AAAA | 493 | | l/s | flow rate in liters per second | RFC-AAAA | 494 | | W/m2 | irradiance | RFC-AAAA | 495 | | cd/m2 | luminance | RFC-AAAA | 496 | | Bspl | bel sound pressure level | RFC-AAAA | 497 | | bit/s | bits per second | RFC-AAAA | 498 | 499 | 500 | 501 | 502 | 503 | Jennings Expires April 27, 2011 [Page 9] 504 | 505 | Internet-Draft Sensor Markup October 2010 506 | 507 | 508 | | lat | degrees latitude. Assumed to be in WGS84 | RFC-AAAA | 509 | | | unless another reference frame is known for | | 510 | | | the sensor. | | 511 | | lon | degrees longitude. Assumed to be in WGS84 | RFC-AAAA | 512 | | | unless another reference frame is known for | | 513 | | | the sensor. | | 514 | +--------+----------------------------------------------+-----------+ 515 | 516 | New entries can be added to the registration by either Expert Review 517 | or IESG Approval as defined in [RFC5226]. Experts should exercise 518 | their own good judgement but need to consider the following 519 | guidelines: 520 | 521 | 1. There needs to be a real and compelling use for any new unit to 522 | be added. 523 | 2. Units should define the semantic information and be chosen 524 | carefully. Implementors need to remember that the same word may 525 | be used in different real-life contexts. For example, degrees 526 | when measuring latitude have no semantic relation to degrees 527 | when measuring temperature; thus two different units are needed. 528 | 3. These measurements are produced by computers for consumption by 529 | computers. The principle is that conversion has to be easily be 530 | done when both reading and writing the media type. The value of 531 | a single canonical representation outweighs the convenience of 532 | easy human representations or loss of precision in a conversion. 533 | 4. Use of SI prefixes such as "k" before the unit is not allowed. 534 | Instead one can represent the value using scientific notation 535 | such a 1.2e3. 536 | 5. For a given type of measurement, there will only be one unit 537 | type defined. So for length, meters are defined and other 538 | lengths such as mile, foot, light year are not allowed. For 539 | most cases, the SI unit is preferred. 540 | 6. Symbol names that could be easily confused with existing common 541 | units or units combined with prefixes should be avoided. For 542 | example, selecting a unit name of "mph" to indicate something 543 | that had nothing to do with velocity would be a bad choice, as 544 | "mph" is commonly used to mean miles per hour. 545 | 7. The following should not be used because the are common SI 546 | prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, 547 | z, y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 548 | 8. The following units should not be used as they are commonly used 549 | to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 550 | Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 551 | BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 552 | 9. The unit names are case sensitive and the correct case needs to 553 | be used, but symbols that differ only in case should not be 554 | allocated. 555 | 556 | 557 | 558 | 559 | Jennings Expires April 27, 2011 [Page 10] 560 | 561 | Internet-Draft Sensor Markup October 2010 562 | 563 | 564 | 10. A number after a unit typically indicates the previous unit 565 | raised to that power, and the / indicates that the units that 566 | follow are the reciprocal. A unit should have only one / in the 567 | name. 568 | 569 | 7.2. Media Type Registration 570 | 571 | The following registrations are done following the procedure 572 | specified in [RFC4288] and [RFC3023]. 573 | 574 | Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 575 | with the RFC number of this specification. 576 | 577 | 7.2.1. senml+json Media Type Registration 578 | 579 | To: ietf-types@iana.org 580 | 581 | Subject: Registration of media type application/senml+json 582 | 583 | Type name: application 584 | 585 | Subtype name: senml+json 586 | 587 | Required parameters: none 588 | 589 | Optional parameters: none 590 | 591 | Encoding considerations: Must be encoded as using a subset of the 592 | encoding allowed in [RFC4627]. Specifically, only the ASCII[RFC0020] 593 | subset of the UTF-8 characters are allowed. This simplifies 594 | implementation of very simple system and does not impose any 595 | significant limitations as all this data is meant for machine to 596 | machine communications and is not meant to be human readable. 597 | 598 | Security considerations: Sensor data can contain a wide range of 599 | information ranging from information that is very public, such the 600 | outside temperature in a given city, to very private information that 601 | requires integrity and confidentiality protection, such as patient 602 | health information. This format does not provide any security and 603 | instead relies on the transport protocol that carries it to provide 604 | security. Given applications need to look at the overall context of 605 | how this media type will be used to decide if the security is 606 | adequate. 607 | 608 | Interoperability considerations: Applications should ignore any JSON 609 | key value pairs that they do not understand. This allows backwards 610 | compatibility extensions to this specification. The "ver" field can 611 | be used to ensure the receiver supports a minimal level of 612 | 613 | 614 | 615 | Jennings Expires April 27, 2011 [Page 11] 616 | 617 | Internet-Draft Sensor Markup October 2010 618 | 619 | 620 | functionality needed by the creator of the JSON object. 621 | 622 | Published specification: RFC-AAAA 623 | 624 | Applications that use this media type: The type is used by systems 625 | that report electrical power usage and environmental information such 626 | as temperature and humidity. It can be used for a wide range of 627 | sensor reporting systems. 628 | 629 | Additional information: 630 | 631 | Magic number(s): none 632 | 633 | File extension(s): senml 634 | 635 | Macintosh file type code(s): none 636 | 637 | Person & email address to contact for further information: Cullen 638 | Jennings 639 | 640 | Intended usage: COMMON 641 | 642 | Restrictions on usage: None 643 | 644 | Author: Cullen Jennings 645 | 646 | Change controller: IESG 647 | 648 | 649 | 8. Security Considerations 650 | 651 | Sensor data can range from information with almost no security 652 | considerations, such as the current temperature in a given city, to 653 | highly sensitive medical or location data. This specification 654 | provides no security protection for the data but is meant to be used 655 | inside another container or transport protocol such as S/MIME or HTTP 656 | with TLS that can provide integrity, confidentiality, and 657 | authentication information about the source of the data. 658 | 659 | Further discussion of security proprieties can be found in 660 | Section 7.2. 661 | 662 | 663 | 9. Acknowledgement 664 | 665 | I would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay 666 | Campbell, Martin Thomson, Bjoern Hoehrmann, and Carsten Bormann for 667 | their review comments. 668 | 669 | 670 | 671 | Jennings Expires April 27, 2011 [Page 12] 672 | 673 | Internet-Draft Sensor Markup October 2010 674 | 675 | 676 | 10. References 677 | 678 | 10.1. Normative References 679 | 680 | [RFC4627] Crockford, D., "The application/json Media Type for 681 | JavaScript Object Notation (JSON)", RFC 4627, July 2006. 682 | 683 | [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 684 | Types", RFC 3023, January 2001. 685 | 686 | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 687 | Registration Procedures", BCP 13, RFC 4288, December 2005. 688 | 689 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 | Requirement Levels", BCP 14, RFC 2119, March 1997. 691 | 692 | [IEEE.754.1985] 693 | Institute of Electrical and Electronics Engineers, 694 | "Standard for Binary Floating-Point Arithmetic", 695 | IEEE Standard 754, August 1985. 696 | 697 | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 698 | IANA Considerations Section in RFCs", BCP 26, RFC 5226, 699 | May 2008. 700 | 701 | 10.2. Informative References 702 | 703 | [I-D.ietf-core-coap] 704 | Shelby, Z., Frank, B., and D. Sturek, "Constrained 705 | Application Protocol (CoAP)", draft-ietf-core-coap-02 706 | (work in progress), September 2010. 707 | 708 | [BIPM] Bureau International des Poids et Mesures, "The 709 | International System of Units (SI)", 8th edition, 2006 . 710 | 711 | [NIST822] Thompson, A. and B. Taylor, "Guide for the Use of the 712 | International System of Units (SI)", NIST Special 713 | Publication 811, 2008 Edition . 714 | 715 | [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 716 | Address Text Representation", RFC 5952, August 2010. 717 | 718 | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 719 | Unique IDentifier (UUID) URN Namespace", RFC 4122, 720 | July 2005. 721 | 722 | [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 723 | October 1969. 724 | 725 | 726 | 727 | Jennings Expires April 27, 2011 [Page 13] 728 | 729 | Internet-Draft Sensor Markup October 2010 730 | 731 | 732 | Author's Address 733 | 734 | Cullen Jennings 735 | Cisco 736 | 170 West Tasman Drive 737 | San Jose, CA 95134 738 | USA 739 | 740 | Phone: +1 408 421-9990 741 | Email: fluffy@cisco.com 742 | 743 | 744 | 745 | 746 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | 763 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 | Jennings Expires April 27, 2011 [Page 14] 784 | 785 | -------------------------------------------------------------------------------- /archive/draft-jennings-senml-05.html: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/archive/draft-jennings-senml-05.html -------------------------------------------------------------------------------- /archive/draft-jennings-senml-06.html: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/archive/draft-jennings-senml-06.html -------------------------------------------------------------------------------- /bin/exificient.jar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/bin/exificient.jar -------------------------------------------------------------------------------- /bin/jing.jar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/bin/jing.jar -------------------------------------------------------------------------------- /bin/trang.jar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/bin/trang.jar -------------------------------------------------------------------------------- /bin/xercesImpl.jar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/bin/xercesImpl.jar -------------------------------------------------------------------------------- /check-cddl-table-against-tbl-cbor-labels.rb: -------------------------------------------------------------------------------- 1 | require 'pp' 2 | 3 | MAPPINGS = Hash.new {|h, k| k} 4 | 5 | File.read("senml-cbor.cddl").scan(/([-\w]+)\s*=\s*([-\w]+)/) do |n, v| 6 | begin 7 | MAPPINGS[n] = Integer(v) 8 | rescue ArgumentError 9 | end 10 | end 11 | 12 | pp MAPPINGS 13 | 14 | texttable = Hash[File.read("draft-ietf-core-senml.md").lines("").grep(/#tbl-cbor-labels/).first. 15 | lines[1..-3].map{|x| 16 | x.chomp.scan(/\|\s*([^|\s]+)/)[1..-1].map{|y| 17 | Integer(y.first) rescue y.first 18 | } 19 | }] 20 | 21 | pp texttable 22 | 23 | raise unless texttable == MAPPINGS 24 | -------------------------------------------------------------------------------- /ex1.gen.exi: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/ex1.gen.exi -------------------------------------------------------------------------------- /ex1.gen.exi.hex: -------------------------------------------------------------------------------- 1 | 0000 a0 00 48 80 6c 20 01 06 1d 75 72 6e 3a 64 65 76 |..H.l ...urn:dev| 2 | 0010 3a 6f 77 3a 31 30 65 32 30 37 33 61 30 31 30 38 |:ow:10e2073a0108| 3 | 0020 30 30 36 33 02 05 43 65 6c 01 00 e7 01 01 00 03 |0063..Cel.......| 4 | 0030 01 |.| 5 | 0031 6 | -------------------------------------------------------------------------------- /ex1.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} 3 | ] 4 | -------------------------------------------------------------------------------- /ex1.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.498780179e+09,"v":23.1} 3 | ] 4 | -------------------------------------------------------------------------------- /ex1.gen.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /ex1.json: -------------------------------------------------------------------------------- 1 | [{ "n": "urn:dev:ow:10e2073a01080063", "v":23.1, "u":"Cel" }] 2 | -------------------------------------------------------------------------------- /ex10.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,"v":23.5}, 3 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09,"v":23.6} 4 | ] 5 | -------------------------------------------------------------------------------- /ex10.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,"v":23.5}, 3 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09,"v":23.6} 4 | ] 5 | -------------------------------------------------------------------------------- /ex10.gen.wrap.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09, 3 | "v":23.5}, 4 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09, 5 | "v":23.6} 6 | ] 7 | -------------------------------------------------------------------------------- /ex10.json: -------------------------------------------------------------------------------- 1 | [ 2 | { "n": "urn:dev:ow:10e2073a01080063", 3 | "t": 1276020076, "v":23.5, "u":"Cel" }, 4 | { "n": "urn:dev:ow:10e2073a01080063", 5 | "t": 1276020091, "v":23.6, "u":"Cel" } 6 | ] 7 | -------------------------------------------------------------------------------- /ex11.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,"v":23.5}, 3 | {"u":"Cel","t":1.276020091e+09,"v":23.6} 4 | ] 5 | -------------------------------------------------------------------------------- /ex11.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,"v":23.5}, 3 | {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09,"v":23.6} 4 | ] 5 | -------------------------------------------------------------------------------- /ex11.gen.wrap.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09, 3 | "v":23.5}, 4 | {"u":"Cel","t":1.276020091e+09, 5 | "v":23.6} 6 | ] 7 | -------------------------------------------------------------------------------- /ex11.json: -------------------------------------------------------------------------------- 1 | [ 2 | { "bn": "urn:dev:ow:10e2073a01080063", 3 | "t": 1276020076, "v":23.5, "u":"Cel" }, 4 | { "t": 1276020091, "v":23.6, "u":"Cel" } 5 | ] 6 | -------------------------------------------------------------------------------- /ex12.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bt":1.320078429e+09,"bu":"/","n":"2001:db8::3","v":1}, 3 | {"n":"2001:db8::4","v":1} 4 | ] 5 | -------------------------------------------------------------------------------- /ex12.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"2001:db8::3","u":"/","t":1.320078429e+09,"v":1}, 3 | {"n":"2001:db8::4","u":"/","t":1.320078429e+09,"v":1} 4 | ] 5 | -------------------------------------------------------------------------------- /ex12.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bt":1.320078429e+09,"bu":"/", 3 | "n":"2001:db8::3", "v":1 }, 4 | {"n":"2001:db8::4", "v":1 } 5 | ] 6 | -------------------------------------------------------------------------------- /ex13.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bt":1.320078429e+09,"bu":"/","n":"2001:db8::3","v":0.5}, 3 | {"n":"2001:db8::4","v":0.5}, 4 | {"n":"2001:db8::3","t":0.1,"v":0}, 5 | {"n":"2001:db8::4","t":0.1,"v":0} 6 | ] 7 | -------------------------------------------------------------------------------- /ex13.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bt":1.320078429e+09,"bu":"/", 3 | "n":"2001:db8::3","v":0.5}, 4 | {"n":"2001:db8::4","v":0.5}, 5 | {"n":"2001:db8::3","t":0.1,"v":0}, 6 | {"n":"2001:db8::4","t":0.1,"v":0} 7 | ] 8 | -------------------------------------------------------------------------------- /ex2.gen.exi: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/ex2.gen.exi -------------------------------------------------------------------------------- /ex2.gen.exi.hex: -------------------------------------------------------------------------------- 1 | 0000 a0 30 0d 84 80 f3 ab 93 71 d3 23 2b b1 d3 7b b9 |.0......q.#+..{.| 2 | 0010 d1 89 83 29 91 81 b9 9b 09 81 89 81 c1 81 81 b1 |...)............| 3 | 0020 99 d2 84 bb 37 b6 3a 30 b3 b2 90 1a b1 58 84 c0 |....7.:0.....X..| 4 | 0030 33 04 b1 ba b9 39 32 b7 3a 10 1a 09 06 40 38 |3....92.:....@8| 5 | 003f 6 | -------------------------------------------------------------------------------- /ex2.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063:","n":"voltage","u":"V","v":120.1}, 3 | {"n":"current","u":"A","v":1.2} 4 | ] 5 | -------------------------------------------------------------------------------- /ex2.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063:voltage","u":"V","t":1.498780179e+09,"v":120.1}, 3 | {"n":"urn:dev:ow:10e2073a01080063:current","u":"A","t":1.498780179e+09,"v":1.2} 4 | ] 5 | -------------------------------------------------------------------------------- /ex2.gen.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /ex2.json: -------------------------------------------------------------------------------- 1 | [ {"bn": "urn:dev:ow:10e2073a01080063:", 2 | "n": "voltage", "t": 0, "u": "V", "v": 120.1 }, 3 | {"n": "current", "t": 0, "u": "A", "v": 1.2 } 4 | ] 5 | -------------------------------------------------------------------------------- /ex3.gen.cbor: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/ex3.gen.cbor -------------------------------------------------------------------------------- /ex3.gen.cbor.diag: -------------------------------------------------------------------------------- 1 | [{-2: "urn:dev:ow:10e2073a0108006:", 2 | -3: 1276020076.001, -4: "A", -1: 5, 0: "voltage", 1: "V", 2: 120.1}, 3 | {0: "current", 6: -5, 2: 1.2}, {0: "current", 6: -4, 2: 1.3}, 4 | {0: "current", 6: -3, 2: 1.4}, {0: "current", 6: -2, 2: 1.5}, 5 | {0: "current", 6: -1, 2: 1.6}, {0: "current", 6: 0, 2: 1.7}] 6 | 7 | -------------------------------------------------------------------------------- /ex3.gen.cbor.hex: -------------------------------------------------------------------------------- 1 | 0000 87 a7 21 78 1b 75 72 6e 3a 64 65 76 3a 6f 77 3a |..!x.urn:dev:ow:| 2 | 0010 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 3a |10e2073a0108006:| 3 | 0020 22 fb 41 d3 03 a1 5b 00 10 62 23 61 41 20 05 00 |".A...[..b#aA ..| 4 | 0030 67 76 6f 6c 74 61 67 65 01 61 56 02 fb 40 5e 06 |gvoltage.aV..@^.| 5 | 0040 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e 74 06 |fffff..gcurrent.| 6 | 0050 24 02 fb 3f f3 33 33 33 33 33 33 a3 00 67 63 75 |$..?.333333..gcu| 7 | 0060 72 72 65 6e 74 06 23 02 fb 3f f4 cc cc cc cc cc |rrent.#..?......| 8 | 0070 cd a3 00 67 63 75 72 72 65 6e 74 06 22 02 fb 3f |...gcurrent."..?| 9 | 0080 f6 66 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e |.ffffff..gcurren| 10 | 0090 74 06 21 02 f9 3e 00 a3 00 67 63 75 72 72 65 6e |t.!..>...gcurren| 11 | 00a0 74 06 20 02 fb 3f f9 99 99 99 99 99 9a a3 00 67 |t. ..?.........g| 12 | 00b0 63 75 72 72 65 6e 74 06 00 02 fb 3f fb 33 33 33 |current....?.333| 13 | 00c0 33 33 33 |333| 14 | 00c3 15 | -------------------------------------------------------------------------------- /ex3.gen.cbor.txt: -------------------------------------------------------------------------------- 1 | 87 # array(7) 2 | a7 # map(7) 3 | 21 # negative(1) 4 | 78 1b # text(27) 5 | 75726e3a ... 030363a # "urn:dev:ow:10e2073a0108006:" 6 | 22 # negative(2) 7 | fb 41d303a15b001062 # primitive(4743138824102613090) 8 | 23 # negative(3) 9 | 61 # text(1) 10 | 41 # "A" 11 | 20 # negative(0) 12 | 05 # unsigned(5) 13 | 00 # unsigned(0) 14 | 67 # text(7) 15 | 766f6c74616765 # "voltage" 16 | 01 # unsigned(1) 17 | 61 # text(1) 18 | 56 # "V" 19 | 02 # unsigned(2) 20 | fb 405e066666666666 # primitive(4638151703112607334) 21 | a3 # map(3) 22 | 00 # unsigned(0) 23 | 67 # text(7) 24 | 63757272656e74 # "current" 25 | 06 # unsigned(6) 26 | 24 # negative(4) 27 | 02 # unsigned(2) 28 | fb 3ff3333333333333 # primitive(4608083138725491507) 29 | a3 # map(3) 30 | 00 # unsigned(0) 31 | 67 # text(7) 32 | 63757272656e74 # "current" 33 | 06 # unsigned(6) 34 | 23 # negative(3) 35 | 02 # unsigned(2) 36 | fb 3ff4cccccccccccd # primitive(4608533498688228557) 37 | a3 # map(3) 38 | 00 # unsigned(0) 39 | 67 # text(7) 40 | 63757272656e74 # "current" 41 | 06 # unsigned(6) 42 | 22 # negative(2) 43 | 02 # unsigned(2) 44 | fb 3ff6666666666666 # primitive(4608983858650965606) 45 | a3 # map(3) 46 | 00 # unsigned(0) 47 | 67 # text(7) 48 | 63757272656e74 # "current" 49 | 06 # unsigned(6) 50 | 21 # negative(1) 51 | 02 # unsigned(2) 52 | f9 3e00 # primitive(15872) 53 | a3 # map(3) 54 | 00 # unsigned(0) 55 | 67 # text(7) 56 | 63757272656e74 # "current" 57 | 06 # unsigned(6) 58 | 20 # negative(0) 59 | 02 # unsigned(2) 60 | fb 3ff999999999999a # primitive(4609884578576439706) 61 | a3 # map(3) 62 | 00 # unsigned(0) 63 | 67 # text(7) 64 | 63757272656e74 # "current" 65 | 06 # unsigned(6) 66 | 00 # unsigned(0) 67 | 02 # unsigned(2) 68 | fb 3ffb333333333333 # primitive(4610334938539176755) 69 | -------------------------------------------------------------------------------- /ex3.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a0108006:","bt":1.276020076001e+09,"bu":"A","bver":5,"n":"voltage","u":"V","v":120.1}, 3 | {"n":"current","t":-5,"v":1.2}, 4 | {"n":"current","t":-4,"v":1.3}, 5 | {"n":"current","t":-3,"v":1.4}, 6 | {"n":"current","t":-2,"v":1.5}, 7 | {"n":"current","t":-1,"v":1.6}, 8 | {"n":"current","v":1.7} 9 | ] 10 | -------------------------------------------------------------------------------- /ex3.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a0108006:voltage","u":"V","t":1.276020076001e+09,"v":120.1}, 3 | {"n":"urn:dev:ow:10e2073a0108006:current","u":"A","t":1.276020071001e+09,"v":1.2}, 4 | {"n":"urn:dev:ow:10e2073a0108006:current","u":"A","t":1.276020072001e+09,"v":1.3}, 5 | {"n":"urn:dev:ow:10e2073a0108006:current","u":"A","t":1.276020073001e+09,"v":1.4}, 6 | {"n":"urn:dev:ow:10e2073a0108006:current","u":"A","t":1.276020074001e+09,"v":1.5}, 7 | {"n":"urn:dev:ow:10e2073a0108006:current","u":"A","t":1.276020075001e+09,"v":1.6}, 8 | {"n":"urn:dev:ow:10e2073a0108006:current","u":"A","t":1.276020076001e+09,"v":1.7} 9 | ] 10 | -------------------------------------------------------------------------------- /ex3.gen.wrap.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a0108006:","bt":1.276020076001e+09, 3 | "bu":"A","bver":5, 4 | "n":"voltage","u":"V","v":120.1}, 5 | {"n":"current","t":-5,"v":1.2}, 6 | {"n":"current","t":-4,"v":1.3}, 7 | {"n":"current","t":-3,"v":1.4}, 8 | {"n":"current","t":-2,"v":1.5}, 9 | {"n":"current","t":-1,"v":1.6}, 10 | {"n":"current","v":1.7} 11 | ] 12 | -------------------------------------------------------------------------------- /ex3.gen.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | -------------------------------------------------------------------------------- /ex3.json: -------------------------------------------------------------------------------- 1 | [{"bn": "urn:dev:ow:10e2073a0108006:", 2 | "bt": 1276020076.001, 3 | "bu": "A", 4 | "bver": 5, 5 | "n": "voltage", "u": "V", "v": 120.1 }, 6 | { "n": "current", "t": -5, "v": 1.2 }, 7 | { "n": "current", "t": -4, "v": 1.30 }, 8 | { "n": "current", "t": -3, "v": 0.14e1 }, 9 | { "n": "current", "t": -2, "v": 1.5 }, 10 | { "n": "current", "t": -1, "v": 1.6 }, 11 | { "n": "current", "t": 0, "v": 1.7 } 12 | ] 13 | -------------------------------------------------------------------------------- /ex4.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09,"bu":"%RH","v":21.2}, 3 | {"t":10,"v":21.3}, 4 | {"t":20,"v":21.4}, 5 | {"t":30,"v":21.4}, 6 | {"t":40,"v":21.5}, 7 | {"t":50,"v":21.5}, 8 | {"t":60,"v":21.5}, 9 | {"t":70,"v":21.6}, 10 | {"t":80,"v":21.7}, 11 | {"t":90,"v":21.5}, 12 | {"t":91,"v":21.5}, 13 | {"t":92,"v":21.5} 14 | ] 15 | -------------------------------------------------------------------------------- /ex4.gen.json-trim: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09, 3 | "bu":"%RH","v":21.2}, 4 | {"t":10,"v":21.3}, 5 | {"t":20,"v":21.4}, 6 | {"t":30,"v":21.4}, 7 | {"t":40,"v":21.5}, 8 | {"t":50,"v":21.5}, 9 | {"t":60,"v":21.5}, 10 | {"t":70,"v":21.6}, 11 | {"t":80,"v":21.7}, 12 | -------------------------------------------------------------------------------- /ex4.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09,"v":21.2}, 3 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067474e+09,"v":21.3}, 4 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067484e+09,"v":21.4}, 5 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067494e+09,"v":21.4}, 6 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067504e+09,"v":21.5}, 7 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067514e+09,"v":21.5}, 8 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067524e+09,"v":21.5}, 9 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067534e+09,"v":21.6}, 10 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067544e+09,"v":21.7}, 11 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067554e+09,"v":21.5}, 12 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067555e+09,"v":21.5}, 13 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067556e+09,"v":21.5} 14 | ] 15 | -------------------------------------------------------------------------------- /ex4.gen.wrap.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09, 3 | "bu":"%RH","v":21.2}, 4 | {"t":10,"v":21.3}, 5 | {"t":20,"v":21.4}, 6 | {"t":30,"v":21.4}, 7 | {"t":40,"v":21.5}, 8 | {"t":50,"v":21.5}, 9 | {"t":60,"v":21.5}, 10 | {"t":70,"v":21.6}, 11 | {"t":80,"v":21.7}, 12 | {"t":90,"v":21.5}, 13 | {"t":91,"v":21.5}, 14 | {"t":92,"v":21.5} 15 | ] 16 | -------------------------------------------------------------------------------- /ex4.json: -------------------------------------------------------------------------------- 1 | [ {"bn": "urn:dev:ow:10e2073a01080063", 2 | "bt": 1320067464, 3 | "bu": "%RH", 4 | "v": 21.2, "t": 0 }, 5 | { "v": 21.3, "t": 10 }, 6 | { "v": 21.4, "t": 20 }, 7 | { "v": 21.4, "t": 30 }, 8 | { "v": 21.5, "t": 40 }, 9 | { "v": 21.5, "t": 50 }, 10 | { "v": 21.5, "t": 60 }, 11 | { "v": 21.6, "t": 70 }, 12 | { "v": 21.7, "t": 80 }, 13 | { "v": 21.5, "t": 90 }, 14 | { "v": 21.5, "t": 91 }, 15 | { "v": 21.5, "t": 92 } 16 | ] 17 | -------------------------------------------------------------------------------- /ex5.gen.cbor: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/ex5.gen.cbor -------------------------------------------------------------------------------- /ex5.gen.exi: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/ex5.gen.exi -------------------------------------------------------------------------------- /ex5.gen.exi.hex: -------------------------------------------------------------------------------- 1 | 0000 a0 30 0d 84 80 eb ab 93 71 d3 23 2b b1 d3 7b b9 |.0......q.#+..{.| 2 | 0010 d1 89 83 29 91 81 b9 9b 09 81 89 81 c1 81 81 b1 |...)............| 3 | 0020 98 a2 30 ee bd 41 00 00 0a 4a a4 90 e0 20 0e 90 |..0..A...J... ..| 4 | 0030 56 c6 f6 e2 9d ad 94 01 82 69 05 6c 61 74 29 dd |V........i.lat).| 5 | 0040 9e e0 28 26 80 30 05 32 c0 60 1a 00 c0 10 00 29 |..(&.0.2.`.....)| 6 | 0050 ea d9 40 18 26 80 30 04 00 4a 77 67 b8 0a 09 a0 |..@.&.0..Jwg....| 7 | 0060 18 01 4c f0 18 06 80 60 04 00 0a 7e b6 50 06 09 |..L....`...~.P..| 8 | 0070 a0 18 01 00 12 9e d9 ee 02 82 68 07 80 40 29 2a |..........h..@)*| 9 | 0080 2a 61 31 00 34 04 80 29 a8 03 00 d0 12 00 80 00 |*a1.4..)........| 10 | 0090 a9 2b 65 00 60 9a 02 40 10 00 94 fe cf 70 14 13 |.+e.`..@.....p..| 11 | 00a0 80 |.| 12 | 00a1 13 | -------------------------------------------------------------------------------- /ex5.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09,"bu":"%RH","v":20}, 3 | {"u":"lon","v":24.30621}, 4 | {"u":"lat","v":60.07965}, 5 | {"t":60,"v":20.3}, 6 | {"u":"lon","t":60,"v":24.30622}, 7 | {"u":"lat","t":60,"v":60.07965}, 8 | {"t":120,"v":20.7}, 9 | {"u":"lon","t":120,"v":24.30623}, 10 | {"u":"lat","t":120,"v":60.07966}, 11 | {"u":"%EL","t":150,"v":98}, 12 | {"t":180,"v":21.2}, 13 | {"u":"lon","t":180,"v":24.30628}, 14 | {"u":"lat","t":180,"v":60.07967} 15 | ] 16 | -------------------------------------------------------------------------------- /ex5.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09,"v":20}, 3 | {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09,"v":24.30621}, 4 | {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067464e+09,"v":60.07965}, 5 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067524e+09,"v":20.3}, 6 | {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067524e+09,"v":24.30622}, 7 | {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067524e+09,"v":60.07965}, 8 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067584e+09,"v":20.7}, 9 | {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067584e+09,"v":24.30623}, 10 | {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067584e+09,"v":60.07966}, 11 | {"n":"urn:dev:ow:10e2073a01080063","u":"%EL","t":1.320067614e+09,"v":98}, 12 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067644e+09,"v":21.2}, 13 | {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067644e+09,"v":24.30628}, 14 | {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067644e+09,"v":60.07967} 15 | ] 16 | -------------------------------------------------------------------------------- /ex5.gen.resolved.wrap.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09, 3 | "v":20}, 4 | {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09, 5 | "v":24.30621}, 6 | {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067464e+09, 7 | "v":60.07965}, 8 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067524e+09, 9 | "v":20.3}, 10 | {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067524e+09, 11 | "v":24.30622}, 12 | {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067524e+09, 13 | "v":60.07965}, 14 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067584e+09, 15 | "v":20.7}, 16 | {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067584e+09, 17 | "v":24.30623}, 18 | {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067584e+09, 19 | "v":60.07966}, 20 | {"n":"urn:dev:ow:10e2073a01080063","u":"%EL","t":1.320067614e+09, 21 | "v":98}, 22 | {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067644e+09, 23 | "v":21.2}, 24 | {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067644e+09, 25 | "v":24.30628}, 26 | {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067644e+09, 27 | "v":60.07967} 28 | ] 29 | -------------------------------------------------------------------------------- /ex5.gen.wrap.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09, 3 | "bu":"%RH","v":20}, 4 | {"u":"lon","v":24.30621}, 5 | {"u":"lat","v":60.07965}, 6 | {"t":60,"v":20.3}, 7 | {"u":"lon","t":60,"v":24.30622}, 8 | {"u":"lat","t":60,"v":60.07965}, 9 | {"t":120,"v":20.7}, 10 | {"u":"lon","t":120,"v":24.30623}, 11 | {"u":"lat","t":120,"v":60.07966}, 12 | {"u":"%EL","t":150,"v":98}, 13 | {"t":180,"v":21.2}, 14 | {"u":"lon","t":180,"v":24.30628}, 15 | {"u":"lat","t":180,"v":60.07967} 16 | ] 17 | -------------------------------------------------------------------------------- /ex5.gen.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /ex5.json: -------------------------------------------------------------------------------- 1 | [{"bn": "urn:dev:ow:10e2073a01080063", 2 | "bt": 1320067464, 3 | "bu": "%RH", 4 | "v": 20.0, "t": 0 }, 5 | { "v": 24.30621, "u": "lon", "t": 0 }, 6 | { "v": 60.07965, "u": "lat", "t": 0 }, 7 | { "v": 20.3, "t": 60 }, 8 | { "v": 24.30622, "u": "lon", "t": 60 }, 9 | { "v": 60.07965, "u": "lat", "t": 60 }, 10 | { "v": 20.7, "t": 120 }, 11 | { "v": 24.30623, "u": "lon", "t": 120 }, 12 | { "v": 60.07966, "u": "lat", "t": 120 }, 13 | { "v": 98.0, "u": "%EL", "t": 150 }, 14 | { "v": 21.2, "t": 180 }, 15 | { "v": 24.30628, "u": "lon", "t": 180 }, 16 | { "v": 60.07967, "u": "lat", "t": 180 } 17 | ] 18 | -------------------------------------------------------------------------------- /ex6.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"2001:db8::2/","bt":1.320078429e+09,"n":"temperature","u":"Cel","v":25.2}, 3 | {"n":"humidity","u":"%RH","v":30}, 4 | {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3}, 5 | {"n":"humidity","u":"%RH","v":67} 6 | ] 7 | -------------------------------------------------------------------------------- /ex6.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"2001:db8::2/temperature","u":"Cel","t":1.320078429e+09,"v":25.2}, 3 | {"n":"2001:db8::2/humidity","u":"%RH","t":1.320078429e+09,"v":30}, 4 | {"n":"2001:db8::1/temperature","u":"Cel","t":1.320078429e+09,"v":12.3}, 5 | {"n":"2001:db8::1/humidity","u":"%RH","t":1.320078429e+09,"v":67} 6 | ] 7 | -------------------------------------------------------------------------------- /ex6.gen.wrap.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"2001:db8::2/","bt":1.320078429e+09, 3 | "n":"temperature","u":"Cel","v":25.2}, 4 | {"n":"humidity","u":"%RH","v":30}, 5 | {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3}, 6 | {"n":"humidity","u":"%RH","v":67} 7 | ] 8 | -------------------------------------------------------------------------------- /ex6.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn": "2001:db8::2/", 3 | "bt": 1320078429, 4 | "n": "temperature", "v": 25.2, "u": "Cel" }, 5 | { "n": "humidity", "v": 30, "u": "%RH" }, 6 | {"bn": "2001:db8::1/", 7 | "n": "temperature", "v": 12.3, "u": "Cel" }, 8 | { "n": "humidity", "v": 67, "u": "%RH" } 9 | ] 10 | -------------------------------------------------------------------------------- /ex7.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":23.1}, 3 | {"n":"label","vs":"Machine Room"}, 4 | {"n":"open","vb":false}, 5 | {"n":"nfv-reader","vd":"aGkgCg"} 6 | ] 7 | -------------------------------------------------------------------------------- /ex7.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063:temp","u":"Cel","t":1.499109309e+09,"v":23.1}, 3 | {"n":"urn:dev:ow:10e2073a01080063:label","t":1.499109309e+09,"vs":"Machine Room"}, 4 | {"n":"urn:dev:ow:10e2073a01080063:open","t":1.499109309e+09,"vb":false} 5 | ] 6 | -------------------------------------------------------------------------------- /ex7.json: -------------------------------------------------------------------------------- 1 | [ 2 | { "bn": "urn:dev:ow:10e2073a01080063:", "n":"temp", "v":23.1, "u":"Cel" }, 3 | { "n":"label", "vs":"Machine Room" }, 4 | { "n":"open", "vb": false }, 5 | { "n":"nfv-reader", "vd":"aGkgCg" } 6 | ] 7 | -------------------------------------------------------------------------------- /ex8.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063:","bt":1.320078429e+09,"l":"[{\"href\":\"humidity\",\"foo\":\"bar\"}]","n":"temperature","u":"Cel","v":27.2}, 3 | {"n":"humidity","u":"%RH","v":80} 4 | ] 5 | -------------------------------------------------------------------------------- /ex8.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"l":"[{\"href\":\"humidity\",\"foo\":\"bar\"}]","n":"urn:dev:ow:10e2073a01080063:temperature","u":"Cel","t":1.320078429e+09,"v":27.2}, 3 | {"n":"urn:dev:ow:10e2073a01080063:humidity","u":"%RH","t":1.320078429e+09,"v":80} 4 | ] 5 | -------------------------------------------------------------------------------- /ex8.gen.wrap.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063:","bt":1.320078429e+09, 3 | "l":"[{\"href\":\"humidity\",\"foo\":\"bar\"}]", 4 | "n":"temperature","u":"Cel","v":27.2}, 5 | {"n":"humidity","u":"%RH","v":80} 6 | ] 7 | -------------------------------------------------------------------------------- /ex8.gen.xml: -------------------------------------------------------------------------------- 1 | 2 | 5 | 6 | 7 | -------------------------------------------------------------------------------- /ex8.json: -------------------------------------------------------------------------------- 1 | [{"bn": "urn:dev:ow:10e2073a01080063:", 2 | "bt": 1320078429, 3 | "l": "[{\"href\":\"humidity\",\"foo\":\"bar\"}]", 4 | "n": "temperature", "v": 27.2, "u": "Cel" }, 5 | { "n": "humidity", "v": 80, "u": "%RH" } 6 | ] 7 | -------------------------------------------------------------------------------- /ex9.gen.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063:"}, 3 | {"n":"temp","u":"Cel","v":23.1}, 4 | {"n":"heat","u":"/","v":1}, 5 | {"n":"fan","u":"/","v":0} 6 | ] 7 | -------------------------------------------------------------------------------- /ex9.gen.resolved.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"n":"urn:dev:ow:10e2073a01080063:temp","u":"Cel","t":1.498780179e+09,"v":23.1}, 3 | {"n":"urn:dev:ow:10e2073a01080063:heat","u":"/","t":1.498780179e+09,"v":1}, 4 | {"n":"urn:dev:ow:10e2073a01080063:fan","u":"/","t":1.498780179e+09,"v":0} 5 | ] 6 | -------------------------------------------------------------------------------- /ex9.json: -------------------------------------------------------------------------------- 1 | [ 2 | {"bn":"urn:dev:ow:10e2073a01080063:"}, 3 | {"n":"temp","u":"Cel","v":23.1}, 4 | {"n":"heat","u":"/","v":1}, 5 | {"n":"fan","u":"/","v":0} 6 | ] 7 | -------------------------------------------------------------------------------- /example/ExiProcessor.jar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/example/ExiProcessor.jar -------------------------------------------------------------------------------- /example/Makefile: -------------------------------------------------------------------------------- 1 | 2 | 3 | SRC := $(wildcard draft-*.xml) 4 | 5 | HTML := $(patsubst %.xml,%.html,$(SRC)) 6 | TXT := $(patsubst %.xml,%.txt,$(SRC)) 7 | DIF := $(patsubst %.xml,%.diff.html,$(SRC)) 8 | 9 | all: $(HTML) $(TXT) $(DIF) senml-simple.exi senml.exi 10 | 11 | #please, instead of chsning S2B here, amke S2B be on your path 12 | S2B=s2x.pl -e 13 | #S2B=/home/ekr/doc/ietf-drafts/ekr/s2b/s2x.pl 14 | #S2B = cp 15 | 16 | draft-ietf-p2psip-reload.ixml: draft-ietf-p2psip-reload.xml 17 | $(S2B) $< $@ 18 | 19 | draft-ietf-p2psip-reload.txt: draft-ietf-p2psip-reload.ixml 20 | xml2rfc $^ $@ 21 | 22 | draft-ietf-p2psip-reload.html: draft-ietf-p2psip-reload.ixml 23 | xml2rfc $^ $@ 24 | 25 | 26 | #%.html: %.xml 27 | # xsltproc -o $@ rfc2629.xslt $^ 28 | 29 | %.html: %.xml 30 | xml2rfc $^ $@ 31 | 32 | 33 | %.txt: %.xml 34 | xml2rfc $^ $@ 35 | 36 | %.diff.html: %.txt 37 | htmlwdiff $^.old $^ > $@ 38 | 39 | %.exi: %.xml 40 | java -jar ExiProcessor.jar -xml_in $^ -exi_out $@ -schema senml.xsd \ 41 | -alignment bit_packed -strict -header_options -schemaID a 42 | 43 | # decode 44 | # java -jar ExiProcessor.jar -exi_in senml-simple.exi -schema senml.xsd -xml_out foo.xml -alignment byte_packed 45 | 46 | #senml.exi: senml.xml 47 | # java -jar ExiProcessor.jar -xml_in $^ -exi_out $@ -schema senml.xsd -schemaID a -compression 48 | 49 | 50 | senml-simple.exi: senml-simple.xml 51 | java -jar ExiProcessor.jar -xml_in $^ -exi_out $@ -schema senml.xsd \ 52 | -alignment byte_packed -strict -header_options -schemaID a 53 | 54 | senml-temp.exi: senml-temp.xml 55 | java -jar ExiProcessor.jar -xml_in $^ -exi_out $@ -schema senml.xsd \ 56 | -alignment byte_packed -strict -header_options -schemaID a 57 | 58 | 59 | %.dec.xml: %.exi 60 | java -jar ExiProcessor.jar -exi_in $^ -xml_out $@ 61 | 62 | -------------------------------------------------------------------------------- /example/jing.jar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/example/jing.jar -------------------------------------------------------------------------------- /example/senml-simple.exi: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/example/senml-simple.exi -------------------------------------------------------------------------------- /example/senml-simple.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | -------------------------------------------------------------------------------- /example/senml-temp.exi: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/example/senml-temp.exi -------------------------------------------------------------------------------- /example/senml-temp.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /example/senml.exi: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/example/senml.exi -------------------------------------------------------------------------------- /example/senml.json: -------------------------------------------------------------------------------- 1 | {"e":[ 2 | { "n": "voltage", "u": "V", 3 | "v": 120.1, "anExtension": 0.0 }, 4 | { "n": "current", "t": -5, "v": 1.2 }, 5 | { "n": "current", "t": -4, "v": 1.30 }, 6 | { "n": "current", "t": -3, "v": 0.14e1 }, 7 | { "n": "current", "t": -2, "v": 1.5 }, 8 | { "n": "current", "t": -1, "v": 1.6 }, 9 | { "n": "current", "t": 0, "v": 1.7 } 10 | ], 11 | "bn": "0017f202a5c4-", 12 | "bt": 1276020076, 13 | "someExtensions": "a value" 14 | } 15 | -------------------------------------------------------------------------------- /example/senml.rnc: -------------------------------------------------------------------------------- 1 | default namespace = "urn:ietf:params:xml:ns:senml" 2 | namespace rng = "http://relaxng.org/ns/structure/1.0" 3 | 4 | p = element p { 5 | attribute n { xsd:string }?, 6 | attribute v { xsd:float }?, 7 | attribute sv { xsd:string }?, 8 | attribute bv { xsd:boolean }? 9 | } 10 | 11 | e = element e { 12 | attribute n { xsd:string }?, 13 | attribute u { xsd:string }?, 14 | attribute v { xsd:float }?, 15 | attribute sv { xsd:string }?, 16 | attribute bv { xsd:boolean }?, 17 | attribute s { xsd:decimal }?, 18 | attribute t { xsd:integer }?, 19 | attribute ut { xsd:integer }?, 20 | p* 21 | } 22 | 23 | senml = 24 | element senml { 25 | attribute bn { xsd:string }?, 26 | attribute bt { xsd:integer }?, 27 | attribute bu { xsd:string }?, 28 | attribute ver { xsd:integer }?, 29 | e*, 30 | p* 31 | } 32 | 33 | start = senml 34 | -------------------------------------------------------------------------------- /example/senml.rng: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | -------------------------------------------------------------------------------- /example/senml.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 |

7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /example/senml.xsd: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /example/trang.jar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/core-wg/senml-spec/aced339e9aafd7675024e5c6c46a19d564506e90/example/trang.jar -------------------------------------------------------------------------------- /lib/addstyle.sed: -------------------------------------------------------------------------------- 1 | \~~ { a\ 2 | 6 | } 7 | -------------------------------------------------------------------------------- /lib/style.css: -------------------------------------------------------------------------------- 1 | @viewport { 2 | zoom: 1.0; 3 | width: extend-to-zoom; 4 | } 5 | 6 | @-ms-viewport { 7 | width: extend-to-zoom; 8 | zoom: 1.0; 9 | } 10 | 11 | body { 12 | font: 11pt cambria, helvetica, arial, sans-serif; 13 | font-size-adjust: 0.5; 14 | line-height: 130%; 15 | margin: 1em auto; 16 | max-width: 700px; 17 | } 18 | 19 | .title, .filename, h1, h2, h3, h4 { 20 | font-family: candara, helvetica, arial, sans-serif; 21 | font-size-adjust: 0.5; 22 | } 23 | .title { font-size: 150%; } 24 | h1 { font-size: 130%; } 25 | h2 { font-size: 120%; } 26 | h3, h4 { font-size: 110%; } 27 | ul.toc >li { font-size: 95%; } 28 | ul.toc >li >ul, .figure, caption { font-size: 90%; } 29 | 30 | table { 31 | margin-left: 0em; 32 | } 33 | table.header { 34 | width: 100%; 35 | } 36 | 37 | table.header td { 38 | background-color: inherit; 39 | color: black; 40 | } 41 | 42 | samp, tt, code, pre { 43 | font: 11pt consolas, monospace; 44 | font-size-adjust: none; 45 | } 46 | 47 | pre.text, pre.text2 { 48 | width: 90%; 49 | } 50 | 51 | dt { 52 | float: left; clear: left; 53 | margin: 0.5em 0.5em 0 0; 54 | } 55 | dt:first-child { 56 | margin-top: 0; 57 | } 58 | dd { 59 | margin: 0.5em 0 0 2em; 60 | } 61 | dd p, dd ul { 62 | margin-top: 0; margin-bottom: 0; 63 | } 64 | dd *+p { 65 | margin-top: 0.5em; 66 | } 67 | 68 | ol, ul { 69 | padding: 0; 70 | margin: 0.5em 0 0.5em 2em; 71 | } 72 | ul.toc, ul.toc ul { 73 | margin: 0 0 0 1.5em; 74 | } 75 | ul.toc a:first-child { 76 | display: inline-block; 77 | min-width: 1.2em; 78 | } -------------------------------------------------------------------------------- /senml-cbor.cddl: -------------------------------------------------------------------------------- 1 | bver = -1 n = 0 s = 5 2 | bn = -2 u = 1 t = 6 3 | bt = -3 v = 2 ut = 7 4 | bu = -4 vs = 3 vd = 8 5 | bv = -5 vb = 4 6 | bs = -6 7 | 8 | binary-value = bstr 9 | -------------------------------------------------------------------------------- /senml-json.cddl: -------------------------------------------------------------------------------- 1 | bver = "bver" n = "n" s = "s" 2 | bn = "bn" u = "u" t = "t" 3 | bt = "bt" v = "v" ut = "ut" 4 | bu = "bu" vs = "vs" vd = "vd" 5 | bv = "bv" vb = "vb" 6 | bs = "bs" 7 | 8 | binary-value = tstr ; base64url encoded 9 | -------------------------------------------------------------------------------- /senml-json2cbor.rb: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env ruby 2 | 3 | # ruby senml2cbor.rb senml-data.json > senml-data.cbor 4 | # (reads from stdin if no argument given) 5 | # 6 | # Installation: do `gem install cbor` first 7 | 8 | require 'json' 9 | require 'cbor' 10 | 11 | MAPPINGS = Hash.new {|h, k| k} 12 | 13 | DATA.read.scan(/([-\w]+)\s*=\s*([-\w]+)/) do |n, v| 14 | begin 15 | MAPPINGS[n] = Integer(v) 16 | rescue ArgumentError 17 | end 18 | end 19 | 20 | # p MAPPINGS 21 | 22 | class Array 23 | def cborify_senml 24 | map(&:cborify_senml) 25 | end 26 | end 27 | 28 | class Hash 29 | def cborify_senml 30 | Hash[map { |k, v| 31 | [MAPPINGS[k], v.cborify_senml] 32 | }] 33 | end 34 | end 35 | 36 | # This hacks off precision to 10 bits of mantissa so CBOR can generate 37 | # half floats. Optional. Comment out if undesired. 38 | #class Float 39 | # def cborify_senml 40 | # short = [[self].pack("g").unpack("N")[0] & 0xFFFFE000].pack("N").unpack("g")[0] 41 | # # warn [short, short.to_cbor.size].inspect 42 | # if short.to_cbor.size == 3 43 | # short 44 | # else 45 | # self 46 | # end 47 | # end 48 | #end 49 | 50 | class Object 51 | def cborify_senml 52 | self 53 | end 54 | end 55 | 56 | data = JSON.load(ARGF) 57 | # p data.cborify_senml 58 | print data.cborify_senml.to_cbor 59 | 60 | # Below, a copy of senml-cbor.cddl so this is a freestanding program; 61 | # need to remember to update this copy whenever we update 62 | # senml-cbor.cddl 63 | __END__ 64 | 65 | bver = -1 n = 0 s = 5 66 | bn = -2 u = 1 t = 6 67 | bt = -3 v = 2 ut = 7 68 | bu = -4 vs = 3 vd = 8 69 | bv = -5 vb = 4 70 | bs = -6 71 | 72 | binary-value = bstr 73 | -------------------------------------------------------------------------------- /senml.cddl: -------------------------------------------------------------------------------- 1 | 2 | SenML-Pack = [1* record] 3 | 4 | record = { 5 | ? bn => tstr, ; Base Name 6 | ? bt => numeric, ; Base Time 7 | ? bu => tstr, ; Base Units 8 | ? bv => numeric, ; Base Value 9 | ? bs => numeric, ; Base Sum 10 | ? bver => uint, ; Base Version 11 | ? n => tstr, ; Name 12 | ? u => tstr, ; Units 13 | ? s => numeric, ; Value Sum 14 | ? t => numeric, ; Time 15 | ? ut => numeric, ; Update Time 16 | ? ( v => numeric // ; Numeric Value 17 | vs => tstr // ; String Value 18 | vb => bool // ; Boolean Value 19 | vd => binary-value ) ; Data Value 20 | * key-value-pair 21 | } 22 | 23 | ; now define the generic versions 24 | key-value-pair = ( label => value ) 25 | 26 | label = non-b-label / b-label 27 | non-b-label = tstr .regexp "[A-Zac-z0-9][-_:.A-Za-z0-9]*" / uint 28 | b-label = tstr .regexp "b[-_:.A-Za-z0-9]+" / nint 29 | 30 | value = tstr / binary-value / numeric / bool 31 | numeric = number / decfrac 32 | -------------------------------------------------------------------------------- /senml.gen.xsd: -------------------------------------------------------------------------------- 1 | 2 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /senml.rnc: -------------------------------------------------------------------------------- 1 | default namespace = "urn:ietf:params:xml:ns:senml" 2 | namespace rng = "http://relaxng.org/ns/structure/1.0" 3 | 4 | senml = element senml { 5 | attribute bn { xsd:string }?, 6 | attribute bt { xsd:double }?, 7 | attribute bv { xsd:double }?, 8 | attribute bs { xsd:double }?, 9 | attribute bu { xsd:string }?, 10 | attribute bver { xsd:int }?, 11 | 12 | attribute n { xsd:string }?, 13 | attribute s { xsd:double }?, 14 | attribute t { xsd:double }?, 15 | attribute u { xsd:string }?, 16 | attribute ut { xsd:double }?, 17 | 18 | attribute v { xsd:double }?, 19 | attribute vb { xsd:boolean }?, 20 | attribute vs { xsd:string }?, 21 | attribute vd { xsd:string }? 22 | } 23 | 24 | sensml = 25 | element sensml { 26 | senml+ 27 | } 28 | 29 | start = sensml 30 | -------------------------------------------------------------------------------- /size.md: -------------------------------------------------------------------------------- 1 | | Encoding | Size | Compressed Size | 2 | | JSON | 573 | 206 | 3 | | XML | 649 | 235 | 4 | | CBOR | 254 | 196 | 5 | | EXI | 161 | 184 | 6 | --------------------------------------------------------------------------------