w3c / wot-architecture

Web of Things (WoT) Architecture

Web of Things (WoT) Architecture

General information about the Web of Things can be found on https://www.w3.org/WoT/.

---

This repository is for discussion and development of the Web of Things (WoT) Architecture deliverable.

Each commit here will sync it to the master, which will expose the content to http://w3c.github.io/wot-architecture/.

To make contributions, please provide pull-requests to the html file, see github help.

Some images are written using PlantUML. See editors' guide.

If you are implementing the WoT architecture and their building blocks, please contribute to the WoT Architecture implementation report. The process is described in Implementation Report.

wot-architecture's Issues

High-level content of the document

During my current iteration, I somewhat lost my understanding of what the document currently actually offers. There is a lot of good and valid information, yet it feels a bit like a heap rather than the guidance document it should be. There is a list defining the purpose in the introduction. However, I do not see it reflected in the sections or the content:

• a guideline to the mapping between functional architecture and physical devices configuration

This (probably) corresponds to the "Mapping Variations" section at the end

• a description of the role and functionality of each logical module

This is the Servient architecture and somewhat building block explanation

• a reference defining what should be standardized

Do we need this here? We already have a charter.

• a set of requirements for a WoT implementation environment.

Not sure what this means

My proposal

I fear that also other readers might have trouble to understand the provided information. Please tell me, if it is only me! For my personal better understanding, I would propose the following outline, which would produce a corresponding list for the purpose of the document:

Functional Requirements

The list of requirements addressed by the WoT Architecture. Ideally, the final document does not only state the requirements, but also summarizes how they are met.

Integration Patterns

An overview of the different integration patterns and envisioned deployments. See #9 and our architecture overview figure

WoT Building Blocks and Servient Architecture

An introduction to the WoT building blocks. The result of combing these is either a Thing (only TD) or a WoT Servient (also Protocol Bindings and optionally the Scripting API). I guess this should be understood before looking at the deployment scenarios.

WoT Thing Description

WoT Binding Templates

WoT Scripting API

Thing

Servient

Servient in the Web Browser

Deployment Scenarios

Implementation guidelines for the different deployment scenarios. The current Section 5 answers what kind of discovery is required and what interactions are possible (my interpretation of the "API" lists). Issue #24 proposes to add guidance on how to enable connectivity in each scenario.

Functional Roles of Servients*

*Let's think about better titles.

I find "Mapping Variations" quite misleading and the focus on specific devices in the sub-section titles is confusing, too. I think the purpose of the current Section 6 is to show which functional roles a Servient could serve (e.g., simply as state-of-the-art implementation of a Thing, or as gateway, or as cloud proxy, etc.). . Please confirm my assumption about this purpose.

Security Considerations

Space to note everything that has to be considered for a secure WoT deployment...

---

Please let me know if you agree with this, as I want to avoid rewriting to much without consensus.

Working Draft for Prague PlugFest

This issue is to collect the topics that should be addressed for the next WoT Architecture Working Draft.

Wrap up Burlingame F2F Plugfest and Terminology "Servient"

At Sunnyvale F2F meeting hosted by Fujitsu in July 2015, terminology “Servient” was proposed first time by Johannes at TF-AP.
https://www.w3.org/WoT/IG/wiki/F2F_meeting_29-31_July_2015_in_Sunnyvale_CA
https://www.w3.org/WoT/IG/wiki/images/3/33/Sunnyvale_F2F_TF-AP_breakout.pdf

Regarding “Building Block”, client and server looks symmetry and they will be cascaded to work together.
Then we assumed the node which works as both client and server.
So introducing new terminology “Servient” which combines “Server” and “Client”.
This “Servient” is very convenient to represent common building block.

In WoT IG/WG, “Servient” is common sense. On the other hand, it is new terminology.
So, it might be tough to understand the concept of “Servient” by other guys such as Mozilla.

In architecture document or in complementary document, describing servient use case might be helpful to understand what is Servient.

I think of 2 types of servient use cases as follows

1. Orchestrating Servers
2. Proxy
   WoT-Servient and Proxy.pptx

Propose draft text for 7.4 WoT Security and Privacy Guidelines

6.3 WoT servient on Smartphone - Browser + Servient

The text for Figures 13 and 14 is quite confusing and it is hard to understand the difference (actually there is none described in the text). Also, the figure numbering needs fixing.

