Meeting minutes
Agenda
Kaz/ML: Agenda bashing
Kaz: would suggest we check the WG Charter extension plan right after the minutes review
<kaz> https://
Minutes review
Lagally: Any objections?
-> no objections -> minutes approved
WG Charter extension
<kaz> Extension plan
Lagally: 10 steps
… 0. Clarify normative sections
… 1. roll back
… 2. normative feature freeze for TD & arch
… 3. start to get wide review
<kaz> 0. Clarify which normative sections should be included or should be improved in TD 1.1, Profile, Arch 1.1, and Discovery by end-Nov
<kaz> 1. Roll back TD spec to 1.1 (1.0 compatible) features by Nov 30
<kaz> 2. Normative features freeze TD 1.1 & Architecture spec by Dec 15
<kaz> 3. Start to get wide review including TAG, Accessibilty, Privacy, Security, and Internationalization to review TD 1.1 draft (note: might take 6 month)
<kaz> 4. Normative features freeze Discovery spec by Dec 15
<kaz> 5. Feature freeze Profile spec by Jan 31
<kaz> 6. Testfest in mid-Feb
<kaz> 7. CR transition in mid-March
<kaz> 8. PR transition in mid-April
<kaz> 9. REC transition before end of extended charter end of July
Lagally: idea was to have 12 mo extension
Lagally: instead of 6 mo
Daniel: quick comment
… preliminary decision for 12mo
… but this plan still says 6mo
Lagally: right
Lagally: made preliminary decision yesterday. Should decide today
Ben: 6 month time line
… does it affect the timeline if we go with 12 mo
… v2.0 delayed
… can we recharter if we finish early
<kaz> discussion on WG Charter extension during the WoT main call on Nov-10
<kaz> [[<sebastian> preliminary resolution: the group decide to extend the current WG charter for 12month. A final decision will be made in tomorrow's Architecture call. An email will be sent to the WG group as reminder.]]
Kaz: We will ask for 12 mo extension
… but we would like to keep 6 mo schedule
… just for potential delay
… PLH agreed with new plan
… we can renew charter for 2.0 in parallel
Ben: Sounds good
… can we have a new charter earlier
Kaz: Yes
Lagally: final resolution should make clear that we stick to freeze dates
Sebastian: would like to mention that my goal is to release v1.1 as soon as possible
… can start work for 2.0 earlier
Lagally: TD finalized within 12 months ?
Sebastian: That's the plan
… we started already to work on 2.0
Lagally: 2.0 may have impact on other documents
Kaz: we concentrate on 1.1 in this charter period
… should check deadlines periodically
Lagally: Why don't we make a clear decision that 2.0 does not go into this charter
… put 2.0 in new charter
Kaz: we've been talking about potential features for TD 2.0 but we've been deferring those features to the next Charter period by adding the "2.0" label.
Sebastian: backwards compatibility issues with 2.0
Ben: 2 separate documents in current charter, TD update and TD next
Sebastian: Correct. Other documents currently should rely on 1.1 for now
Lagally: Suggest to identify use-cases for new features
Lagally: does anyone have concern with 12 mo extension?
Lagally: <adds note about keeping 6 mo schedule>
<mlagally> proposal: call participants agree to the 12 months WG2021 Extension Plan as described in https://
<mlagally> proposal: call participants agree to the 12 months WG2021 Extension Plan as described in https://
RESOLUTION: call participants agreed to the 12 months WG2021 Extension Plan as described in https://
Clarify specification structure
Remove External TD representations section
https://
Lagally: Canonical TD removed from TD and from profile?
… not sure if we should do that
Ben: repeating information from TD spec
… canonical no longer used in profile
Sebastian: if Canonical text is in TD we should remove it from profile
Lagally: Does it explain all aspects like pure JSON parser is sufficient ?
Sebastian: Yes, basic setup of TD
Lagally: What is default encoding format for TD?
Sebastian: JSON-based serialization
<kaz> diff version - 5.2.4 Error Responses
Ben: default is JSON, but it can be JSON-LD annotated
Lagally: On canonical TD mentioning. I think having it in profile makes sense.
… heard concerns about implementing canonical TD
… was confusing to me
Ben: no mentioning of canonical TD any longer, therefore I removed it
Lagally: The content is not complete yet. we need to keep that in mind
Sebastian: at the moment canonical TD is covered by the TD spec
… no need to repeat in profile
Lagally: Feature is at risk, right?
Sebastian: yes, depends on available implementations
Lagally: The text in profile is not normative
Ben: Yes, but it is in conflict with the TD text
<sebastia_> https://
Lagally: Suggest to wait till TD includes the feature (or not)
Ben: Unfortunately it is a different specification
Lagally: To make progress. Let's wait until we know how canonical TD moves on in the TD spec
Ben: it is not used in the profile as of now
Lagally: Plan was to have a signing TD section
Ben: I don't think that belongs to profile
Sebastian: McCool is working on signing document
… it turns out it is not ready
… we should not refer to
… standardized solution by W3C is going to come
… I agree with Ben, signing should not go into profile
Sebastian: The canonical TD section will be kept until we start PR transition
… mid april
… after that we will be removing it (IF we don't have enough implementations)
Lagally: its unfortunate to have forward references to documents that are to be written in the future
<benfrancis> https://
Sebastian: We should just be sure that text is compliant
… should also avoid redundancy
Lagally: Yes, and misalignments
Lagally: Okay, let's approve PR#123
Kaz: Do we want to have this feature normatively
… we should decide that first
Lagally: Normative canonical TD format does make sense
Kaz: I see, since we cannot deal with it now we should move it to open issues
Daniel: Canonical TD feature is needed, but for the TD in general, not for the profile only
Kaz: right. the purpose of WoT Profile is a collection of subsets of features from the WoT specs, so we don't need to redefine any features within the WoT Profile itself.
<mlagally> https://
Lagally: let's create an issue (see above)
Add Discovery section
https://
Ben: Goal of profile spec is adhoc interop
… currently there is no text in profile how to find/retrieve TD
… simplest mechanism is "direct" discovery
… that's all what the addition says, URL retrievable
Sebastian: I miss a convention how the URL looks like
… like well-known pattern known from CoAP
… a pre-defined URL would be good
… or root address
Ben: discovery spec does propose well-known pattern
<kaz> diff version - 5.3 Discovery
Daniel: well-known is based on host level
… does not work for multiple things
Ben: in discovery spec are 2 stages
… well-known in introduction mechanism
… thing or directory
… in case of multiple things you need to have a directory
… hence it is not a good fit here
Lagally: requirement of thing or TD
Ben: Does not matter, can be hosted by the thing itself or by a cloud service
Lagally: Why do we require HTTP url
… could be a file ?
Ben: I argue that if TD cannot be retrieved via HTTP it is not a WebThing, rather a thing
Lagally: I can see many use-cases
… we put constraints and forbid other scenarios
… out-of-band is fine for me
Ben: I take the point
… long-lasting issue to have a discovery section in profile
… this is the simplest mechanism
… if we think this is too much, I can live without
Sebastian: out-of-the box interop raises the question where to get the TD
… without such a requirement we miss that capability
Ben: This discovery mechanism is basic
… DNS would be too much of a requirement
Lagally: I suggest we make things self-descriptive
… knowing URL of thing should be sufficient
BF/SK: Not sure what is needed
Lagally: Simple, define fixed string property "td" that always reports TD
Sebastian: Agree, but we do not need to define property
Ben: IP address /domain still needs to be known
Lagally: Mandatory endpoint
Ben: What about multiple things on gateway (same hostname)
<kaz> WoT Discovery - 5. Introduction Mechanisms
Sebastian: Master array
Ben: Is a directory, right?
Sebastian: Yes
Kaz: details of discovery should be described by the WoT Discovery document .. not here
Lagally: What is missing?
Ben: Link, currently we reference direct
<benfrancis> https://
Ben: I am hearing we should reference well-known also
Kaz: direct + well-known for the Core Profile within the WoT Profile document.
Lagally: Question, do we enforce well-known scheme in profile
Ben: I am OK with that
… tricky if gateway host multiple things
… maybe having direct mandatory, well-known optional
Sebastian: I don't think it helps, might miss IP
Ben: I am fine with making both mechanism mandatory
… I just want to make clear that requires directory service
Ege: https://
… points to TDs
Ben: Does not work with well-known
… for multiple things
Sebastian: topic should be covered by discovery spec
Ege: well-known works well in local network
Sebastian: Just a list of links
… should have links container
similar to http://
Lagally: Couple of options
… we don't consider aggregates things
… container aggregation with links container
… not sure about complexity
Lagally: Suggest to have self-description
Ben: I think you mean well-known uri ?
Lagally: Yes
Ben: Okay, can work on that
… still see issues with hosting multiple things
Kaz: profile can have both, direct and well-known?
… the problem here is rather that the WoT Discovery spec still needs updates
Lagally: I think the direction is clear. We want a link to get a TD without significant overhead
Ben: I can work on the topic
Add use cases for profiles section
https://
Lagally: I have to PRs on use-cases
… motivate
Lagally: other PR is https://
<mlagally> https://
Lagally: please provide feedback
<mlagally> Please review until next week.
Ben: I looked at the PR
… initial feedback seems to be a duplication of text
… other specs don't have use-cases section
… not sure if we need to have it in profile
Lagally: Text comes from use-case document
… help to understand scope and context
Sebastian: Similar comment. I think we have use-case document
… maybe we can reference use-case sections
… I would like to see "who benefits from the profile"
… motivation is somewhat missing
<kaz> diff - 4. Use Cases and Requirements
Lagally: It is a summary from use-case document
… just pointing to use case document is not enough
Kaz: Summary text can be included but maybe in introduction section
Sebastian: I am concerned about amount of topics
… I think we should concentrate on technical decisions
Lagally: No new details, helps the reader
Sebastian: Anyhow, should put our focus on technical discussions
<kaz> https://
Kaz: anyway, this is rather additional rationale description for WoT Profile in general
… so should be included in the Introduction section after shrinking the text a bit
Lagally: please look at the text also
Next call
Lagally: we've done PR 123, 117, 121, 131 and 129
… would continue the discussion during the next call
Ben: would like to think about the decision making policy again
… currently we make decisions during the weekly calls
Lagally: from my viewpoint, the mechanism works good so far
… would like to hear from everybody for opinions, though
Kaz: we need to identify which Issues/PRs need what level of discussion
Ben: note that I've split my big PR into several smaller PRs for easier review
Lagally: let's discuss the potential new procedure for making decision during the main call
Ben: ok
[adjourned]