W3C

– DRAFT –
WoT Architecture

11 November 2021

Attendees

Present
Ben_Francis, Daniel_Peintner, Ege_Korkan, Fady_Salama, Kaz_Ashimura, Michael_Koster, Michael_Lagally, Ryuichi_Matsukura, Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Lagally
Scribe
dape, kaz

Meeting minutes

Agenda

Kaz/ML: Agenda bashing

Kaz: would suggest we check the WG Charter extension plan right after the minutes review

<kaz> https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md

Minutes review

Nov-4

Lagally: Any objections?

-> no objections -> minutes approved

WG Charter extension

<kaz> Extension plan

Lagally: 10 steps
… 0. Clarify normative sections
… 1. roll back
… 2. normative feature freeze for TD & arch
… 3. start to get wide review

<kaz> 0. Clarify which normative sections should be included or should be improved in TD 1.1, Profile, Arch 1.1, and Discovery by end-Nov

<kaz> 1. Roll back TD spec to 1.1 (1.0 compatible) features by Nov 30

<kaz> 2. Normative features freeze TD 1.1 & Architecture spec by Dec 15

<kaz> 3. Start to get wide review including TAG, Accessibilty, Privacy, Security, and Internationalization to review TD 1.1 draft (note: might take 6 month)

<kaz> 4. Normative features freeze Discovery spec by Dec 15

<kaz> 5. Feature freeze Profile spec by Jan 31

<kaz> 6. Testfest in mid-Feb

<kaz> 7. CR transition in mid-March

<kaz> 8. PR transition in mid-April

<kaz> 9. REC transition before end of extended charter end of July

Lagally: idea was to have 12 mo extension

Lagally: instead of 6 mo

Daniel: quick comment
… preliminary decision for 12mo
… but this plan still says 6mo

Lagally: right

Lagally: made preliminary decision yesterday. Should decide today

Ben: 6 month time line
… does it affect the timeline if we go with 12 mo
… v2.0 delayed
… can we recharter if we finish early

<kaz> discussion on WG Charter extension during the WoT main call on Nov-10

