WoT Profile – 22 June 2022

Meeting minutes

minutes

from 06-15

<kaz> June-15

Lagally: PR #203 should be under "Cleanup"

Lagally: then talked about length limits
… please change section 2 title to "cleanup"

Kaz: fixed

Lagally: and issue #200 should add "Length and size limits"

Lagally: any objections to appoving?
… none, approved.

New Issues

Lagally: not time to discuss all today, but will review, discuss in git

Lagally: page 1 is all new issues coming in the last month

<kaz> Issue 234 - Simplified array syntax

Lagally: issue 234 - simplified array syntax

<kaz> Issue 233 - Define a constrained set of link relation types

Lagally: issue 233 - need constrained set of link types with unambigous semantics

McCool: generally for this I think we want to add only what we need, i.e. start at the small end of the egg

<kaz> Issue 232 - Define minimum set of supported languages

Lagally: issue 232 - minimum set of supported languages

McCool: mostly related to things with displays
… issue with politics here, which are the "important" languages?

Lagally: true, but could use Java/javascript ones

<kaz> Issue 231 - Simplified processing of bidirectional text in multi-language TDs

Lagally: issue 231 - bidir heuristics elimination

<sebastian> sorry, I will reconnect later

<kaz> Issue 230 - Make default language mandatory

Lagally: issue 230 - default language mandatory - not optional

<kaz> Issue 229 - remove http-webhook-profile-protocol-binding-general-2 assertion

Lagally: issue 229 - webhook protocol binding

McCool: so one weird thing here is what if we have three? This sets up webhooks as an alternative to SSE, but what if there is a third option, or you don't use it at all?

Lagally: also, regarding whether baseline is needed or not as part of SSE profile

<kaz> Issue 228 - Is HTTP Baseline required for HTTP Webhooks or SSE?

Lagally: issue 228 - baseline part of SSE or not

<kaz> Issue 225 - Retried events in Webhook Profile

Lagally: issue 225 - retried events in Webhooks
… ege is suggesting being stricter

McCool: being too strict may make using libraries harder

Kaz: agree
… suggest we invite existing implementers and ask about their approach

McCool: also, number and spacing of retries does not affect interop, so maybe out of scope

<kaz> Issue 224 - subscribeallevents security requirements

Lagally: issue 224 - subscribeall security requirements

McCool: generally different access controls for different affordances
… access controls are a thing, sorry they aren't RESTful
… guess I should comment

<kaz> Issue 223 - Example 46 is not about subscribeallevents

Lagally: issue 223 - minor, will address

<kaz> Issue 222 - Security Requirements for WebHook Consumer

Lagally: issue 222 - security requirements for webhook consumer

McCool: probably the thing to do here is provide all needed information to support webhook, including things like bearer tokens for access

<kaz> Issue 221 - Security Schemes are too loose

Lagally: issue 221 - security schemes are too loose

Lagally: agree, needs to be more specific

McCool: agree, need to narrow

McCool: agree, needs to be narrowed to standard HTTP usage

<kaz> Issue 220 - List of required Security Schemes

Lagally: issue 220 - too many security schemes

McCool: maybe, digest and basic do overlap

<kaz> Issue 219 - Common Rules apply to all profiles

Lagally: issue 219 - common rules apply to all profiles?

<kaz> Issue 218 - JSON Schemas for profiles

Lagally: issue 218: JSON Schemas for all profiles?

Lagally: yes

<kaz> Issue 217 - TD version dependency

Lagally: issue 217 - TD version dependency, should say TD 1.1
… agree

<kaz> Issue 215 - Explaining why HTTP Basline Profile has Information Model Constraints

Lagally: issue 215 - explanation would be useful for info model
… agree

<kaz> Issue 214 - Wrong sections/headers for HTTP profiles

Lagally: issue 214 - wrong section/headers - editorial

<kaz> Issue 213 - Wrong place to use HTTP Baseline Profile

Lagally: issue 213 - wrong place for use of HTTP profile

Event Payload Format for Webhooks

<kaz> Issue 222 (revisited) - Security Requirements for WebHook Consumer

McCool: so one comment, issue 222, may mean that we want to add security information to the payload format

<kaz> PR 198 - WIP: event payload format

Lagally: may be more for subscription; let me first review PR
… was based on digital twin use cases
… need clear way to describe event data
… relate this to the cloud events specification
… encodes timestamps, and event source (e.g. affordance)

McCool: and also an actual payload?

Lagally: yes, and also a type

McCool: also wondering how we deal with non-JSON data, e.g. an image; do we have to use base-64 encoding, etc?

McCool: more generally, ready to merge, or still WIP?

Lagally: still WIP, need more input
… some arguments that need something simpler, could be its own "Digital Twin" profile

Length and Size Limits

<kaz> Issue 200 - Revisit length limits

Lagally: looked into a couple of constraints that may be inspiring
… e.g. URL length, e.g. 255

McCool: random thoughts, particular formats can avoid needing to specify length limits, i.e. if we say ids are uuidv4, length limit for id redundant
… as for URLs, issue is long query parameters, i.e. encoded SPARQL queries
… want to avoid breaking things
… but in general long URLs tend to result from query parameters