I assume 13 means the browser runs on a different device than the smartphone and 14 that the browser can also run on the smartphone itself. I don't see this as fundamentally different. Whether the smartphone offers its own sensors/actuators as Things or functions as gateway for other technologies such as Bluetooth is not depicted either (although maybe even more interesting).

I would just have one figure and explaining these options well.

A Thing may be the abstraction of more than one entity.

The definition of a Thing is:

An abstraction of a physical or virtual entity whose metadata and interfaces are described by a WoT Thing Description.

Shouldn't this definition be relaxed to account for more use cases:

An abstraction of one or more physical or virtual entities whose metadata and interfaces are described by a WoT Thing Description.

For example, a Thing could be the abstraction of all the lights in a street.

3. Use Cases

The Architecture document is now restructured.

Section 3. Use Cases needs a last overhaul:

• Update figures (drop servient terminology)
• Add editable figure source to the repository
• Check if use cases still contain initial intention

Optional:

• Potentially split up the large set of features of the two use cases in 3.1.5 Cloud Device Shadows into several incremental uses cases

Thing proxies

@draggett commented this in the terminology discussion (however, out of scope there, so moved here):

Another addition would address the concept of republishing a thing, e.g. to expose a thing on a cloud server where the thing is a proxy for a thing exposed by a device or application hub behind a network firewall.

We currently have the concepts of synchronization and Management Thing in the Scripting API work. Since this is more an architectural issue, I propose that a section on how to proxy/mirror Things is added AFTER we published the FPWD.

Thing Description in High-level architecture

In Figure 14, Thing Descriptions are placed in each Servient. But it is not clear that TD in the Application Servient describes for.
So I've updated these figures as below. The intension of this update is to clarify which Servient is described by the TD and which Servient use the TD to interact others. And these pictures are consistent with Figure 16, I think.

What do you think of these figures?

Original PowerPoint file is here.

Edit(Feb 24): Removed a term 'Servient', because it is not yet defined at this section and not suitable for high-level architecture description.

Replace the figure of the Building Blocks

This issue is a proposal to replace the figure of the Building Blocks to a new one. Because some components of the current Building Blocks have been not well defined yet. The below is my proposal.

As already discussed, consideration of the use cases and the requirements derived therefrom resulted in noting that there are three types of entities. The figure shows the functional architecture that commonly applies to those three entity types.
The “WoT Runtime” functionally realizes operations based on interaction model described in Thing Descriptions, and is the central functionality of a WoT Servient. Based on a Thing Description, the WoT Runtime instantiates ExposedThing and ConsumedThings in a WoT Servient, and they provide functions used by applications, proxies and devices to serve as server’s and/or client’s roles. For example, when a WoT Servient is a device, an ExposedThing gets instantiated based on the device’s Thing Description. Regarding those operations to manage the lifecycle of an ExposedThing such as retrieving and/or serving Thing Descriptions, instantiating an ExposedThing based on the Thing Descriptions and terminating an ExposedThing, the details of the operation vary among different kind of devices. The WoT Servient Life Cycle Management (LCM) encapsulates those lifecycle operations. It uses internal interfaces to realize the lifecycle management of ExposedThings. The LCM is an application that runs on top of the WoT Runtime. The WoT Scripting API is one implementation of such an internal interface that includes functionality to realize the lifecycle management of ExposedThings. When a WoT Servient is an application or a proxy, the lifecycle management of ConsumedThings are realized in the same manner as that of ExposedThings. The WoT Runtime provides an interface to operate on the interaction model. This interface is defined as an abstract interface (the “Abstract Interface” in the figure [TDB?]). For this abstract interface to be used to interact with other WoT Servients or Web Server/Clients in practice, concrete bindings to underlying protocols need to be selected and used. It is the REST protocol that is most commonly used as the WoT interface on the Web. Other protocols such as CoAP, MQTT and WebSocket are also commonly used, and the protocol bindings enable the use of those protocols to interact with other Web Servients and Web Servers/Clients. Note that Web Servers and Clients are “Web Objects” that can directly interact with WoT Servients through the WoT interface even though they are not designed on the WoT interaction model. The overwhelming majority of existing sensors and devices are not implemented as Web Objects. The Device interface adapter represents the functionality to translate the native interface of those diverse kind of devices to/from the Abstract interface. As for the interfaces to existing devices, there are standards in each domain such as Home, Building and Factory. Moreover, the standards adopted by nations and even regions are often different, adding more complexity. Although in the future a framework for native protocol translation may be considered that eases the development of such translation work, it is not in the scope of the current WoT charter, therefore, the translation functionality is just called “Device interface adapter”.

