Meeting minutes
Minutes
<kaz> May-14
<kaz> (minutes approved)
PR review
PR # 419
<kaz> PR 419 - Explicity state contentType of application/json in Forms - closes #141
Ben: How does a TD consumer select from multiple forms?
<kaz> related Issue 141 - how to handle multiple forms
Sebastian: We don't need to explicitly specify applicatoin/json in the form because it is the default
… TD 2.0 will also have global definitions that might help with this issue
<kaz> Diff: 6.2.1.1 readproperty
Ben: The TD spec is not clear enough about the behavior of default content types
Sebastian: Here is a link to the TD spec section
Ben: (reviews the algorithm for content type selection in the profile document )
Sebastian: (explains the content selection algorithm commonly used by WoT clients)
Sebastian: A client does needs to know which content type it needs and need to look in the form
Ben: there are some cases that won't work
Kaz: we should make an issue for TD and go ahead with Profile 1.0
Ben: I have made an issue for TD 2.0
… will leave the issue #141 open for discussion
Sebastian: to clarify, the redundancy doesn't hurt, and we can improve the definition in TD 2.0
Cristiano: It seems appropriate for Profile clients to look for application/json content type
WIP PRs
Ben: can the WIP PRs be closed or merged??
PR #334
<kaz> PR 334 - WIP: Provide example in the new introduction section
<kaz> Ben's comment on PR 334
PR #271
<kaz> PR 271 - WIP: Common constraints - identifiers
Ben: I don't think using urn:UUID is necessary
Sebastian: agree
… it it's important to use UUID URNs you can do that
Ben: Does anyone disagree that this isn't necessary?
Sebastian: We should leave this for Lagally review
PR #314
<kaz> PR 314 - WIP: Allow auto security scheme for other permitted security schemes
Ben: For this one we should wait for McCool to return
PR #330
<kaz> PR 330 - Cloud Events Message Format
Ben: there is disagreement about cloud events
… it was for Profile 1.1, should we keep it open
Sebastian: Cloud Events has been used in the market but I'm unsure about the formal specification
… We should discuss more
Cristiano: if there is no activity, we can close the PR and re-open if we need more discussion
Ben: OK to close the PR with comments?
… OK, will close
PR #417
<kaz> PR 417 - A start on use cases and requirements for Profiles 2.0
Ben: This was to drive consensus on the requirements for Profiles 2.0
… We could leave it open to continue the discussion
Ben: any opinions?
Kaz: It was resolves that a task force can work on the use cases and requirements
Ben: It's important to have a central place for use cases but also a separate place for each specification
Issues review
Issue #255
<kaz> Issue 255 - Remove or re-work section 6.1.2 Links
Ben: The idea is to constrain the use of link relations for interoperability
… It's difficult to make testable assertions
… Is fixing this important for TD 1.0?
Cristiano: Is the concern stability or interoperability?
Ben: The concern is tetestability
Cristiano: agree that is is difficult to test
Ben: There are a couple of ways we can improve this
… We can remove it or we can fix the text
… What do we need to do for the Profile 1.0 note, considering testability is not as important for a note?
Cristiano: The content is useful as informative to have in the document, and will improve the note
Kaz: I agree, and suggest we add a clear explanation in the text as an editors note
<kaz> Ben's updated comment
Issue #258
<kaz> Issue 258 - New section on Webhook message format
Ben: This proposal for webhooks is aligned with SSE
… the metadata is in HTTP headers instead of the body
Ben: It avoids the need for a content wrapper
… does this need to be fixed for 1.0?
… It is needed for interoperability
Cristiano: Should we remove this section?
Ben: We might define our own payload format or use the header approach
Cristiano: The webhook is easier to use with Profile 1.0
… because the payload is described in the data schema
Kaz: This discussion should include the binding group
… Webhooks don't need to be resolved for Profile 1.0
Ben: Agree thet 2.0 is the place to resolve this, the issue is that there is a specific requirement in Profile 1.0
Kaz: minimum effort is the guidance
AOB and Adjourn
Ben: adjourned