You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This specification was developed as part of the global effort to combat the climate crisis.
46
-
Specifically, in order to scalably measure carbon emissions of organizations and calculate the impact of deploying and operating clean energy technologies, companies need an efficient means to discover the details and capabilities of energy utilities and other similar entities.
47
-
48
-
There are thousands of utilities serving customers across the world, and each have their own way of organizing and structuring data.
47
+
There are thousands of utilities and other central grid entities serving customers across the world, and each have their own way of organizing and structuring data.
49
48
This specification defines a way for these utilities and other entities to provide standardized, structured reference information about them, the functionality they offer, and how organizations can interoperate with them.
50
-
By serving "metadata" defined in this specification, utilities and other entities can automatically incorporate their details and capabilities into carbon tracking websites, apps, products, and other clean energy technologies.
49
+
By serving "metadata" defined in this specification, utilities and other entities can automatically incorporate their details and capabilities into websites, apps, products, and other energy technologies.
51
50
52
51
This specification is intended to be a starting point for providing basic information about utilities and other similar entities, then extended by other specifications to define additional information and functionality.
53
52
For example, this specification may be extended to define how organizations can dynamically register with a utility in order to gain access to customer-authorized energy usage data.
@@ -60,31 +59,27 @@ These entities can include, but are not limited to, distribution utilities, grid
60
59
61
60
<aid="client"href="#client"class="permalink">🔗</a> **"Client"** - The entity requesting Server's metadata endpoints.
62
61
A Client can be any organization or user seeking the Server's metadata on their details and capabilities.
63
-
These entities can include, but are not limited to, carbon tracking applications, electric vehicle companies, clean energy technology providers, commercial utility customers, grid management applications, and energy efficiency organizations.
62
+
These entities can include, but are not limited to, building management applications, electric vehicle companies, energy technology providers, commercial utility customers, grid management applications, and energy efficiency organizations.
<spanstyle="background-color:yellow">TODO: add more as needed</span> are defined by their referenced standards documents.
75
-
76
-
<aid="string"href="#string"class="permalink">🔗</a> "string" - A series of unicode characters as defined in [RFC 8259](https://www.rfc-editor.org/rfc/rfc8259#section-7).
65
+
"[HTTPS](#ref-https)",
66
+
"[Request Methods](#ref-request-methods)",
67
+
"[Status Codes](#ref-status-codes)",
68
+
"[JSON](#ref-json)",
69
+
"[Well-Known URI](#ref-wellknown-uri)",
70
+
"[GeoJSON](#ref-geojson)"
77
71
78
-
<aid="datetime"href="#datetime"class="permalink">🔗</a> "datetime" - A string representing date and time in the format of `date-time`as defined by[RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) (e.g. "2024-01-01T00:00:00Z").
72
+
<aid="string"href="#string"class="permalink">🔗</a> "string" - A series of unicode characters as defined in[RFC 8259 Section 7](#ref-rfc8259-strings).
79
73
80
-
<aid="url"href="#url"class="permalink">🔗</a> "URL" - A string representing resource as defined in[RFC 3986](https://www.rfc-editor.org/rfc/rfc3986.html#section-1.1.3) (e.g. "https://example.com/page1").
74
+
<aid="datetime"href="#datetime"class="permalink">🔗</a> "datetime" - A string representing date and time in the format of `date-time`as defined by[RFC 3339 Section 5.6](#ref-rfc3339-datetime) (e.g. "2024-01-01T00:00:00Z").
81
75
82
-
<aid="mime-type"href="#mime-type"class="permalink">🔗</a> "MIME type" - A string representing a document media type as defined in [RFC 6838](https://datatracker.ietf.org/doc/html/rfc6838) (e.g. "image/png").
76
+
<aid="url"href="#url"class="permalink">🔗</a> "URL" - A string representing resource as defined in [RFC 3986 Section 1.1.3](#ref-rfc3986-url) (e.g. "https://example.com/page1").
83
77
84
-
<aid="country-code"href="#country-code"class="permalink">🔗</a> "country code" - A two-character string representing a country as defined in [ISO 3166](https://www.iso.org/iso-3166-country-codes.html) (e.g. "US").
78
+
<aid="mime-type"href="#mime-type"class="permalink">🔗</a> "MIME type" - A string representing a document media type as defined in [RFC 6838](#ref-rfc6838) (e.g. "image/png").
85
79
80
+
<aid="country-code"href="#country-code"class="permalink">🔗</a> "country code" - A two-character string representing a country as defined in [ISO 3166](#ref-iso3166) (e.g. "US").
86
81
87
-
<aid="key-words"href="#key-words"class="permalink">🔗</a> Key Words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are defined in accordance with [BCP 14](https://www.rfc-editor.org/info/bcp14).
82
+
<aid="key-words"href="#key-words"class="permalink">🔗</a> Key Words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are defined in accordance with [BCP 14](#ref-bcp14).
`RFC 3339 Section 5.6` - Section 5.6. Internet Date/Time Format, "Date and Time on the Internet: Timestamps", RFC 3339, Internet Engineering Task Force (IETF),
If you would like to contribute to these specifications, please see our docs on [Contributing]({{ "/" | relative_url }}#contributing) and [Design Principles]({{ "specs/design-principles" | relative_url }}).
There are thousands of utilities serving customers across the world, and each has their own way of organizing and structuring data and functionality.
21
-
For [use case]({{ "/use-cases" | relative_url }}) companies needing to access data or functionality, an efficient means of discovering, registering, and interoperating with these utilities is needed.
20
+
There are thousands of utilities and other central entities serving customers across the world, and each has their own way of organizing and structuring data and functionality.
21
+
For external entities needing to access data or functionality, an efficient means of discovering, registering, and interoperating with these utilities and other central entities is needed.
If you would like to contribute to these specifications, please see our docs on [Contributing]({{ "/" | relative_url }}#contributing) and [Design Principles]({{ "specs/design-principles" | relative_url }}).
17
17
18
+
---
19
+
20
+
#### Where these specifications are used
21
+
22
+
Other specifications, standards, and products are [encouraged]({{ "/use-cases" | relative_url }}) to incorporate our specifications into their protocols to enable secure, automated, and streamlined server discovery and client registration. Below are some examples of other working groups that reference our `CDS-WG1-*` specifications. If you use our specifications to enable your products or protocols, and want to be listed here, we'd love if you [opened a pull request](https://github.com/lfe-cds/CDS-Registration/pulls)!
23
+
24
+
*[CDS Customer Data](https://cds-customerdata.lfenergy.org/specs/) - Defines open specifications for secure customer data access.
0 commit comments