forked from w3c/wot-charter-drafts
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathwot-wg-2023-details.html
671 lines (671 loc) · 38 KB
/
wot-wg-2023-details.html
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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
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
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
<!DOCTYPE html>
<html lang="en-US">
<head>
<meta name="generator" content="HTML Tidy for HTML5 for Linux version 5.6.0">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Work Item Details for Web of Things Working Group Charter (2023 Draft)</title>
</head>
<body>
<section>
<h1>Work Item Details for Web of Things Working Group 2023 Charter Draft</h1>
<p>The following are details of some planned work items for the WoT WG charter starting in 2023, based on the
current draft.</p>
<dl>
<dt>
<strong>Discovery Updates</strong> (<a href="#discovery-deliverable">Discovery</a>):
</dt>
<dd>
Updates to the Discovery specification to support additional introduction mechanisms, improve query mechanisms
in directories, align with scripting APIs, support all Thing Description versions (1.0, 1.1, and 2.0) and Thing
Models, better support CoAP, and improve security and validation.
<dl>
<dt>
<a href="#discovery-improvements-workitem"><strong>Discovery Improvements</strong></a> (Discovery):
</dt>
<dd>Backward-compatible improvements to the Discovery specification to support additional introduction
mechanisms, align with scripting APIs, support all Thing Description versions (1.0, 1.1, and 2.0), and
improve security and validation.</dd>
<dt>
<a href="#discovery-thing-models-workitem"><strong>Discovery of Thing Models</strong></a> (Discovery):
</dt>
<dd>Extend discovery support to include storing and returning Thing Models from exploration mechanisms.</dd>
<dt>
<a href="#discovery-coap-dir-workitem"><strong>Discovery CoAP Directory</strong></a> (Discovery):
</dt>
<dd>Add support for a CoAP API to TD Directory services supporting discovery.</dd>
<dt>
<a href="#discovery-jsonpath-query-language-workitem"><strong>Discovery JSON Path Query
Language</strong></a> (Discovery):
</dt>
<dd>Add support for JSONPath queries to TD Directory services.</dd>
<dt>
<a href="#discovery-query-filters-workitem"><strong>Discovery Query Filters</strong></a> (Discovery):
</dt>
<dd>Add support for query filters for common use cases to TD Directory services.</dd>
</dl>
</dd>
<dt>
<strong>Security Scheme Reorganization</strong> (<a href="#thing-description-deliverable">Thing
Description</a>, <a href="#binding-deliverable">Binding Templates</a>):
</dt>
<dd>
Refactor security schemes to use Protocol Binding ontologies for protocol-specific security schemes while also
enabling simpler and inline security declarations.
<dl>
<dt>
<a href="#sec-ontology-workitem"><strong>Security Scheme Ontology</strong></a> (Thing Description, Binding
Templates):
</dt>
<dd>Refactor security schemes to use Protocol Binding ontologies for protocol-specific security schemes.</dd>
<dt>
<a href="#inline-sec-workitem"><strong>Inline Security</strong></a> (Thing Description):
</dt>
<dd>Add a way to describe security definitions in a simplified fashion for simple cases.</dd>
</dl>
</dd>
<dt>
<strong>Canonicalization and Signing</strong> (<a href="#thing-description-deliverable">Thing Description</a>,
<a href="#discovery-deliverable">Discovery</a>, <a href="#profiles-deliverable">Profiles</a>):
</dt>
<dd>
Add canonicalization and signing algorithms to support signed Thing Descriptions in the Discovery process.
<dl>
<dt>
<a href="#signing-workitem"><strong>Signing</strong></a> (Discovery, Thing Description):
</dt>
<dd>Add support for Thing Description signing and support signed Thing Descriptions in the Discovery process.
Requires definition of Thing Description canonicalization.</dd>
<dt>
<a href="#canon-workitem"><strong>Canonicalization</strong></a> (Thing Description, Discovery):
</dt>
<dd>Define a Thing Description canonicalization algorithm.</dd>
</dl>
</dd>
<dt>
<strong>Connection and Payload Reuse Improvements</strong> (<a href="#thing-description-deliverable">Thing
Description</a>, <a href="#binding-deliverable">Binding Templates</a>, <a href=
"#profiles-deliverable">Profiles</a>):
</dt>
<dd>
Add support for describing cases where a connection and subsequent payloads are same or similar.
<dl>
<dt>
<a href="#payload-protocols-workitem"><strong>Payload Driven Protocols</strong></a> (Thing Description,
Binding Templates, Profiles):
</dt>
<dd>Add support for describing protocols that depend on specific payload structures on top of the protocol
bindings.</dd>
<dt>
<a href="#init-connection-workitem"><strong>Initial / Common Connection Description</strong></a> (Thing
Description, Binding Templates):
</dt>
<dd>Add support for a connection description to be shared among affordance operations.</dd>
<a href="#streaming-workitem"><strong>Streaming</strong></a> (Thing
Description, Binding Templates):
</dt>
<dd>Add infrastructure (as necessary) to support streaming protocols which
allow ongoing and time-sensitive delivery of data including for audio and video.
</dd>
</dl>
</dl>
</dd>
<dt>
<strong>Normative Linting, Parsing, Consuming and Validation mechanism for TDs</strong> (<a href=
"#thing-description-deliverable">Thing Description</a>, <a href="#scripting-deliverable">Scripting API</a>,
<a href="#profiles-deliverable">Profiles</a>):
</dt>
<dd>
Define a linting mechanism for Thing Descriptions that allows adding additional rules and normative mechanism
for parsing, consuming and validation of TDs for Consumers.
<dl>
<dt>
<a href="#td-consumption-workitem"><strong>Normative TD Parsing, Consuming and Validation</strong></a>
(Thing Description, Scripting API, Profiles):
</dt>
<dd>Define normative algorithms for parsing, consuming and validating Thing Descriptions.</dd>
<dt>
<a href="#td-linting-workitem"><strong>Linting mechanism for TDs</strong></a> (Thing Description,
Profiles):
</dt>
<dd>Define a linting mechanism for Thing Descriptions that allows adding additional rules.</dd>
</dl>
</dd>
<dt>
<strong>Protocol and Payload Bindings</strong> (<a href="#binding:-deliverable">Binding Templates</a>):
</dt>
<dd>
Define bindings for specific protocols and payloads of interest while focusing to support ecosystems.
<dl>
<dt>
<a href="#http-binding-workitem"><strong>HTTP Protocol Binding</strong></a> (Binding Templates):
</dt>
<dd>Add HTTP binding</dd>
<dt>
<a href="#coap-binding-workitem"><strong>CoAP Protocol Binding</strong></a> (Binding Templates):
</dt>
<dd>Add CoAP binding</dd>
<dt>
<a href="#mqtt-binding-workitem"><strong>MQTT Protocol Binding</strong></a> (Binding Templates):
</dt>
<dd>Add MQTT binding</dd>
<dt>
<a href="#modbus-binding-workitem"><strong>Modbus Protocol Binding</strong></a> (Binding Templates):
</dt>
<dd>Add Modbus binding</dd>
<dt>
<a href="#bacnet-binding-workitem"><strong>BACnet Protocol Binding</strong></a> (Binding Templates):
</dt>
<dd>Add BACnet binding</dd>
<dt>
<a href="#rtsp-binding-workitem"><strong>RTSP Protocol Binding</strong></a> (Binding Templates):
</dt>
<dd>Add normative RTSP binding.
See also the <a href=#streaming-workitem">Streaming</a> workitem.</dd>
<dt>
<a href="#opcua-binding-workitem"><strong>OPC UA Protocol Binding</strong></a> (Binding Templates):
</dt>
<dd>Add OPC UA binding</dd>
<dt>
<a href="#grpc-binding-workitem"><strong>gRPC Protocol Binding</strong></a> (Binding Templates):
</dt>
<dd>Add gRPC binding</dd>
<dt>
<a href="#json-binding-workitem"><strong>JSON Payload Binding</strong></a> (Binding Templates):
</dt>
<dd>Add JSON binding</dd>
<dt>
<a href="#cbor-binding-workitem"><strong>CBOR Payload Binding</strong></a> (Binding Templates):
</dt>
<dd>Add CBOR binding</dd>
<dt>
<a href="#xml-binding-workitem"><strong>XML Payload Binding</strong></a> (Binding Templates):
</dt>
<dd>Add XML binding</dd>
<dt>
<a href="#cloudevents-binding-workitem"><strong>CloudEvents Payload Binding</strong></a> (Binding
Templates):
</dt>
<dd>Add CloudEvents binding</dd>
<dt>
<a href="#echonet-binding-workitem"><strong>ECHONET Lite Web API Combination Binding</strong></a> (Binding
Templates):
</dt>
<dd>Add ECHONET Lite Web API binding</dd>
</dl>
</dd>
<dt><strong>Other</strong>:</dt>
<dd>
<dl>
<dt>
<a href="#geolocation-workitem"><strong>Geolocation</strong></a> (Discovery, Thing Description, Profiles):
</dt>
<dd>Define mechanisms for embedding of static geolocation information in TDs, annotation of data models for
dynamic geolocation, and spatial filters in TD Directory queries for geospatially-limited discovery.</dd>
<dt>
<a href="#onboarding-workitem"><strong>Onboarding</strong></a> (Architecture, Discovery):
</dt>
<dd>Define a lifecycle process to establish mutual trust and identification so
that secure communication and appropriate levels of authentication can
be established between sets of devices.</dd>
<dt>
<a href="#timeseries-workitem"><strong>Timeseries</strong></a> (Thing Description, Binding Templates):
</dt>
<dd>Add support for describing historical values or value changes of affordances to the TD specification in
an interoperable way with existing solutions.</dd>
<dt>
<a href="#manageable-actions-workitem"><strong>Manageable Actions</strong></a> (Thing Description,
Profiles):
</dt>
<dd>Add support for describing actions that can be managed after their invocation.</dd>
<dt>
<a href="#td-versioning-workitem"><strong>TD Versioning</strong></a> (Thing Description, Discovery):
</dt>
<dd>Explain the semantics on how to version Thing Descriptions.</dd>
<dt>
<a href="#binding-mechanism-workitem"><strong>Binding Mechanism</strong></a> (Binding Templates, Thing
Description, Security, Profiles):
</dt>
<dd>Add normative binding mechanism</dd>
<dt>
<a href="#wotcg-coordination"><strong>WoT CG Coordination</strong></a>:
</dt>
<dd>Collaborate on community outreach of the WG reports to increase adoption and implementation, as well as
collect feedback from the wider community.</dd>
<dt>
<a href="#profiles-workitem"><strong>Interoperability Profiles</strong></a> (Profiles):
</dt>
<dd>Support out-of-the-box interoperability via a profiling mechanism.</dd>
</dl>
</dd>
</dl>
<p>Details for each of these are given below.</p>
<section>
<h2 id="discovery-improvements-workitem">Discovery Improvements</h2>
<p>Various updates are expected to be needed to align the Discovery spec with updates to other proposed
deliverables in this charter, for example updates to the information model, including support for all versions of
the Thing Description specification, and to improve security and validation.</p>
</section>
<section>
<h2 id="discovery-thing-models-workitem">Discovery of Thing Models</h2>
<p>Currently only Thing Descriptions can be stored in TD Directories, but it would be useful to also store Thing
Models in them, in particular to allow links to Thing Models to be resolved by reference to a TD Directory.</p>
</section>
<section>
<h2 id="discovery-coap-dir-workitem">Discovery CoAP Directory</h2>
<p>Currently, TD Directory services only have an HTTP API defined. TD Directories are the only Discovery
exploration mechanism supporting the return of multiple Thing Descriptions, and they may also be needed in the
case of constrained devices hosting multiple Things. However, the cost of using HTTP in constrained environments
can be prohibitive. Defining a CoAP API with equivalent functionality to the HTTP API would allow the API to be
used and provided by constrained devices, including those that simply want to self-host multiple TDs.</p>
</section>
<section>
<h2 id="discovery-jsonpath-query-language-workitem">Discovery JSON Path Query Language</h2>
<p>Currently there is no mandatory query language support for TD Directories. This means that consumers will
often need to download the contents of the entire directory if the id of a target TD is not known. An endpoint
for SPARQL queries is defined but because of the difficulty of supporting RDF processing it is optional. JSON
Path is still currently under discussion as an IETF RFC but was not mature enough to include during the last
charter. JSON Path queries would complement the current SPARQL-based query support but would be lighter-weight to
implement and use.</p>
</section>
<section>
<h2 id="discovery-query-filters-workitem">Discovery Query Filters</h2>
<p>Some simple query filters would be added to the API for specific common use cases, such as filtering by type,
time, or keyword. These filters would be chainable with each other and with query language results, so that, for
example, the result of a JSON Path query might them be filtered by time without needing to complicate the JSON
Path query with time computations. This mechanism would also be able to support <a href=
"#geolocation-workitem">filtering by geolocation</a>.</p>
</section>
<section>
<h2 id="geolocation-workitem">Geolocation</h2>
<p>Many WoT use cases have identified a need to limit discovery by geographic location or to identify the
location of a Thing. To support this, a standard way to encode geolocation metadata is needed (or several ways,
each identified using a profile) and (for discovery) query mechanisms that can filter by this metadata.
Geolocation metadata should be aligned with existing standards, and should support both static and dynamic
situations. Geolocation information may be included in either TDs or in data delivered directly from the Thing
and ideally both situations would be supported. Since multiple standards and use cases exist for geolocation
information, profiles to constrain how it should be encoded in particular situations (for example, in Building
Information Management Systems) would be useful.</p>
</section>
<section>
<h2 id="onboarding-workitem">Onboarding</h2>
<p>In order to establish secure communications in some contexts
a process to establish mutual trust between Things and Consumers is needed.
Having a prescriptive (but optional)
process for this would be useful.
</p><p>
In particular, the goal of the
onboarding process would be allow encrypted communications to
be used on a LAN, including establishing and exchanging
keying material among a set of devices without requiring fixed URLs
or use of a CA.
The keying material could, for example, take the form of certificates
containing public keys that can be used to identify devices and
also to establish mutual TLS or DTLS encrypted communication channels.
A pairwise onboarding process would involve the exchange of this
material between a Thing and a Consumer and a process or set of processes
that can be used to verify the level
of authorization to invoke affordances on the Thing.
In order to onboard sets of devices, group keys or a special "onboarding"
role can be used to establish transitive trust.
</p><p>
Onboarding is part of the larger WoT Thing lifecycle which is described in the
Architecture document.
In this work item we will define mechanisms to perform secure minimum-effort
trust establishment and identity confirmation among sets of
devices (both Things and Consumers)
that conforms to the security and privacy requirements of specific deployment
scenarios and use cases.
</p><p>
This work item complements the work that is done for device discovery,
and is in particular useful when
registering TDs with a TD Directory service,
however is also applicable for other use cases.
However, establishing identity and mutual trust would take place
prior to registration with discovery services, and onboarding itself
would not require registration with discovery services.
</p>
<p>
It must be possible for people with disabilities to navigate the onboarding process for Things independently. This means that any services, apps, or physical interactions that are necessary to the onboarding (or reconfiguration) process will need to be designed to be accessible, and function correctly with Assistive Technologies that Consumers may be using.
</p>
</section>
<section>
<h2 id="sec-ontology-workitem">Security Scheme Ontology</h2>
<p>Currently security schemes are "baked into" the TD specification but it would be more manageable and
consistent to break them out as separate ontologies so that all security schemes would be done via extensions.
For protocol-specific security schemes in particular, these should be moved to the Protocol Bindings and
ontologies supporting them. The TD 2.0 spec would be updated to only include general-purpose "structural"
security schemes and "generic" schemes that apply to all protocols.</p>
</section>
<section>
<h2 id="signing-workitem">Signing</h2>
<p>Mechanisms for signing TDs documents were under discussion in the last charter but were not mature enough to
include. Adding support for TD canonicalization and signing would be helpful to ensure that TDs are not
intercepted and modified by third parties. Verifying a signature requires identity management, i.e. the verifier
needs to know or have trusted access to the public key of the signer. Directories need to be extended to verify
signatures and generate new chained signatures as needed.</p>
</section>
<section>
<h2 id="timeseries-workitem">Timeseries</h2>
<p>Some edge and cloud services can collect property value changes or event emissions for a certain time. This
data, called timeseries, can be retrieved by Consumers to display the evolution of the affordance data over time,
make predictions about the future values and more. There are different serialization formats and structures of
such data in existing solutions. The generic mechanism for timeseries should be introduced in the <a href=
"#thing-description-deliverable">Thing Description</a> with bindings to existing solutions illustrated in the
<a href="#binding-deliverable">Binding Templates</a></p>
<p>Related Issues:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/issues/892</li>
</ul>
<p></p>
</section>
<section>
<h2 id="payload-protocols-workitem">Payload Driven Protocols</h2>
<p>Some protocols are built on top of the application layer protocols. Some examples are:</p>
<ul>
<li>RPC protocols on top of HTTP such as JSON-RPC.</li>
<li>Protocols using MQTT topics together with payloads to identify affordances.</li>
<li>Websocket sub-protocols.</li>
<li>SSE usage across implementations.</li>
<li>Webhook usage across implementations.</li>
</ul>
<p></p>
<p>The <a href="#thing-description-deliverable">Thing Description</a> should be updated with mechanisms that make
it possible to describe such protocols while optimizing the TD instances to be human and machine readable. The
<a href="#binding-deliverable">Binding Templates</a> should be updated with concrete cases where this mechanism
is already used. The <a href="#profiles-deliverable">Profiles</a> can use this mechanism to reduce the size of
TDs while making them easier to understand. The working group will also document in which cases this method does
not work due to making the TDs too complicated to understand, thus requiring a binding document.</p>
</section>
<section>
<h2 id="manageable-actions-workitem">Manageable Actions</h2>
<p>Various use cases require the implementation of more complex actions that span multiple protocol transactions.
Such actions are not simply invoked but need to managed over time by the Thing and the Consumer. These are
covered in the <a href="https://www.w3.org/TR/wot-thing-description11/">WoT Thing Description 1.1</a> via the
initiation (<code>invokeaction</code>), monitoring (<code>queryaction</code>), and cancellation
(<code>cancelaction</code>) of ongoing actions. However, the following points are not supported:</p>
<ul>
<li>Sent and received payloads associated to the operations</li>
<li>Management of dynamically generated identification</li>
<li>Describing queues of actions</li>
</ul>These limitations are also influencing the <a href="#profiles-deliverable">Profiles</a>.
<p></p>
<p>Additionally, there have been proposals by the WG members that need to taken into account and evaluated:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/tree/main/proposals/hypermedia-control</li>
<li>https://github.com/w3c/wot-thing-description/tree/main/proposals/hypermedia-control-2</li>
<li>https://github.com/w3c/wot-thing-description/tree/main/proposals/hypermedia-control-3</li>
</ul>
<p></p>
<p>Related Issues:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description#1692</li>
<li>https://github.com/w3c/wot-thing-description#1644</li>
<li>https://github.com/w3c/wot-thing-description#1223</li>
</ul>
<p></p>
</section>
<section>
<h2 id="init-connection-workitem">Initial / Common Connection Description</h2>
<p>Currently, each form of an affordance has information on the endpoint, media type and other protocol related
information. It is possible to use the <code>base</code> term for simplifying the endpoint but it has limitations
such as:</p>
<ul>
<li>If the media type is also common across forms, it is repeated</li>
<li>Multiple bases are not possible</li>
<li>For protocols that are based on an initial connection and then subsequent messages, the semantics are not
clear.</li>
</ul>
<p></p>
<p>Thus, a mechanism to describe connection and protocol information that can be used by other forms is needed.
In protocols with initial connection, this can be also used to indicate what needs to be done by the Consumer
before executing any operation.</p>
<p>Related Issues:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/issues/1664</li>
<li>https://github.com/w3c/wot-thing-description/issues/1248</li>
<li>https://github.com/w3c/wot-thing-description/issues/1242</li>
<li>https://github.com/w3c/wot-thing-description/issues/878</li>
</ul>
<p></p>
</section>
<section>
<h2 id="streaming-workitem">Streaming</h2>
<p>A streaming protocol establishes an ongoing connection supporting
delivery of time-sensitive information such as audio or video.
Note that this connection in general
may be over either reliable (TCP) or unreliable (UDP)
transports, or over a combination, and may also support encryption or
content management.
Streaming may also be used to support other kinds of ongoing time-sensitive
data delivery.
</p><p>
While related to event notification mechanisms, streaming in practice
is supported by a specific set of protcols such as RTSP, HLS, DASH, MSE, WebRTC, etc.
This workitem would add any infrastructure needed to TDs in order to support
streaming protocol bindings generally, for example, by adding additional
subprotocols supporting stream publication and subscription management (if needed).
</p><p>
In order to clearly define what infrastructure is actually needed, if any,
one or more
concrete streaming protocol bindings should also be attempted, such
as <a href="#rtsp-binding-workitem">RTSP</a>.
</p>
</section>
<section>
<h2 id="canon-workitem">Canonicalization</h2>
<p>Thing Descriptions can contain the same information but serialized differently even in the same serialization
format, due to structures such as maps which do not impose an order. This is problematic for comparing TDs or
more importantly, for signing them where every byte difference results in a different signature. Thus, the WG
will develop a canonicalization algorithm based on JSON-LD.</p>
<p>Related Issues:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/issues/1023</li>
<li>https://github.com/w3c/wot-thing-description/issues/940</li>
</ul>
<p></p>
<p>Some work has been done in the previous charter but has been postponed due to lack of features in JSON-LD.
Related PRs:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/pull/1304</li>
<li>https://github.com/w3c/wot-thing-description/pull/1151</li>
<li>https://github.com/w3c/wot-thing-description/pull/943</li>
<li>https://github.com/w3c/wot-thing-description/pull/1086</li>
</ul>
<p></p>
</section>
<section>
<h2 id="inline-sec-workitem">Inline Security Definitions</h2>
<p>In order simplify how security mechanisms are described in simple cases, the WG will propose a way to use them
with combining the definition and usage into a single term.</p>
<p>Related Issues:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/issues/1572</li>
<li>https://github.com/w3c/wot-thing-description/issues/757</li>
<li>https://github.com/w3c/wot-thing-description/issues/300</li>
</ul>
<p></p>
<p>Some work has been done in the previous charter but has been postponed due to backwards compatibility
requirement. Related PRs:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/pull/945</li>
</ul>
<p></p>
</section>
<section>
<h2 id="td-versioning-workitem">TD Versioning</h2>
<p>TD allows themselves to be versioned. However, the semantics of such versioning is not defined, i.e. the
meaning of version numbers. This makes it difficult to manage TDs and results in different behavior across
versioned TD repositories. The WG will define the semantics of versions of a TD and recommendations on how to
manage different versions of TDs.</p>
<p>Related Issues:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/issues/257</li>
<li>https://github.com/w3c/wot-discovery/issues/257</li>
</ul>
<p></p>
</section>
<section>
<h2 id="td-consumption-workitem">TD Parsing, Consumption and Validation</h2>
<p>Currently the TD specification defines an abstract information model and a default JSON serialization for TDs.
However, parsing, consuming and validating TDs are not normatively defined. A validation process is defined but
is not normative, which leads to certain ambiguities for a Consumer parsing a TD. Additionally, no method is
proposed for validation the extensions that are used via the prefixes and the <code>@context</code>. The WG will
specify normative algorithms for parsing, consuming and validating TDs to ensure interoperability of
Consumers.</p>
</section>
<section>
<h2 id="td-linting-workitem">TD Linting</h2>
<p>Linting rules exist for programming languages or for API specifications in order to establish custom rules
within projects. How these rules can be defined for TDs is not specified in any way, making it difficult to
constrain flexibility of TDs in a standardized manner. The WG will define the mechanism for linting TDs together
with optional rules that can be used by different projects.</p>
<p>Related Issues:</p>
<ul>
<li>https://github.com/w3c/wot-thing-description/issues/1707</li>
<li>https://github.com/w3c/wot-thing-description/issues/1512</li>
<li>https://github.com/w3c/wot-thing-description/issues/1195</li>
</ul>
<p></p>
</section>
<section>
<h2 id="binding-mechanism-workitem">Binding Mechanism</h2>
<p>The current mechanism for how a protocol or payload binding should happen is largely informative with some
normative text in different deliverables. The WG will consolidate the explanation of the mechanism and explain it
in further detail.</p>
</section>
<section>
<h2 id="http-binding-workitem">HTTP Protocol Binding</h2>
<p>The WG will work on the current HTTP Protocol Binding that is split also into the TD specification in order to
publish it as a standalone normative document. This will reference the HTTP in RDF ontology, introduce default
values and describe the terms associated with the behavior of Things regarding the usage of the HTTP.</p>
</section>
<section>
<h2 id="coap-binding-workitem">CoAP Protocol Binding</h2>
<p>The WG will work on the current CoAP Protocol Binding in order to publish it as a standalone normative
document. This will include a CoAP ontology, introduce default values and describe the terms associated with the
behavior of Things regarding the usage of the CoAP.</p>
</section>
<section>
<h2 id="mqtt-binding-workitem">MQTT Protocol Binding</h2>
<p>The WG will work on the current MQTT Protocol Binding in order to publish it as a standalone normative
document. This will include a MQTT ontology, introduce default values and describe the terms associated with the
behavior of Things and Brokers regarding the usage of the MQTT.</p>
</section>
<section>
<h2 id="modbus-binding-workitem">Modbus Protocol Binding</h2>
<p>The WG will work on the current Modbus Protocol Binding in order to publish it as a standalone normative
document. This will include a Modbus ontology, introduce default values and describe the terms associated with
the behavior of Things regarding the usage of the Modbus.</p>
</section>
<section>
<h2 id="bacnet-binding-workitem" class="todo">BACnet Protocol Binding</h2>
<p>The WG will work on specifying a BACnet Protocol Binding for the Web of Things in order to publish it as a
standalone normative document. This will include a BACnet ontology, introduce default values and describe the
terms associated with the behavior of Things regarding the usage of the BACnet. Note: How should we mention
ASHRAE here?</p>
</section>
<section>
<h2 id="rtsp-binding-workitem" class="todo">RTSP Protocol Binding</h2>
<p>The WG will work on specifying a RTSP Protocol Binding for the Web of Things in order to publish it as a
standalone normative document.
This will include any necessary RTSP ontology (e.g. for RTSP methods),
introduce default values, and describe the
terms associated with the behavior of Things regarding the usage of RTSP.
</p><p>
RTSP is widely supported in IP cameras.
The binding will permit multiple video and audio streams to be managed.
Note that single cameras may have multiple videos streams supporting
different resolutions or encodings, may likewise support multiple
audio streams for different rates or encodings, and may support
bidirectional audio streams (e.g. a speaker as well as a microphone).
This is related to the <a href="#streaming-workitem">Streaming</a> workitem.
</p><p>
Note 1: There are many other streaming protocols. RTSP is older but is widely
supported in IP cameras in particular.
Unfortunately it is typically not directly supported
in browsers, so we may want to consider additional streaming protocols such
as HLS, DASH, MSE, WebRTC, RTMP, or others. Many of these are supported in
browsers although often optimized for non-camera use cases, such as video
conferencing (WebRTC) or content delivery (HLS, DASH).
</p><p>
Note 2: In addition IP cameras also often
have associated pan-tilt-zoom (PTZ) controls so we may want to define some
vocabulary terms to allow affordances for
such controls to be described consistently in a TD.
</p>
</section>
<section>
<h2 id="opcua-binding-workitem" class="todo">OPC UA Protocol Binding</h2>
<p>The WG will work on specifying an OPC UA Protocol Binding for the Web of Things in order to publish it as a
standalone normative document. This will include a OPC UA ontology, introduce default values and describe the
terms associated with the behavior of Things regarding the usage of the OPC UA. Note: How should we mention OPC
Foundation here?</p>
</section>
<section>
<h2 id="grpc-binding-workitem">gRPC Protocol Binding</h2>
<p>The WG will work on specifying a gRPC Protocol Binding for the Web of Things in order to publish it as a
standalone normative document. This will include a gRPC ontology, introduce default values and describe the terms
associated with the behavior of Things regarding the usage of the gRPC.</p>
</section>
<section>
<h2 id="json-binding-workitem">JSON Payload Binding</h2>
<p>The WG will work on specifying a JSON Payload Binding for the Web of Things in order to publish it as a
standalone normative document. This will include specification on the usage of Data Schema terms as well as
<code>contentType</code> term usage within forms.</p>
</section>
<section>
<h2 id="cbor-binding-workitem">CBOR Payload Binding</h2>
<p>The WG will work on specifying a CBOR Payload Binding for the Web of Things in order to publish it as a
standalone normative document. This will include specification on the usage of Data Schema terms as well as
<code>contentType</code> term usage within forms.</p>
</section>
<section>
<h2 id="xml-binding-workitem">XML Payload Binding</h2>
<p>The WG will work on specifying an XML Payload Binding for the Web of Things in order to publish it as a
standalone normative document. This will include specification on the usage of Data Schema terms as well as
<code>contentType</code> term usage within forms.</p>
</section>
<section>
<h2 id="cloudevents-binding-workitem">CloudEvents Payload Binding</h2>
<p>The WG will work on specifying an CloudEvents Payload Binding for the Web of Things in order to publish it as
a standalone normative document. This will include specification on the usage of Data Schema terms as well as
<code>contentType</code> term usage within forms.</p>
</section>
<section>
<h2 id="echonet-binding-workitem" class="todo">ECHONET Lite Web API Combination Binding</h2>
<p>The WG will work on specifying an ECHONET Lite Web API Combination Binding for the Web of Things in order to
publish it as a standalone normative document. This will include specification on the usage of Data Schema terms,
together with how form elements should be structured with possible other assertions on the TD instances. Note:
How should we mention ECHONET Consortium here?</p>
</section>
<section>
<h2 id="wotcg-coordination">WoT CG Coordination</h2>
<p>The WG identifies multiple areas where a coordination of the standardization activity with the W3C WoT CG is
beneficial to drive more interest to the Web of Things and increase its adoption. To this end, the WG will
implement the following action items:</p>
<ul>
<li>Ask the WoT CG for the WG members to be invited in W3C WoT CG meetups.</li>
<li>Ask for use cases from the WoT CG and analyze them.</li>
<li>Collect implementations from CG participants for Plugfest and Testfest efforts.</li>
<li>Comanage social media and chat platforms with the WoT CG as well as other related CGs.</li>
</ul>
<p></p>
</section>
<section>
<h2 id="profiles-workitem">Interoperability Profiles</h2>
<ol>
<li>Complete the transition of the <a href="https://w3c.github.io/wot-profile/">WoT Profile 1.0</a> Working
Draft, including a first basic HTTP-based profile, to a Recommendation
</li>
<li>Normatively define one or more profiles which specify how to observe properties and subscribe to events
over HTTP, e.g. using Server-Sent Events and/or Webhooks</li>
<li>Consider defining other profiles, e.g. a CoAP-based profile for constrained devices which do not have the
resources to implement HTTP-based profiles</li>
<li>Stretch goal: Specify an updated profiling mechanism which reuses the sub-protocol and context extension
mechanisms from the WoT Thing Description specification, in order to more tightly constrain how profiles are
defined</li>
</ol>
</section>
</section>
</body>
</html>