Propose draft text for chapters 6.1 and 6.2

Motivate for Interaction model, media types etc in Functional Requirements - Common Principles

Add new requirement to "5.1.1 common principles" section to motivate for a simple and generic interaction model, media types etc.

Propose draft text for section 7.3 WoT Scripting API

Consistency check

Editors of the other documents should file their concerns, change requests, etc. here in this issue. WoT Architecture Editors will use it as todo list.

new common pattern: multiple devices with multiple clouds

Terminology for "Semantics"

We have different kinds of "Semantics":

• TD model vocab
• Binding vocab
• Application semantics, domain-specific model (e.g., iot.schema.org)

Lets add this to terminology.md

General issues for FPWD

After a first read through I would like to share my comments (mostly typos) below. The section I refer to are linked first.

A
https://w3c.github.io/wot-architecture/#introduction

Why is the Architecture document labeled as "the WoT Thing Description (this document)"?
Is it because of the four items in scope in the charter

(https://www.w3.org/2016/12/wot-wg-2016.html).

If so.. we miss in the Arch Document Introduction any mentioning about "Security and Privacy". Somehow the current form of the bullet list item confuses me a bit.

B
https://w3c.github.io/wot-architecture/#introduction

typo: 2nd last bullet lits item
"a guideline to map the abstract architechture ..."
vs
"a guideline to map the abstract architecture ..."

C
https://w3c.github.io/wot-architecture/#sec-building-blocks

"This section presents the abstract architecture for the Web of Things, which is derived from the use cases in section and the requirements in section ,"

--> the reference to this sections seems to be missing

"Figure Figure 9 Abstract Architecture of W3C WoT summarizes "

Figure duplicated.

"Figure Figure 10 Conceptional Architecture of the WoT Building Blocks ..."

Figure duplicated again.

D
https://w3c.github.io/wot-architecture/#thing
"... ergo, everthing that has a Thing Description is a Thing. "
--> last para of 5.1
--> "everthing" ---> "everything"

E
https://w3c.github.io/wot-architecture/#wot-binding-templates

After Figure 11 ... "Figure" is duplicated again.

"Figure Figure 11 From Binding Templates to Protocol Bindings shows ..."

F
https://w3c.github.io/wot-architecture/#wot-scripting-api

"The WoT Scripting API as an optional building"
-->
"The WoT Scripting API is an optional building"

G
https://w3c.github.io/wot-architecture/#security-and-privacy-0

"Security is a cross-cutting issue that needs to be taken into account in all WoT building block .."

I think it should read "blocks"

H
https://w3c.github.io/wot-architecture/#security-and-privacy-0

Still first para
"from Web secrutiy,"
to
from Web security,

I
https://w3c.github.io/wot-architecture/#wot-servient-architecture

First para
"Thus, the can be in both,"
to
"Thus, they can be in both,"

second para
"The previous Figure Figure 10 Conceptional Architecture of the WoT Building Blocks"
or
"Figure Figure 12 Implementation View of a Servient."

2 times figure again.

J
https://w3c.github.io/wot-architecture/#application
"The security metadata also needs to unclude"
cs
"The security metadata also needs to include"

and
"or certifictes "
vs
"or certificates "

K
https://w3c.github.io/wot-architecture/#scripting-api

The text is the same as in 6.1 with the same errors.
Besides I wonder whether we can do better than duplicating the same text.

L
https://w3c.github.io/wot-architecture/#protocol-bindings
end of 2nd para
"across theses generic protocol stacks. "
vs
"across these generic protocol stacks. "

M
https://w3c.github.io/wot-architecture/#servient

"Figure 14 Servient Consuming Thing the basic scenario"

The sentence seems to miss something like

"Figure 14 Servient Consuming Thing shows the basic scenario"

O
https://w3c.github.io/wot-architecture/#conclusion

"It is based on three building blocks ..."

I am not sure if the number is correct or how to count the building blocks given that Scripting is optional. What about Security?

"Security option" in 4.2 Scripting API

The document uses the term "security option" that is not aligned with the Scripting API.

My latest understanding was that scripts come along with "Security metadata" that define the execution environment, and thus access control for the Discovery/Client/Server APIs.

Break down proxy scenarios

There is an editors note in the Proxy section suggesting to break down the use cases.

The author of this note should comment his suggestions in this issue

Clear definition about Properties, Actions, and Events

For the TD deliverable document we need a reference with definitions about WoT's Properties, Actions, and Events. There was the plan to place this in the architecture document. What is the status about this?

BTW: A good reference can be https://rawgit.com/w3c/wot-thing-description/master/proposals/simplified-td/index.html#interaction-model

Link other documents such as TD, Scripting, Bindings

The architecture document may be the first document people gonna read.

Hence it would be good that the Abstract/intro might describe the other documents (as suggest by @mmccool PR) and also link the other documents such as thing description, Scripting, binding...

Connectivity Section(s)

#14 raised the issue about how to connect to a Servient running on a smartphone. This is similar to how to connect to Servient behind a firewall or NAT.

One solution is quite obvious when looking at the pattern from LWM2M: the Servient connects to the cloud with a long-lasting, bidirectional connection (e.g., CoAP-over-TLS). Yet there might be other solutions for other use cases, for instance WebRTC.

I propose to add a connectivity section or even better, add this aspect under "Deployment Scenarios" to improve the differentiation to "Mapping Variations" (which is currently more or less the figures...).

Structure of protocol binding block and therminology

Issue raised as #3 was closed.
On the other hand, the issue about terminology of current protocol binding, I have.

Before starting WG, the architecture building blocks are reviewed according to WG charter.
We have introduced "protocol binding" with "binding templates" as one of blocks for communication between WoT servients which supports at least one of "http", "CoAP", "Web-socket" or "MQTT" defined by binding template.

Now the discussion for creating protocol binding document leads to following 2 issues.

1. the protocol binding block consists of 2 layers.

Top layer might be very thin and just extracting common API type from run-time such as "Property", "Action" and "Event".

Bottom layer is mapping data model for each protocol which is described in current practice as follows;
e.g. For HTTP,
API Type "Property"
"Read" is mapped to "GET"
"Write" is mapped to:"PUT"
API Type "Action"
"Invoke" is mapped to "POST"
"Update task:" is mapped to "PUT (on handle resource)"
"Cancel task" is mapped to "DELETE (on handle resource)"
API Type "Event"
"Subscribe" is mapped to "POST + (Long-)Polling/Chunking/Streaming of returned handle resource"
"Update subscription" is mapped to "PUT (on handle resource)"
"Cancel subscription" is mapped to "DELETE (on handle resource)"

This bottom layer is just the same as "binding template", I think.

I wonder that we should provide new name both of these 2 layers or no need.

2. All of protocols implementation must be covered by protocol binding or not

All of protocols such as OCF-defined over HTTP, one M2M defined over HTTP might be able to implemented as 1)'s bottom layer.