<kaz> [[<sebastian> preliminary resolution: the group decide to extend the current WG charter for 12month. A final decision will be made in tomorrow's Architecture call. An email will be sent to the WG group as reminder.]]

Kaz: We will ask for 12 mo extension
… but we would like to keep 6 mo schedule
… just for potential delay
… PLH agreed with new plan
… we can renew charter for 2.0 in parallel

Ben: Sounds good
… can we have a new charter earlier

Kaz: Yes

Lagally: final resolution should make clear that we stick to freeze dates

Sebastian: would like to mention that my goal is to release v1.1 as soon as possible
… can start work for 2.0 earlier

Lagally: TD finalized within 12 months ?

Sebastian: That's the plan
… we started already to work on 2.0

Lagally: 2.0 may have impact on other documents

Kaz: we concentrate on 1.1 in this charter period
… should check deadlines periodically

Lagally: Why don't we make a clear decision that 2.0 does not go into this charter
… put 2.0 in new charter

Kaz: we've been talking about potential features for TD 2.0 but we've been deferring those features to the next Charter period by adding the "2.0" label.

Sebastian: backwards compatibility issues with 2.0

Ben: 2 separate documents in current charter, TD update and TD next

Sebastian: Correct. Other documents currently should rely on 1.1 for now

Lagally: Suggest to identify use-cases for new features

Lagally: does anyone have concern with 12 mo extension?

Lagally: <adds note about keeping 6 mo schedule>

<mlagally> proposal: call participants agree to the 12 months WG2021 Extension Plan as described in https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md

<mlagally> proposal: call participants agree to the 12 months WG2021 Extension Plan as described in https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md. This has been already prelimiarily approved in yesterdays main call.

RESOLUTION: call participants agreed to the 12 months WG2021 Extension Plan as described in https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md. This has been already preliminarily approved in yesterdays main call.

Clarify specification structure

Remove External TD representations section

https://github.com/w3c/wot-profile/pull/123

Lagally: Canonical TD removed from TD and from profile?
… not sure if we should do that

Ben: repeating information from TD spec
… canonical no longer used in profile

Sebastian: if Canonical text is in TD we should remove it from profile

Lagally: Does it explain all aspects like pure JSON parser is sufficient ?

Sebastian: Yes, basic setup of TD

Lagally: What is default encoding format for TD?

Sebastian: JSON-based serialization

<kaz> diff version - 5.2.4 Error Responses

Ben: default is JSON, but it can be JSON-LD annotated

Lagally: On canonical TD mentioning. I think having it in profile makes sense.
… heard concerns about implementing canonical TD
… was confusing to me

Ben: no mentioning of canonical TD any longer, therefore I removed it

Lagally: The content is not complete yet. we need to keep that in mind

Sebastian: at the moment canonical TD is covered by the TD spec
… no need to repeat in profile

Lagally: Feature is at risk, right?

Sebastian: yes, depends on available implementations

Lagally: The text in profile is not normative

Ben: Yes, but it is in conflict with the TD text

<sebastia_> https://w3c.github.io/wot-thing-description/#canonicalization-serialization-json

Lagally: Suggest to wait till TD includes the feature (or not)

Ben: Unfortunately it is a different specification

Lagally: To make progress. Let's wait until we know how canonical TD moves on in the TD spec

Ben: it is not used in the profile as of now

Lagally: Plan was to have a signing TD section

Ben: I don't think that belongs to profile

Sebastian: McCool is working on signing document
… it turns out it is not ready
… we should not refer to
… standardized solution by W3C is going to come
… I agree with Ben, signing should not go into profile

Sebastian: The canonical TD section will be kept until we start PR transition
… mid april
… after that we will be removing it (IF we don't have enough implementations)

Lagally: its unfortunate to have forward references to documents that are to be written in the future

<benfrancis> https://w3c.github.io/wot-thing-description/#canonicalization-serialization-json

Sebastian: We should just be sure that text is compliant
… should also avoid redundancy

Lagally: Yes, and misalignments

Lagally: Okay, let's approve PR#123

Kaz: Do we want to have this feature normatively
… we should decide that first

Lagally: Normative canonical TD format does make sense

Kaz: I see, since we cannot deal with it now we should move it to open issues

Daniel: Canonical TD feature is needed, but for the TD in general, not for the profile only

Kaz: right. the purpose of WoT Profile is a collection of subsets of features from the WoT specs, so we don't need to redefine any features within the WoT Profile itself.

<mlagally> https://github.com/w3c/wot-profile/issues/132

Lagally: let's create an issue (see above)

Add Discovery section

https://github.com/w3c/wot-profile/pull/121

Ben: Goal of profile spec is adhoc interop
… currently there is no text in profile how to find/retrieve TD
… simplest mechanism is "direct" discovery
… that's all what the addition says, URL retrievable

Sebastian: I miss a convention how the URL looks like
… like well-known pattern known from CoAP
… a pre-defined URL would be good
… or root address

Ben: discovery spec does propose well-known pattern

<kaz> diff version - 5.3 Discovery

Daniel: well-known is based on host level
… does not work for multiple things

Ben: in discovery spec are 2 stages
… well-known in introduction mechanism
… thing or directory
… in case of multiple things you need to have a directory
… hence it is not a good fit here

Lagally: requirement of thing or TD

Ben: Does not matter, can be hosted by the thing itself or by a cloud service

Lagally: Why do we require HTTP url
… could be a file ?

Ben: I argue that if TD cannot be retrieved via HTTP it is not a WebThing, rather a thing

Lagally: I can see many use-cases
… we put constraints and forbid other scenarios
… out-of-band is fine for me

Ben: I take the point
… long-lasting issue to have a discovery section in profile
… this is the simplest mechanism
… if we think this is too much, I can live without

Sebastian: out-of-the box interop raises the question where to get the TD
… without such a requirement we miss that capability

Ben: This discovery mechanism is basic
… DNS would be too much of a requirement

Lagally: I suggest we make things self-descriptive
… knowing URL of thing should be sufficient

BF/SK: Not sure what is needed

Lagally: Simple, define fixed string property "td" that always reports TD

Sebastian: Agree, but we do not need to define property

Ben: IP address /domain still needs to be known

Lagally: Mandatory endpoint

Ben: What about multiple things on gateway (same hostname)

<kaz> WoT Discovery - 5. Introduction Mechanisms

Sebastian: Master array

Ben: Is a directory, right?

Sebastian: Yes

Kaz: details of discovery should be described by the WoT Discovery document .. not here

Lagally: What is missing?

Ben: Link, currently we reference direct

<benfrancis> https://w3c.github.io/wot-discovery/#introduction-mech

Ben: I am hearing we should reference well-known also

Kaz: direct + well-known for the Core Profile within the WoT Profile document.

Lagally: Question, do we enforce well-known scheme in profile

Ben: I am OK with that
… tricky if gateway host multiple things
… maybe having direct mandatory, well-known optional

Sebastian: I don't think it helps, might miss IP

Ben: I am fine with making both mechanism mandatory
… I just want to make clear that requires directory service

Ege: https://esiremotelab.esi.ei.tum.de:8081/ shares array of TDs
… points to TDs

Ben: Does not work with well-known
… for multiple things

Sebastian: topic should be covered by discovery spec

Ege: well-known works well in local network

Sebastian: Just a list of links
… should have links container

similar to http://plugfest.thingweb.io:8083/

Lagally: Couple of options
… we don't consider aggregates things
… container aggregation with links container
… not sure about complexity

Lagally: Suggest to have self-description

Ben: I think you mean well-known uri ?

Lagally: Yes

Ben: Okay, can work on that
… still see issues with hosting multiple things

Kaz: profile can have both, direct and well-known?
… the problem here is rather that the WoT Discovery spec still needs updates

Lagally: I think the direction is clear. We want a link to get a TD without significant overhead

Ben: I can work on the topic

Add use cases for profiles section

https://github.com/w3c/wot-profile/pull/129

Lagally: I have to PRs on use-cases
… motivate

Lagally: other PR is https://github.com/w3c/wot-profile/pull/130

<mlagally> https://github.com/w3c/wot-profile/pull/130

Lagally: please provide feedback

<mlagally> Please review until next week.

Ben: I looked at the PR
… initial feedback seems to be a duplication of text
… other specs don't have use-cases section
… not sure if we need to have it in profile

Lagally: Text comes from use-case document
… help to understand scope and context

Sebastian: Similar comment. I think we have use-case document
… maybe we can reference use-case sections
… I would like to see "who benefits from the profile"
… motivation is somewhat missing

<kaz> diff - 4. Use Cases and Requirements

Lagally: It is a summary from use-case document
… just pointing to use case document is not enough

Kaz: Summary text can be included but maybe in introduction section

Sebastian: I am concerned about amount of topics
… I think we should concentrate on technical decisions

Lagally: No new details, helps the reader

Sebastian: Anyhow, should put our focus on technical discussions

<kaz> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/130/d51d816...47508a1.html#profile-use-cases

Kaz: anyway, this is rather additional rationale description for WoT Profile in general
… so should be included in the Introduction section after shrinking the text a bit

Lagally: please look at the text also

Next call

Lagally: we've done PR 123, 117, 121, 131 and 129
… would continue the discussion during the next call

Ben: would like to think about the decision making policy again
… currently we make decisions during the weekly calls

Lagally: from my viewpoint, the mechanism works good so far
… would like to hear from everybody for opinions, though

Kaz: we need to identify which Issues/PRs need what level of discussion

Ben: note that I've split my big PR into several smaller PRs for easier review

Lagally: let's discuss the potential new procedure for making decision during the main call

Ben: ok

[adjourned]

Summary of resolutions

  1. call participants agreed to the 12 months WG2021 Extension Plan as described in https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md. This has been already preliminarily approved in yesterdays main call.
Minutes manually created (not a transcript), formatted by scribe.perl version 159 (Fri Nov 5 17:37:14 2021 UTC).