Meeting minutes
Minutes
McCool: (goes through the minutes)
approved
PRs
PR 276
PR 276 - Fix typo, context, and ontology
McCool: mostly editorial
Farshid: good to get some more reviews
… e.g., from Andrea
PR 273
PR 273 - Things API with optional CRUD
Farshid: please see the diff
diff - 6.2.2 Directory Service API
McCool: why don't we move the extra sections to the bottom?
Farshid: ok
… regarding the Editor's note, just added some sentences
… but the diff is broken
McCool: (then shows the text at the bottom of section 6.2.2
McCool: (then 6.2.2.1)
McCool: we should have actual terminology for "full HTTP directory"
Farshid: this is a section for HTTP
McCool: maybe still good to have a clear terminology definition
McCool: (goes back to the PR itself, and adds comments)
… this comment might be a bit out dated
Farshid's comment 7 days ago about multiple forms
Farshid: already removed
McCool: should be a bit cleaner
… generic consumers trying to talk with the Directory may have some problems
Cristiano: you can select one form
McCool: (puts comments)
<FarshidT> multiple forms
McCool: can you create an issue now?
… and we can merge this PR itself
Discussion: Farshids thinks this is broken (maybe messed up as part of an earlier PR) and needs to be fixed. McCool thinks at the very least that putting forms distinguished by different contentTypes in a single interaction is inconvenient for Consumers. Farshid will create an issue and will investigate.
McCool: OK with merging this PR
… but a bit confusing
McCool's comments on further clarification
McCool: let's merge this PR itself
(merged)
Kaz: in that case, your comments on further clarifications are included in Farshid's new issue. right?
McCool: most of them have been already fixed
… and remaining points are included in Farshid's issue and we can look into the minutes as well
PR 274
PR 274 - Specify Consumer Discovery Process
McCool: probably we need some more clarification on server/client within Architecture
… (visits Farshid's comment 7 days ago)
McCool: (adds a new comment)
Thought I fixed this, let me checked (won't merge suggesting in case it screws up my other commits... but will take into account in my edits)
<FarshidT> Issue to validate forms: https://
@@@ above issue to be moved later (to PR 273)
McCool: (goes through the other comments on check points)
McCool's comments on check points)
McCool: maybe "D-client" might be redundant
… the whole point here is need for the name for "Discoverer"
… sounds like "an entity capable of doing Discovery" which is not
we could do:
… opt1: "Discover" rather than "D-Consumer" and "D-Client" and use anothr term for the current meaning, e.g., Registerer
… opt2: leave it as is
… opt3: get rid of "D-Client", however, definition of "Consumer" implies interactions with Things
… including endpoint Things
tou: would prefer different terms
McCool: the consensus here is
… do 1 and also use this to resolve 3
… say a "Discoverer" MAY be a "Consumer", but not necessarily
Kaz: would suggest we once think about the name of the entity and the roles of the entity separately
McCool: let's see how to solve this within the terminology from Architecture
… (then goes through the other comments)
comments on change name of section, clean up text in Architecture, etc.
McCool: let's see the section on "Exploration Mechanisms"
A device intends to publish an entire TD which contains private and public parts: publish one TD (Thing Link) with only the public information referencing another TD which contains the full description.
McCool: (adds a new comment)
I think the last use case is not really "describedby" but "extends" or similar. I propose we remove it: A device intends to publish an entire TD which contains private and public parts: publish one TD (Thing Link) with only the public information referencing another TD which contains the full description.
Farshid: "Not having extra metadata" should not be a consequence of ThingLink itself, but of the describedby relation.
McCool: think it i cleaner if ThingLink does one thing
… Private/public decisions are an access control policy, and should be decided when the TD itself is delivered.
… ThingLink is an introduction mechanism
… don't want to mix metadata within links
Farshid: in that case, why do we need a type for links?
… just need describedby?
McCool: if we leave it open, then my preference is not disallow the metadata
… at this point
McCool: the consensus is
… delete the use case
… but don't disallow metadata in Thing Links
Kaz: in that case, it's actually possible from the spec viewpoint, but we don't want to encourage people to use it at the moment
McCool: right. not recommended
McCool: (next looks into Cristiano's comment)
Cristiano's comment on the Editor's note
McCool: if it's open for any kind of protocols, implementation would be suffered
Cristiano: right
… it's completely left open
… it seems to be reasonable t say we can allow HTTP and CoAP
… but it would omit some others, e.g, FTP
Kaz: we're out of time, so let's wrap up the discussion for today
[adjourned]