on the other hand, I figure out "legacy communication" block explicitly in architecture document. That is because current Panasonic's air conditioner WoT server implementation over Echonet is monolithic and it works well as "WoT Server".
So, I'd like to keep this legacy communication block in WoT architecture for accepting wide variety of implementation.

I'd like to get any comments.

Use the term "Twin" instead of "proxy"

As agreed in call on 28.2.

Thing Discovery

Discovery is mentioned in the scripting API and would obviously be part of Thing Resource Directory (when that is started).
There is a lack of discussion about how to discover Web of Things on various networks.

I'm strongly aware of using CoRE (RFC 6690) /.well-known/core to list resources on a server. which may list Web of Thing resources and Thing Descriptors. A CoRE link format lists resources and additional parameters to include metadata about resources. we could use linked resources by use of describedby= with a IANA registered resource-type rt=.

Also, use of CoRE's .well-known/core resource is part of CoAP (RFC 7252) as part of resource discovery.

A means of getting started on either Things directory or how the discovery process would work and what to look for would be a great way to start implementing real world devices.

Hyperlinks to terms

[Editorial]
In a past teleconference or F2F, there was a discussion about a style of hyperlinks to terminology section.
For example, in Building Blocks, Servient Implementation and Security and Privacy Considerations, terms are repeatedly linked to terminology section. On the other hand, other sections have no links to terminology.

Which style is preferred in this document?

1. Make all occurrence of technical term be linked to terminology section to clarify their meaning.
2. Link only from first occurrence of the term for the conciseness.

And, there are lots (55) of broken reference to terminology section. If needed (especially when we choose an option 1 above), I'll make a pull request to fix them.

Write .md for Identity Management

Need text proposal for @id/id concept.

Beginner Terms

Revise terminology with simpler terms that help beginners to align with common software and networking terms.

Two separate layers for the Protocol Binding mechanism

As I mentioned during the TD call on June 2 and the WoT main call on June 7, I think it would be clearer to have the two separate layers for Protocol Binding:

