Meeting minutes
Agenda
Lagally: I would like to focus on the eventing model
minute review
<kaz> agenda
<kaz> Feb-16
Lagally: anything to change?
<kaz> (typo fixed, and minutes approved)
Out of the Box Interoperability
<kaz> PR 176 - OOTBI section
Lagally: i have added link to h-2020 project
Lagally: i have added interoperability definitions into the text
Lagally: we can do the editorial fixes later after merging
<kaz> (PR 176 merged)
requirements
<kaz> PR 175 - incorporating accepted requirements
Lagally: I have added the accepted requirements with the supporters in the comments
Lagally: We can delete them later as well
Lagally: we should polish the text later
McCool: I think the editors note is important
Lagally: I am ok to change industrial vs home
Lagally: other comments?
Ben: generally use cases and requirements are described by a separate document in w3c specs but we can deal with that later.
<kaz> (merged)
PR 130
<kaz> PR 130 -Add Use cases section
McCool: I agree with Ben that we should not have two use cases to maintain
McCool: requirements should be driven from use cases. thus, it is better to have these in the use cases document so that internal links work better
Lagally: this is not a new use case
Ben: I am ok with the text except for the last sentence
Ben: profile does not enable cross protocol interoparability so the text is misleading. You will need custom adapters
Lagally: The text says enhancing
<McCool> ack
Ege: I also agree with mccool
Lagally: can we approve this MR then?
(group agrees)
Kaz: just to make sure, pr 130 to be merged after fixing the 3 sentences right?
<kaz> separation of the interaction model and the protocol binding.
<kaz> This separation makes it possible to define common protocol agnostic
<kaz> rules that enhance interoperability between different protocols.
Lagally: right
PR 109
<kaz> PR 109 - preparing implementation report - cleanup assertions
Lagally: I was removing rfc assertions
McCool: we should rerun the tool then, which will remove some assertions
Lagally: mandating json schema makes a lot of sense
Ege: there is an annoying problem with the format keyword that different json schema implementations use the formats in different "lazyness" levels, like checking @ sign for email or doing full regex validation
McCool: this is just a cleanup though
McCool: please create a separate issue on that
event model
Lagally: there are TDs from TUM, Siemens and NHK that use longpoll
McCool: if the Consumer cannot have the server functionality
Lagally: I would approach this in another way, we can have a conditional language
Ben: we just merged a requirement saying that consumer must be able to interact with all interactions
Ben: so if the Thing has webhook as the single event approach, some consumers cannot use it
Ben: so I think that for this we would need a separate profile for this
McCool: we can also define a profile without events
McCool: we have multiple options, let's list them and weigh pros and cons
McCool: we can have fallback
McCool: like if the Thing cannot offer webhooks, it must offer sse in the worst case
Ben: having server capability requirement on consumers imply change for all interactions
McCool: let's open an issue for discussion
Ben: we have already 6 issues on this topic, another issue will not help
McCool: let's pick one in this case
Lagally: I think we should list them
Ege: I think that having options for consumers or fallbacks, increase implementation complexity for consumers
… not having events means that if my use case have events, I will not be able to use this profile and write non-profile TDs
<kaz> kaz: given we're out of time, I agree we'll continue the discussion next week, but we should think about how to proceed as well, e.g., need another use case? need a concrete implementation?
PR 117
<kaz> PR 117 - Add Identifier section to Core Profile - closes #111
Lagally: any objections to merge?
Lagally: (merges)
Lagally: aob?
adjourned