WoT Architecture

spec alignment and publication blockers

Lagally: we should concentrate to find owners for all the issues

Kaz: Please can you clarify the expected schedule until end of November

Lagally: we want to have a feature freeze until end of Jan

Kaz: We should clarify which section should be normative.

Lagally: we are working for the 1.1 version, based on 1.0

Kaz: which should mark the sections which are under discussion
… we should categories the issues which are related to TD or to Discovery

Lagally: I like this idea

minutes review

Nov-18

any objections?

no

minutes are approved

WoT Architecture

<kaz> Issues marked as "blocks publication"

Issue 643

Issue 643 - Finding a place to put the security paragraph in the bindings chapter

Lagally: does this issue blocks publication?

McCool: we can defer this issue

Lagally: ok

issue #642

Issue 642 - Identify normative RFC2119 assertions that affect the TD specification

this is just a generic issue that calls for review

Lagally: is the list complete?

Ben: would be Ege here, he would mention that the list covers unclear or incorrect assertions

<benfrancis> https://github.com/w3c/wot-architecture/blob/main/testing/assertions.csv

Ben: the question is if we move all to the TD spec

Kaz: agree with Ben. given there are 42 normative assertions related to TD within the Architecture spec. I think it would make more sense to review the sections within the Architecture spec which includes those 42 assertions on TD than reviewing all the 42 assertions one by one.

Sebastian: I will check all of them. Im worried about the readiness of the Arch document when we remove all of them. Maybe some statements in the document will do not make sense anymore.

issue #641

Issue 641 - arch-hypermedia-origin : The hypermedia controls MUST originate from the authority managing the Thing that is providing the corresponding Interaction Affordance.

Lagally: ask for proposal for next week

issue #640

Issue 640 - arch-methods : Eligible protocols for W3C WoT MUST be based on a standard set of methods that are known a prior.

groups agree to remove this assignment

issue #639

Issue 639 - arch-uri-scheme : Eligible protocols for W3C WoT MUST have an associated URI scheme [[!RFC3986]] that is registered with IANA (see [[?IANA-URI-SCHEMES]]).

group agrees to remove this assertation

I already created a PR for it

-> wot-thing-description PR 1301 - update Section 8.3

Ben: I need time to review it

issue #638

Issue 638 - arch-op-extension : The set of predefined operation types MAY be augmented by Extension operation types chosen by applications.

groups decide to remove

issue #637

Issue 637 - arch-op-wellknown-compare : Well-known operation types MUST be compared using a case-insensitive comparison.

Lagally: TD spec should make clear that the op names case sensitive

Ben: I will take care of it

Lagally: after having this assertion can be removed

issue #636

https://github.com/w3c/wot-architecture/issues/636 Issue 636 - arch-consumer-configuration : The configuration of the Consumer behavior MAY be exposed through the Thing.

group agrees to remove this assertion

issue #635

Issue 635 - arch-id-correlation : An identifier in the WoT Thing Description MUST allow for the correlation of multiple TDs representing the same original Thing or ultimately unique physical entity.

discuss this yesterday in the TD call

McCool: belongs to TD spec and not in Arch

Lagally: we need to revisit again next week

Ben: +1 to have it in the TD spec. Is there a ok to remove from the Arch spec?

Lagally: yes

issue #634

Issue 634 - arch-thing-bundling : Things MAY be bundled together with a Consumer to enable Thing-to-Thing interaction.

group decides to remove it

Issue #633

Issue 633 - arch-property-readable : The state exposed by a Property MUST be retrievable (readable).

Lagally: remove this and will clarify it in TD
… consider mandating in Profile

Issue #632

Issue 632 - arch-td-consumers-process : Consumers MUST be able to parse and process the TD representation format, which is based on JSON [[!RFC8259]].

Lagally: wondering about CBOR

McCool: not precluding CBOR

Lagally: all TD must be JSON?

McCool: it's rather that every Consumer must process JSON

Ben: could be removed from the Architecture spec

Sebastian: would concentrate on the other topics

Lagally: ok
… let's have the detailed discussion during the TD call
… and remove this

Kaz: ok

Issue #627

Issue 627 - Chapter 10 uses non RFC assertions

Lagally: assigned to Ege

Issue #626

Issue 626 - Explaining of WoT operations

related to Issue 606 - Move Table for ops to TD spec

Lagally: need some more discussion
… think the Architecture spec should also explain the ops at a high level
… let's mark this Issue 606 as "blocks publication"

McCool: discuss this in the TD call as well
… kind of odd to have the same information at two places

Lagally: ok
… need some more discussion
… and need a leader for that

McCool: having the table at one table is one issue
… and having some description is another
… the question is that the table includes too much detail

Lagally: yeah, agree that's too much

McCool: maybe detailed defshould be initions in TD
… suggest we have some text on the Issue itself first

Lagally: ok
… who could work on that?

McCool: me and Ege

Lagally: tx

Next steps

Lagally: we've reviewed many of the issues marked as "blocks publication" today
… need further clarification about the 3 categories defined by Issue 641

* clarify the assertion in the architecture specification
* move the text section to the TD specification
* delete from the architecture specification

Lagally: Kaz, any suggestions about how to proceed?

