Meeting minutes
dirk: need to move the emergency use case to version 1.3
noreen: will make a new pull request for the same changes in 1.3
implied requirements
section 1
Specialized assistants MUST be able to interoperate with general IPA's
… we all agree
dirk: IPA's SHOULD be able to execute operations in a user's environment
noreen: the environment that the user controls regardless of the location
… IPA's SHOULD be able to execute operations
jim: IPA's should be about to execute user-requested operations
… we agree
dirk: IPA's MAY be able to interact with users through other modalities.
2.1.1 IPA's MUST be able to transfer a partially completed task to another IPA
IPA's MUST be able to transfer a task to another IPA, including incomplete tasks
IPA's MUST be able to transfer a task to another IPA, including tasks that MAY be partially completed
jim: some database tasks can't be partially completed, all or none
noreen: a task could be a series of transactions
we agree
dirk: The architecture SHOULD support question answering
dirk: The architecture SHOULD support information retrieval requirements
dirk: need to number the requirements
… then we can refer to them in other sections
debbie: cross-reference The architecture SHOULD support executing local services to accomplish tasks The architecture SHOULD support executing remote services to accomplish tasks
The architecture MUST support dynamically adding local and remote services or knowledge sources.
jim: also dynamically remove
dirk: for example, adding devices in a smart home
noreen: that could be a task that needs to be completed by more than one IPA
jim: if we move a lamp to another room, do we need to remove it and add it
dirk: this is more about context
noreen: when you move the lamp its attributes can change (like location)
jim: just "add or remove"
debbie: we should multiply out all the options
It MUST be possible to forward requests from one IPA to another with the same architecture
… this is similar to the partially completed tasks
noreen: the topic level heading of section 2?
dirk: problem statement and use cases
It MUST be possible to forward requests from one IPA to another with the same architecture, omitting the client layer
debbie: that rules out smart speakers
dirk: this means one IPA becomes the client for another IPA
… in the case of cars, the client can forward requests to Amazon, etc.
noreen: It MUST be possible to forward requests from one IPA to another using the standard architecture
(we just finished the 5th item in the architecture section)
dirk: still working on changes to interfaces document, also trying to add some sample requests using JSON notation
… there's one example in Github
… we can talk about that next time
debbie: will create a new requirements document
dirk: reverted changes to 1.2 and noreen put in a new pull request for 1.3