<kaz> scribenick: dezell

Guest

McCool: Christian_Kurze is an invited guest today, and aware of the W3C Patent Policy commitment

Prev minutes

<kaz> July-20

(edits to minutes - SPARGL = SPARQL)

Approved.

<kaz> (typo fixed)

PR 35

<kaz> PR 35 - initial WoT Discovery outline

<kaz> (already merged)

PR 38

<kaz> PR 38 - draft registration API

Outstanding PR against draft (on index)

<kaz> diff for PR 38

McCool: TD should have its own section, but a separate section for issues
... Put the TD as a listing before 8.2.2.1.
... refer to the formal definition of the API elsewhere.

<kaz> section 8.2.2 Directory Service API

Farshid: should we use "no sec" or OAuth?

McCool: OAuth. We need some different specifications about how local directories are controlled.
... in general, we can't trust WiFi security for directories.
... guests on your WiFi may get too much information.
... plus, there are no levels of security in WiFi.
... should refer to "HTTP" and "TLS" - HTTPS is not a standard.

Farshid: I've had trouble with the rendering file.

McCool: yes, it's complex to set up. Let's get the listing in the document, and then we can experiment.

<McCool> look at https://github.com/w3c/wot-thing-description/blob/master/index.html#L470

<McCool> suggest putting this at the top (in the section "header")

<kaz> [[
<aside class="example" id="simple-thing-description-sample" title="Thing Description Sample">
  <pre>{
  "@context": "https://www.w3.org/2019/wot/td/v1",
  "id": "urn:dev:ops:32473-WoTLamp-1234",
  "title": "MyLampThing",
  "securityDefinitions": {
    "basic_sc": {"scheme": "basic", "in":"header"}
  },
  "security": ["basic_sc"],
  "properties": {
    "status" : {
      "type": "string",
      "forms": [{"href": "https://mylamp.example.com/status"}]
    }
  },
  "actions": {
  "toggle" : {
    "forms": [{"href": "https://mylamp.example.com/toggle"}]
    }
  },
  "events":{
    "overheating":{
      "data": {"type": "string"},
      "forms": [{
        "href": "https://mylamp.example.com/oh",
        "subprotocol": "longpoll"
      }]
    }
  }
}</pre>
</aside>
]]

Farshid: I will make modifications and bring them back next week.

McCool: We have a security best practices document (1. Secure Transport).

McCool: we need to add a reference to the right version of TLS.
... "Sub-API to register a TD" needs to include response codes.
... boilerplate at the beginning of TD (section 2. Conformance) see RFC references.
... the "class" id is unique to the document, e.g. "rfc2119-assertion"
... MUST, MUST NOT, MAY are the most important assertions.
... avoid pronouns like "this" and "that" or "it" since it can be very unclear.
... we will await updates next week.

Farshid: two other topics - mutable IDs (I've created an issue).
... my argument is that you might want to change the ID of an item you buy.

<kaz> Issue 39

Farshid: wanted the ID of the resource is the same as in the TD. It's impossible to delete and then create.

McCool: not sure you want to reuse an ID if it's already there. Privacy risk?

Farshid: I've already explained how to do this switch, but we need (at least one) use case.

Kaz: I think there are two viewpoints - the viewpoint of ID's lifespan vs. the viewpoint of players within the system.
... we're already thinking about players like device and directory, but thinking about ID's lifecycle and lifespan would be useful to clarify how to deal with what ID.

McCool: "rotating" IDs requires destroying and recreating a record.

McCool: this rotation may (or may not) have impact on the TD.

Cristiano: if we differentiate between local and TD IDs, doesn't that mean the same TD can be registered multiple times?

McCool: yes that could cause trouble.
... also, devices may register repeatedly.

Farshid: if you POST a TD, you should be able to post it multiple times, and get a different reference for each, whereas PUT would overwrite.

McCool: discovery should de-dup, and return the previous ID.

Farshid: RFC says POST should not be idempotent.

Cristiano: I'm not sure the REST approach is keeping us from considering the other IoT protocols.

Farshid: this description follows the resolution to use HTTP.

McCool: we should probably consider CoAP. But there are payload limitations, and other nits.

Christian: (couldn't quite here)

McCool: we can query on the ID - a stable URL to refer to a TD.
... I've added an entry for "super-classes" for TDs that are "templates" which could help guess at URIs.

Publishing Schedule

McCool: There's a certain amount of time (3 months?) to get adequate external review.
... so we should aim for October for our Candidate Recommendation.
... do people feel FPWD is doable by first of September?

Farshid: can we skip sections?

<inserted> (further discussion on the updated schedule to be done during the WoT Chairs call on Wednesday, July 29)

Section assignment

Andrea: I've been waiting for an indication that we should start? It would speed up if we assign sections.

McCool: I assume Farshid will fill in the rest of the API.
... I was going to do the Architecture and related sections.

Andrea: I can help with introduction.

Toumura: I can help with that as well.

McCool: I'll do a first cut, and should have a version people can look at next week.

Toumara: will do Introduction Mechanisms.

Farshid: will do directory API except search (for Andrea).

McCool: will do Introduction and Architecture.

<McCool> https://github.com/w3c/wot-usecases/pull/33

Horizontal discovery use case #33

McCool: I've added discovery use case and variants.
... run-time discovery, development-time discovery. Thing templates may help in developing these.
... added security considerations.

[adjourned]