• L1: TD World (=Device-independent abstract layer)
• L2: Device World (=Device-dependent layer)

"Protocol Binding" could be the combination of (1) getting/extracting device properties based on the each device's features and (2) packing the extracted properties into TD for interoperable connection. Probably each device vendor should provide concrete micro server implementation for the "propery extraction" part and we W3C WoT group could provide "how to pack the property into TD" as the "Binding Template".

Please see also the diagram below:

Note that the "Servient Internal Data Transfer" within the above diagram should be the standard WoT mechanism, e.g., TD and REST.

I'd suggest we update the WoT Architecture document, e.g., its section "4.3 Binding Templates" with the above idea.

Terminology

This is for providing feedback without the complexity of creating a pull request

Grammatical issue in "ConsumedThing interface" description in the section "WoT Scripting API"

WoT Scripting API

ConsumedThing interface as Cient API to and consume Things over the network or locally (e.g., physically attached hardware)

In the above description the word "and" after "to" is unnecessary.

Arrow between App+Scripts and TD in Fig. 10

In figure 10 (https://w3c.github.io/wot-architecture/#architecture-concept),
three arrows are drawn from 1)"Application + WoT Scripting API", 2)"Interaction Model", 3)"WoT Binding Templates" to "WoT Thing Description". But I could not find what aspect of "Application + WoT Scripting API" is written in Thing Description. I'd like ask guidance about that, but in case if there is no particular entity in TD which corresponds to "Application and WoT Scripting API", I propose to remove that arrow from Fig. 10.

P.S.
Are following words generally used in English specification?
looked like a little bit difficult to understand for us non-European readers.

• ergo (in 5.1) ->therefore?
• portmanteau (in 6) -> bag?

Terminology missing/inconsistent

The terminology used in this document is somewhat inconsistent with what I understood to be our consensus. For instance, does a Thing Description describe a Thing? Is a WoT Servient a kind of WoT Thing? Are there Things that are not WoT Servients (or WoT Servers)? Etc.

Also there are some terms that are used (like Thing) but not included in the list of definitions.

Finally the original definition of "WoT Server" was defined in terms of "web server" which is just wrong (it could, for instance, be a CoAP server).

I added some definitions in my last pull request but it needs a going-over.

Also, there is the question of whether we should be defining such WoT terms here or elsewhere in a document we can all refer to.

Video, Audio treatment

Currently, we are discussing streaming. But this streaming means continuous sensor values.
On the other hand, from the consumer electronics manufacturer's point of view, we have not discussed how to treat audio/video streaming/downloading. This might be out of scope of WoT standardization, but as architecture document, I'd like to point out audio/video is out of scope or not.

Grammatical issue in the first para in the section "7.1 WoT Client"

7.1 WoT Client

Figure 14 shows the basic scenario, where a Servient in client role, a WoT Client, is consuming an existing device that is augmented with a Thing Description (TD). The latter could be generated from digital descriptions already available for the device within the corresponding the IoT Platform. It could also be written by a developer using tools or even manually.

In the above highlighted text, the word "the" is unnecessary.

6. Mapping variations: Security and Privacy boxes in figures

The "Security and Privacy" box around the Servient figure was meant to indicate that we also look into the security considerations. In Section 6, this box looks like we, that is WoT technology, takes care of the secure channel between two Servients. However, that must come from the binding, as we only describe how to use the already provided security (except for TD securing and internal issues for the runtime). Furthermore, the box is quite confusing, when the black dashed box is used in addition to indicate device boundaries...

I would remove the "Security and Privacy" box and rather have good security considerations in the text -- and use details such as "HTTPS" instead of "HTTP"...

Fig.2 Protocol Binding Structure

With some distance after the F2F, Fig.2 does not really fit what we discussed (according to my memory). I saw an important step forward in the insight that there is no differentiation between "WoT protocols" and "non-WoT protocols". We have to describe in any case, in some cases it is just easier (when people use Internet+Web standards without custom edits).

Fig.2, however, shows oneM2M vs OCF vs WoT Device.

Kaz's handdrawn picture was better in the sense, as it reflected that there is no "standard WoT binding" that we have to translate to.

Mention Security also as a building block

In the abstract only TD, Binding, and API is mentioned as building blocks. Security should be also mentioned here as a building block.

Provide more information of the "Thing Directory"

Hi,

I think the Architecture document provides very little information about the "Thing Directory" module. Even, it doesn't reference the open source code in the github.
It would be nice to have a new section where it explains in more detail about this module. For instance, how the devices can located the "Thing Directory", uses cases, operations (TD registration, TD update, TD lookup...), examples...

