– DRAFT –
WoT Architecture/Profile

Agenda

Lagally: (goes through the agenda)

agenda for today

Minutes

Nov-30

Lagally: (goes through the minutes)

approved

Profile

PR 297

PR 297 - Revised Abstract and Introduction - fixes #115 and fixes #190

Lagally: hard to review

Sebastian: did you see the changes themselves?
… think it's a huge improvement basically
… I can't add further improvement until this PR is merged

Lagally: did see it
… some of the changes are really useful
… but we should thoroughly review each PR

Sebastian: would like to update the introduction section as soon as possible...

Lagally: currently we're focusing on the Testing
… so if you could hold it, wouldn't be harmful
… McCool is working on splitting this big PR

Kaz: we had discussion on this PR yesterday
… and decided that Michael McCool would split this PR into smaller pieces
… so Sebastian, if you want, you can also create a small PR to update the introduction section
… and let McCool and Lagally know about your new PR

Sebastian: would prefer merging this first and then add my modification

Kaz: again, the most of the proposed changes from this PR 297 should be included in the next WD
… but we want to review the whole changes thoroughly based on the decision yesterday
… in that case, Sebastian can generate his own smaller PR to modify the introduction section
… and maybe we can merge that PR first
… and review McCool's split smaller PRs for this PR 297 after that

Lagally: agree

Sebastian: would be easier to merge this PR first for examples, etc.
… and add my modification referring to them

Lagally: Sebastian, you can take several points from Ben's PR and generate your own PR

Sebastian: ok

Kaz: really appreciated

Authentication constraints

Thing Description 1.1 - 5.3.3.10 OAuth2SecurityScheme

<mlagally_> all-TD-implementations.csv

Lagally: difficulty with implementing OAuth authentication
… the right thing should be adapting the code flow

Sebastian: Siemens has been trying to implement it
… however, no guarantee for the Testfest

PR 331 - narrowing down oauth required flows

diff - 6.4 Security

Kaz: the content is ok
… but the description of the 2nd sentence is a bit odd
… first sentence: Conforant Consumers
… 2nd: A Thing
… 3rd: Conformant Consumers
… 4th: Conformant Things
… so the 2nd sentence should also say "Conformant Things", shouldn't it?

Lagally: would be better

Sebastian: does this question go to the Providers or Consumers?
… a Consumer might not support it due to performance issue

Kaz: do you mean a potential intermediary which supports OAuth security for a Consumer?

Sebastian: don't want to make the story complicated, though

Lagally: what we could do is requiring security
… BasicSecurityScheme is mandated and OAuth2SecurityScheme is optional
… let's ask McCool for opinion again

Links

PR 315 - Improve link assertions

Lagally: changes requested

diff - 6.5 Links

Lagally: (goes through the changes within the diff)
… (explains the Note)

NOTE
 These links enable consumers to interpret linked content that is
 provided by the link target in an unambiguous way. This interpretation
 is a "best effort" mechanism, that depends on the
 capabilities of the consumer. A consumer with a browser could render
 HTML content, a consumer with a PDF engine can display PDF content, a
 consumer with a dot-matrix display only can display icons.
 For consumers that can render images or documents this implies to
 display appropriate documentation to a human reader. Consumers that are
 capable of working with nested things and thing model structures are
 able to navigate between things and thing models in a well defined way.

Kaz: does this mean we expect the implementers to handle expected data to be negotiated between the server side and the client side like the language negotiation mechanism?
… e.g., en.html, ja.html, fr.html

Lagally: not really sure about language negotiation mechanism...

Sebastian: what you have there at section 6.5
… maybe you can list the possible link relation types there
… to be supported by TD
… can quickly check it

<sebastian> Thing Description 1.1 - 5.3.4.1 Link

Sebastian: link parameters listed within the section 5.3.4.1 of Thing Description 1.1
… with the assignment of mandatory or optional
… the first entry (href) and the last entry (hreflang) from the table within section "6.5 Links" to be removed

Kaz: all the information from the table is redundant, given there is already a table within TD, isn't it?

Lagally: Sebastian, you can create an issue about this

[adjourned]