Meeting minutes
Minutes
Lagally: (goes through the minutes)
approved
Schedule
McCool: the schedule was tight and we've already missed some of the goals
… should think about the updated schedule for the next charter
Lagally: why don't we put "End of March" instead?
McCool: "End of April" would be better
… since we need 2-week review within the WG
… one month should be fine for the basic profile
… but would require 2 months if we include synch/asynch, etc.
… so resolution mid May
Kaz: is that a feasible one?
… probably we should think about two more milestones, e.g., difficult features for spec itself, and testing
McCool: yeah, testing is a big thing
… OK with adding those items
Kaz: for that purpose, we should clarify which features to be included in the CR draft at the end of April
… there are several possible options, I think
Lagally: (adds "Testing" as an item first)
McCool: regarding the features
… should be OK with publishing a CR with normative basic profile and informative actions, for example
Kaz: so we still need some more time to define the actual content for CR
McCool: right
CR draft: End April (6 weeks for wrap-up) 2 weeks review resolution to publish Mid May CR End May (at the latest) testing - In the next charter period
<benfrancis> I object
Contributions
PR 374
PR 374 - Define values of in and name for basic security scheme
McCool: (explains the PR)
… name is tricky here
… if there is a proxy, the value would be proxy.something
Lagally: (goes through the diff)
… have to fix the TD spec for the default value, technically
Ben: (explains his comments)
some Thing implementations might prefer the simpler BasicSecurityScheme if the only alternative is a full OAuth2 implementation.
Ben: Do you introduce the constraint on which is not available?
… do the HTTP Basic Profile allow us distribute the password?
McCool: don't think so
… the problem is we don't have barer token as an option here
McCool: we can leave it open
… and go back to the Security TF to have more discussion
Ben: would like to make you aware
McCool: "Basic" here doesn't mean basic HTTP authentication
… if we merge this PR, that means we would limit the standard ways
… think barer token is allowed to be used
fyi, RFC7617 The 'Basic' HTTP Authentication Scheme
Kaz: so the Security TF need to look into the problems. right?
McCool: right
PR 371
PR 371 - Async action clarifications
Lagally: (goes through the diff)
diff - 8.2.2.1.3 Asynchronous Action Response
Luca: this is an easier option
McCool: means "it might be a queue"
… it's an implementation detail
… this allows finite state machine
… finite and possibly empty
Luca: just asking for clarification here
McCool: would agree the approach itself
… but need to clarify the expected interaction
Kaz: I think we need to clarify the interaction scenario about what kind of information caused what
… starting with TD on the Thing
<McCool> (probably should let others on the queue talk...)
<McCool> +1 for creating issues for further improvements...
Kaz: there is text describing the behavior, but that assumes readers have enough background information like us, the WoT WG participants
<benfrancis> https://
Ben: merging this PR is fine but the first part is redundant
… I put the Note which has similar content above
Kaz: I'm OK with merging this PR itself
<McCool> (need to drop - main call coming)
Kaz: but we do need significant improvement about the whole description about the expected interactions within the spec
PR 297
PR 297 - Revised Abstract and Introduction - fixes #115
Ben: review comments have been addressed, and it's ready for being merged
[adjourned]