Kaz: as I've been mentioning, e.g., during the Editors calls, my original suggestion was rather working on the sections of the Architecture spec one by one
… and see which sections and sentences within the sections from Architecture (1) should stay within Architecture, (2) should be moved to the other specs or (3) should be simply removed.
… so I didn't think we had to look into assertions at this stage
… however, we've been already looking into the assertions extracted from the sentences within the Architecture spec
… so for the next step, we can see which assertions are extracted from which sentence of which section, and identify which text to be removed, to be moved to TD, or can stay within the Architecture spec based on the review results.

Lagally: ok
… have we got owners for each issue yet?

McCool: you can assign me to Issue 635

Lagally: (assigns McCool to Issue 635)

Issue 635

Lagally: what about Issue 638?

Issue 638

(no volunteers)

Lagally: let's see next week again
… and Issue 626?

Issue 626

(McCool and Ege)

Lagally: (have added "remove" label to the issue to remove the assertion)

Profile

Issues marked as "blocks publication"

Lagally: (goes through the issues)
… we need prioritization here
… we need to see resolution for these issues

Ben: yes

Lagally: some more additional labels as well
… e.g., "close-next-week"
… for example, Issue 56

Ben: sorry I confused things
… intention was simply can be closed

Lagally: ok
… let's concentrate on "blocks publication" then
… regarding the issues marked as "close-next-week" can be marked as "close" to show it's proposed to be closed

Ben: can change the label

Lagally: would like to use the remaining time to find a review for each issue marked as "block publication"
… can have some more offline discussions if needed
… first, let's try to find owners

Issue 144

Issue 144 - Outdated reference to Architecture spec

Ben: can work on that

Lagally: tx

Issue 142

Issue 142 - Clarify RFC7807 Problem Details Format constraints

Ben: happy to take this too
… no action needed

Lagally: ok

Issue 141

Issue 141 - how to handle multiple forms

Kaz: not marked as "blocks publication"

Lagally: forgot to mark it, and adding the label

Sebastian: can work on this or with Daniel

Lagally: personally would having a single form

Sebastian: it's always problematic
… possible use cases should include IPv4 vs IPv6
… depending on the support by the Consumers

Lagally: it requires some more discussion
… (adds the label of "needs discussion")

Sebastian: if we can have multiple forms, I'm happy to work on that issue
… but if we need more discussion, would wait a bit

Kaz: are you still ok to be assigned?

Sebastian: yes

Issue 140

Issue 140 - Add reference to security best practices document

Ben: can take it

Issue 132

Issue 132 - Normative Canonicalisation format

McCool: had read the canonicalization part
… the term "canonicalization" itself is not correct any more
… all the constraint description to be move to the Profile spec, I think
… the question is if we need the constraints, one by one

Kaz: are you ok with working on this issue?

McCool: yes

Kaz: tx

Ben: strongly disagree moving the canonicalization section to Profile

McCool: note that it's actually not about "canonicalization"

Ben: discussing potential constraints?
… we definitely don't want to require canonical format

McCool: right
… so let's remove the description from Architecture first
… and then continue discussion on how to deal with that

Lagally: (adds comments on the discussion)

Lagally's comments

Issue 120

Issue 120 - Complete or remove JSON Schema of the Core Profile

Lagally: think we should remove this

Sebastian: having multiple JSON Schema for different purposes would be confusing

McCool: JSON Schema is a set of constraint
… could use it for additional constraints

Lagally: right

Ben: don't have problem with having JSON Schema itself
… but need clarification

Lagally: ok
… consensus to add a JSON Schema
… should rely on the Schema from the TD spec and provide additional rules/validations/constraints if any
… the set of constraints needs to be consolidated first
… before we can define the schema itself

Ben: ok

Lagally's comments

Issue 107

Issue 107 - Events - Scalable event mechanism for cloud use cases

Lagally: will take this

Issue 60

Issue 60 - Allow multiple forms for interaction affordances in Core Profile

Sebastian: can work on this
… same as another discussion

Ben: not completely the same

Lagally: overlap with Issue 141

Issue 17

Issue 17 - Vocabulary not in TD context

Lagally: Sebastian?

Sebastian: we've already covered this, I think
… only geolocation is covered by TD, though
… can take this issue

McCool: builtin ontology and external ones

Ben: Sebastian has already removed the term
… need to update the note
… can help

Issue 10

Issue 10 - Reduce the number of constraints in section 5.1 WoT Core Data Model

McCool: probably we'll discuss during the Security call too

Lagally: would propose assigning this issue to Ben, McCool, Sebastian and myself

Issue 6

Issue 6 - Recommended Security

McCool: assign this to me

Issue 5

Issue 5 - "Core" profile name has undesired implications

Lagally: to me

Issue 3

Issue 3 - Evaluate Data Schema Constraints

Ben: duplicated with Issue 10
… Issue 10 is broader
… so this is subset of Issue 10

Lagally: ok
… assign this to the 4 reviewers for Issue 10 then
… i.e., Ben, McCool, Sebastian and myself

Next steps

Lagally: for the next call, would expect to discuss PRs
… please continue to work on the issues/PRs

Ben: fundamental issues to be clarified
… so need prioritization

Lagally: yes
… aob?

(none)

Lagally: will generate another Doodle for possible new slot
… thank you very much for your contributions

[adjourned]