Oscar

Refine Terminology for WoT Runtime

A WoT runtime can include several sub-components to handle communications, scripting, and protocol bindings. Several aspects of the specification, for example scripting, relate to only one of these components. This has an impact on how and where we discuss security considerations, among other issues.

Therefore the architecture document should define these sub-components and given them specific names.

Must close IG architecture draft

We still have two versions online: WG Editor's Draft and IG draft.

I was thinking, we decided to release IG draft as an IG Note, no? Anyhow, we should replace https://w3c.github.io/wot/architecture/ (IG draft) with a commented link to the WG Editor's Draft, and potentially the "archived" IG Note.

6.3 WoT servient on Smartphone - Browser as Servient

The idea behind Figure 15 should be discussed and and explained much more. I guess having WoT client functionality in the browser is quite straight-forward. However, the rather big aspect of implementing "System Things" and having hardware drivers etc. in Web browsers might be seen critical.

I guess we need to build a careful case that references the existing APIs about location, camera, etc. and visions such as the Web Bluetooth CG.

Best also add such an editor's comment box to ask for feedback.

Architecture > WoT Servient Architecture

The document as written seems to equate overall architecture with the internal architecture of the WoT Servient. I think these are different levels of description and I think we need to make to make it clearer that a WoT system may, in fact, not use the internal architecture of the WoT servient shown.

I think we need a "Network Architecture" section and a "Servient Architecture" section. The "Integration Patterns" section brought up by Matthias and some discussion of how you discover Things and get their Thing descriptions (or expose your own) could go in the Network section, as well as a general discussion of some other related issues (NAT traversal, CAs/HTTPS/offline use, local vs. global access, Discovery...)

Respec - Various normative references in informative sections

Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC8288]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC3987]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC3986]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC7231]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC7252]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!MQTT]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC4395]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC6838]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC7159]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC7049]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!EVENTSOURCE]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC5246]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC6347]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC6071]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC6749]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC7744]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!WOT-SECURITY-CONSIDERATIONS]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC7230]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC7540]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!HTML5]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC6455]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!WEBRTC]] at: 1.
Normative references in informative sections are not allowed. Remove '!' from the start of the reference [[!!RFC765]] at: 1.

Git edit link pointing to wrong repo

Git edit link in SOTD section of https://w3c.github.io/wot-architecture/ seems to refer still to old repo (https://github.com/w3c/wotwg/tree/master/architecture)?

Discovery API

A Discovery API is mentioned but not defined anywhere. Do we have one, do we plan to standardize one, or are we just talking in the abstract? It might be good to at least mention a few ways in which discovery could be implemented, how Thing Descriptions could be obtained, and so forth... even if these discussions are non-normative.

Typo / Disambiguation

5.4.2 Smart home: Legacy device
Fig.6 shows an example of WoT servient on cloud server that controls a legacy electronic appliance through a home hub.
In this case, WoT servient on cloud cashes properties of electric appliances that a home hub manages and acts as an agent that manages them in the cloud in conjunction with the home hub

'cashes' should be 'caches', right? ;-)

6. Mapping variations: Web browser

While an example involving the Web browser is probably quite catchy, the technical details are a bit confusing: for now, there is no WoT support out-of-the-box in Web browsers and they cannot speak the given examples, but "only" HTTP(S), FILE, FTP, and RTP(S).

I see two possible remedies for now:

1. Explain how this would work using a JS library (for parsing the TD and providing the Scripting API) and AJAX/XMLHttpRequestObject (as Protocol Binding).
2. Use a different WoT client.

Security Considerations

@mmccool : We still need content for the section "Security Considerations".

That section should clarify that we are primarily describing exsiting IoT platforms and their existing security mechanisms. Thus, in general the security considerations for each IoT platform used apply. Furthermore, we need to summarize what users of WoT building blocks need to consider (e.g., more accessible information might attract more attackers, TDs might leak information, TDs need to checked like any other information consumed on the Web, etc.

Can the security Task Force provide such a text?

Integration Patterns

There was a lot of feedback that the Integration Patterns were helpful to people. Mozilla created a somewhat cleaner image.

I also think it is useful and we should include it in the architecture, probably in the beginning before the Servient architecture. However, we should remove the "thing-to-cloud" focus, as we also need local connectivity (or "edge connectivity").

I will try to come up with figure. Can we add such a "Integration Patterns" section?