Meeting minutes
agenda
<kaz> Agenda
Lagally: first item spec alligment
… I labeled publication blockers
… a spec alligment issue is also a blocker
… we have a PR from Ege, I left a review
Ege: still need to check the review points
Lagally: after this first section we have profile section, where we'll discuss publication blockers as well
… clarification of the document structure
Lagally: we also need to find a permanent time slot for arch call
… aob?
… none
previous minutes
<kaz> Nov-11
<kaz> https://
Lagally: there's a problem with the resolution link
Kaz: correct link above. The URL within the minutes has a "." at the end of the URL, so didn't work. Just fixed it.
Lagally: last time we pinpointed a conflict with the TD, I'm marking the canonicalization as a publication blocker
<benfrancis> Discovery PR https://
Lagally: we discussed also about the necessity to have a discovery section
… in the core profile
Ben: I shared the link to a PR that fix the issue
Lagally: do we have time to discuss about discovery issues?
Cristiano: I'm ok giving a shot
Lagally: there were few issues on the minutes, anything else?
Kaz: the title of Add identifier section it's ok
… we changed the topic while we were discussing about it
Ben: no we didn't actually discussed that section
Kaz: ok, I'll update the minutes
… fixing
Lagally: fixed thank you
… anything else?
… can we approved it?
Ben: discovery PR link is wrong
Kaz: it is correct
<kaz> (minutes approved)
publication blockers
<kaz> Pub blocker issues
Lagally: we have a good list let's go through them one by one
Ege: for me really all of these assertions regard the TD. What should we do? remove/re-phrase/move to TD spec ?
Ben: +1
… I prefer to move to TD spec
… too many cross-dependencies
… it is difficult to keep everything in sync
Lagally: there's the editor-call to keep consistency among different normative and non-normative documents
Sebastian: +1
… I was even surprised to see those assertions in the arch spec
… it is chance to avoid confusion
… the TD document should include all the relevant assertions/requirements
… in the TD we did the same, we remove definitions and terminology section
… I would like to have all the assertions relative to the TD in the TD document
Lagally: I agree
Cristiano: +1 also from my side :)
Lagally: ok then we just need to identify them
… ege did a first pass
Ege: for the record I only opened issue for assertions that I don't agree with but there might be others
Lagally: maybe somebody else can have another pass
… just to have another view angle
Kaz: thank you for having this discussion. be careful about the term assertion
… we should focus on normative assertions
Lagally: agree let's focus specifically on RFC 2119 assertions
Kaz: we should consider also sections not only assertions
… we should look for duplicates and remove them
Lagally: ok I would see this a second phase
Kaz: I would have started from sections but it is ok
… in the end we'll have to think about section structure
Lagally: changes in big text blocks are more difficult to discuss
Kaz: true
Ege: it was easy to review assertions
… it took me about an hour
… I agree with kaz that some sections can be just moved
… we don't really need to discuss single assertions there
… but I agree that it might take more to reach a consensus
Kaz: we might define "group issues" with links to the assertion issues
Lagally: we already have a good working plan... I'm concerned that moving section it would take longer
Kaz: I think what I've been asking you all during the Editors calls is exactly what we're discussing now. So would like to record the strategy here on the minutes as well.
<sebastian> I have to go to another meeting for 30-45min
Lagally: do we agree with the strategy?
<mlagally> Proposal: For all RFC2119 assertions that were identified contentious the process describe in https://
<mlagally> Proposal: For all RFC2119 assertions that were identified contentious in the architecture specification, the process describe in https://
<mlagally> Proposal: For all RFC2119 assertions that were identified contentious in the architecture specification, the process describe in https://
Ben: the consensus it seems that all the normative assertions should be moved to TD, but the resolution only refers to Ege's assertion
Lagally: right first let's first tackle the first ones
<mlagally> Proposal: For all RFC2119 assertions that were identified contentious in the architecture specification, the process described in https://
Lagally: I'm not sure there's consensus about ALL the td assertions
RESOLUTION: For all RFC2119 assertions that were identified contentious in the architecture specification, the process described in https://
Lagally: about all the assertions we need a person to work on it
… reviewing and giving a list
Lagally: about consensus on this, yeah it is seems that we got to this point
Lagally: Owners of the issues, please take a look
Issue 642
Issue 642 - Identify normative RFC2119 assertions that affect the TD specification
Lagally: would like to assign this to Sebastian
… any volunteers for the other issues?
… to review those issues by the next call
Kaz: should we assign somebody to each issue, shouldn't we?
Lagally: For example, Toumura-san, can you take Issue 641?
tou: sure
Ben: what is expected is categorizing each issue into the three categories?
Lagally: yes
Ben: have already done some review
Kaz: could you remind us of the URL?
Ben: Issue 625
Profile
Lagally: would move forward to Profile and discuss the detail for Architecture offline
Publication blockers
Kaz: maybe we can review those issues during this call rather than assigning another reviewer, can't we?
Lagally: that's possible
Ben: and we should start with older issues to see reviews already made
Lagally: ok
… let's discuss the spec structure PRs next
Profile spec structure
PR 129 - Introduction to use cases for profiles
Ben: we discussed this PR last week
… use case description to be moved to the Use Cased document
PR 130 - Add Use cases section
(related PR above)
Ben: not really agree to the text
… maybe would be better to just add a link to the Use Cases document
Lagally: that's also fine
Ben: agree those use cases themselves are important, but no other normative WoT specs have a Use Cases section
Kaz: thought it would suffice if we put a brief description on the rationale for WoT Profile within Introduction or Why Profile section with a link to the Use Case document
https://
Kaz: the purpose of section "4. Use Cases and Requirements" is explaining the reason why we need a profile for WoT
Lagally: right
Kaz: in that case, we can move the content to "1.2 Why a Core Profile ?"
Lagally: possible
Ben: agree we move the content to section 1
Kaz: then we can move the content to section 1.2 and the text accordingly
Ben: can help
Sebastian: btw, we're concentrating on HTTP for the Core Profile, so would be misleading to say "Cross Protocol Interworking" here (currently section "4.2")
Kaz: would suggest we move the content to section 1.2 first
… and then think about that part "4.2 Cross Protocol Interworking" next week given the time for today
Ben: would agree it would be confusing to mention "Cross Protocol Interworking" here
Lagally: ok
… let's talk about that point next week
PR 125 - Remove WoT Core Data Model and update Core Profile introduction - closes #10
Ben: split my older big PR into small pieces, and this is one of them
… maybe better to talk about the other ones first
… would be better to start with the one on "common constraints"
PR 125 - initial draft of a "common constraints" section
Lagally: common constraints across protocols here
Lagally's comment including several examples of common constraints
Ben: responded to that point
… the core profile is the only one we're defining
… so we're not sure about the other possible profiles
Lagally: understood
Ben: using consistent format is important
Lagally: so should make it generic
Sebastian: for example, time format should be human readable
Ben: but human readability is not requirement for the spec
… anyway, it's too early for us to define "Common Constraints" given we only have one profile
… the reference is also a bit problematic
Lagally: would like to review your recent comments again
Kaz: tend to agree with Ben about saying "Common Constraints" right before the definition of "WoT Core Profile" would be confusing
… maybe we could explain the constraints within the "WoT Core Profile" section instead?
Lagally: the intention of "Common Constraints" is possible common constraints among possible profiles
Kaz: in that case, maybe we could call it "Basic Constraints" or something, given we only have the Core Profile at the moment
Lagally: can live with that
… can add some clarification as well
<benfrancis> Proposed way forward for data model https://
Ben: would move forward for the data model
… please see the comment above
… think it would prevent us from working on multiple profiles
Sebastian: what about IPv4 vs IPv6?
Lagally: define a set of rules on how multiple forms are to be handled by the Consumers?
Ben: that's about the Thing Description spec, but that that should be done during the next Charter period
Lagally: let me review your comments on PR 125
Next call
Kaz: when to have the next call?
Lagally: need to have another doodle poll to find a slot
… basically, this slot or not
[adjourned]