One document matched: draft-jennings-energy-pricing-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="no"?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-jennings-energy-pricing-00"
ipr="trust200902">
<front>
<title abbrev="Energy Pricing">Communication of Energy Pricing
Information</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<date day="7" month="March" year="2011" />
<abstract>
<t>This specification defines media types for representing the future
price of energy in JSON. It also defines a way for a client device, such
as an electric car, to discover a web server that can provide the future
pricing for local electrical energy. This will allow the client device
to make intelligent decisions about when to use energy. </t>
<t>This draft is a very early skeleton of a draft to start discussion
around this idea.</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>Many uses of energy can be shifted in time. Consider charging an
electric car. When the users plugs in a car at 9pm, they may not care
when it actually charges, as long as it is ready at 8AM when they need
to go to work. This is a classic real time problem and can be optimized
as long as the charger for the car has relevant information about how
long it will take to charge and the cost of electricity between the
current time and the time when the task needs to be complete. </t>
<t>This specification defines a simple JSON<xref
target="RFC4627"></xref>media type to provide the cost of energy at
future points of time. It is an array of objects in which each object
contains the time a new price will come into effect and the price at
that time. JSON also defines a well known URL on a web server so that an
HTTP client can retrieve this data. Finally as a way to automatically
discover the web server, this specification defines a DHCP option to
provide the host name of the web server. </t>
<t>Consider a typical residence with broadband internet and a
residential gateway that gets its IP address via DHCP from the service
provider. The service provider would provide the domain of the local
power provider via DHCP. The residential gateway would get this and
provide it in DHCP requests sent to the residential gateway. The
residential gateway would also be able to override this, so if the
consumer had arranged power from an alternative power provider, the name
of that provider could be configured in the device. </t>
<t>A device on the residential network, such as a dishwasher, could find
the energy provider name via DHCP. The dishwasher would then make an
HTTP GET request to the well known URI defined in this specification. In
other words, it would do an HTTP GET to the
/.well_known/energy-price.json and would receive back an
energyprice+json media type. For example </t>
<figure>
<artwork><![CDATA[
{
"currency" : "USD",
"prices":[
{ "time": "2011-04-12T23:20:00.00Z", "price": "0.028" },
{ "time": "2011-04-12T23:21:00.00Z", "price": "0.025" },
{ "time": "2011-04-12T23:22:00.00Z", "price": "0.021" }
]}]]></artwork>
</figure>
<t>The above example shows a case where at 21:00 UTC, the price falls
from 2.8 cents per KWh to 2.5 cents per KWh. </t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Semantics">
<t>Each media type carries a single JSON object that represents a set of
prices and times. This object contains optional attributes described
below and a mandatory array of one or more measurements.</t>
<t><list style="hanging">
<t hangText="validTill:">Time at which this data will become
invalid. UTC time in RFC 3339 format. </t>
<t hangText="currency:">Optional. Specify currency in ISO 4217 [REF]
currency code. </t>
<t hangText="prices:">Array of price change objects. Mandatory and
there must be at least one object in the array. Objects MUST be
ordered in this array by time. </t>
</list></t>
<t>Each price time object contains several attributes, some of which are
optional and some of which are mandatory.</t>
<t><list style="hanging">
<t hangText="time:">Time this price becomes effective. UTC time in
RFC 3339 format. </t>
<t hangText="price:">Price per KWh starting. The cost of energy
changes to this price at the time in this object and remains at this
price until the time of the next object in the prices array. </t>
</list></t>
<t>Open Issue: What is the best representation for time?</t>
<t>Open Issue: Is it OK that currency is optional?</t>
<t>Open Issue: How many entries can the array have? It would be nice to
have some maximum size. </t>
</section>
<section title="Well Known URL ">
<t>A client that implements this specification uses the path
"//.well-known/energy-price.json" for the resource name unless the
client has been configured with an alternative path. </t>
</section>
<section title="DHCP">
<t>Open Issues: Is DHCP the best approach to discovery or would
something else be better?</t>
</section>
<section title="IANA Considerations">
<t>Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with
the RFC number of this specification.</t>
<section title="Well-Known URI Registration">
<t>IANA will make the following "Well Known URI" registration as
described in RFC 5785:</t>
<texttable>
<ttcol></ttcol>
<ttcol></ttcol>
<c>URI suffix:</c>
<c>energy-price.json</c>
<c>Change controller:</c>
<c>IETF <iesg@ietf.org></c>
<c>Specification document(s):</c>
<c>[RFC-AAAA]</c>
<c>Related information:</c>
<c>None</c>
</texttable>
</section>
<section anchor="sec-dhcp" title="DHCP Options">
<t>TBD</t>
</section>
<section anchor="sec-iana-media" title="Media Type Registration">
<t>The following registrations are done following the procedure
specified in <xref target="RFC4288"></xref> and <xref
target="RFC3023"></xref>.</t>
<t>Note to RFC Editor: Please replace all occurrences of "RFC-AAAA"
with the RFC number of this specification.</t>
<section title="energyprice+json Media Type Registration">
<t>TBD</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
<t>Further discussion of security proprieties for media types can be
found in <xref target="sec-iana-media"></xref>.</t>
</section>
<section title="Privacy Considerations">
<t>TBD </t>
</section>
<section title="Acknowledgement">
<t>I would like to thank someone for their review comments. </t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC4627">
<front>
<title>The application/json Media Type for JavaScript Object
Notation (JSON)</title>
<author fullname="D. Crockford" initials="D." surname="Crockford">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from
the ECMAScript Programming Language Standard. JSON defines a small
set of formatting rules for the portable representation of
structured data. This memo provides information for the Internet
community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4627" />
<format octets="16319"
target="http://www.rfc-editor.org/rfc/rfc4627.txt" type="TXT" />
</reference>
<reference anchor="RFC3023">
<front>
<title>XML Media Types</title>
<author fullname="M. Murata" initials="M." surname="Murata">
<organization></organization>
</author>
<author fullname="S. St. Laurent" initials="S."
surname="St. Laurent">
<organization></organization>
</author>
<author fullname="D. Kohn" initials="D." surname="Kohn">
<organization></organization>
</author>
<date month="January" year="2001" />
<abstract>
<t>This document standardizes five new media types -- text/xml,
application/xml, text/xml-external-parsed-entity, application/xml-
external-parsed-entity, and application/xml-dtd -- for use in
exchanging network entities that are related to the Extensible
Markup Language (XML). This document also standardizes a
convention (using the suffix '+xml') for naming media types
outside of these five types when those media types represent XML
MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3023" />
<format octets="86011"
target="http://www.rfc-editor.org/rfc/rfc3023.txt" type="TXT" />
</reference>
<reference anchor="RFC4288">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization></organization>
</author>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization></organization>
</author>
<date month="December" year="2005" />
<abstract>
<t>This document defines procedures for the specification and
registration of media types for use in MIME and other Internet
protocols. This document specifies an Internet Best Current
Practices for the Internet Community, and requests discussion and
suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="13" />
<seriesInfo name="RFC" value="4288" />
<format octets="52667"
target="http://www.rfc-editor.org/rfc/rfc4288.txt" type="TXT" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list style="empty">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:04:02 |