Meeting minutes
minutes
<kaz> July-29
review 07-29 minutes
any objections?
hearing none, minutes are approved
profile pull 96
canonical TD dependencies
… removing the dependency on canonical TDs and replace it with defaults instead
<kaz> PR 96 - Remove Canonical TD dependency from property binding
Ben: small change to avoid using ml: canonical TD, since *all* we want to do is apply defaults, not the other changes
Ben: there is some other HTML cleanup though that makes the diff bigger
Lagally: suggest we merge; any objections?
… will merge
pull 93
<kaz> PR 93 - reworking data model section
Lagally: reworking data model section
… has some detailed feedback on every section
Lagally: don't feel that interop conflicts with readability and constrained devices
Ben: conflicts between readability and constrained devices
… core profile is not specifically for constrained devices
… and http profile is not really appropriate for constrained devices
McCool: I think this should just say the goal is to "improve interoperability"
Sebastian: interop also contains readability implicitly
McCool: not necessarily, there are cases where it is in conflict
… for example, to avoid ambiguity, we might have to make the TD more verbose, which is in conflict with readability
Lagally: I think we also want so say something about simplified processing
McCool: simplified processing is a secondary goal, at best
Ben: however, this discussion comes after my PR which just removes this section
… so we should perhaps discuss whether we need this section before trying to wordsmith it
Lagally: however, I think there are several things in this section that we do need, such as length limits
… in order to align with other ecosystems that have such limits
Ben: I did a line by line explanation on why I think *each* of these is unnecessary; Ege agreed
… is there a specific point that you disagree with?
McCool: would like to see if we can resolve this; this is a set of constraints, we really should consider them individually
… then do a wrapper summary last
… conversely we can discuss offline, or on the issue
Lagally: I think we should take this offline for now, review, and revisit next week
Lagally: as an aside I want to point out that the sections align with those in the TD, which I think is a reasonable structure
pull 91 - TD examples
<kaz> PR 91 - Example TD and canonical TD for Core Profile - closes #90
Lagally: do we still want to use a canonical TD here?
Ben: the idea here is to write some examples that use each of the operations, using a common web thing
… end is a longer thing description, which I've called a "Canonical TD" (maybe wrong term), but applies all the defaults
… however, this PR is still a draft, since actions are under discussion in the TD spec, including new ops
Lagally: if I recall we decided only to provide a subset of operations
Ben: this PR is a draft, suggest skipping this one for now, coming back to it later once we have resolved other PRs
Lagally: does the second example add value?
Ben: idea is the first one is the simplified TD, the second one is how it should be interpreted (e.g. after defaults are applied)
McCool: I think the second one is useful, and could be called "Expanded form" rather than Canonical Form
Lagally: why do we need the first one there?
Ben: the idea is the first one is the simplified form
McCool: these are a pair, they only make sense together
… they are the same TD, just in different forms
Lagally: worried that there are things in the example that are not well explained in the text
McCool: perhaps can raise specific issues about things that might be in the example but are not described in normative text
Kaz: think examples are good, but perhaps can structure the sections better
Lagally: I think both belong in section 5.3
Ben: nothing in the example that are not in the text; is non-normative, which is an overview
… have no problem putting both examples in the same section
… with regards to external TD section, I'm proposing we remove that section
… and I explain my thoughts about that in the restructuring PR
… I think we should look at the protocol binding pr
pull 89 - actions
<kaz> PR 89 - Define protocol binding for actions - closes #81
Lagally: discussion of situation where cancel action takes longer than the timeout
Ben: (feedback in issue; simple for simple cases; edge cases can use a different approach, e.g. a separate cancel action)
Ben: we have an existing protocol binding for profiles
… it's also not defined if a writeproperty takes longer than the time
… what do we do then?
Lagally: an HTTP timeout error occurs
… so if that happens with a timeout, how do we see whether or not the action got cancelled?
Ben: same problem with a property; you would have to read the value
… for actions, we would have to check the status
McCool: I think that as long as we can query the status of an action, then there is an error recovery mechanism
… then can repeat the cancel
… if we EXPECT cancels to take a long time, can have a separate async action as ben sugests
Ben: we could also add a "cancel" state... but since the resource gets deleted, checking to see if the resource is gone is enough
McCool: think we should add some explanatory text for error recovery recommendations
Kaz: should define something polite for recovery as our recommendation, though doing too much would be a kind of DOS
McCool: for example, should wait a while and not send a bunch of new cancellations immediately, since if the server was slow to respond it might just be busy
… in which case sending more requests is not helpful
Ben: several places where error-recovery suggestions would be good, but let's not block the current issue
Lagally: concur
Sebastian: any updates due to the name conventions discussed in the TD call?
Ben: just headings, so I suggest we land this, then revisit one we finish discussing the naming conventions
Sebastian: happy with merging this PR, I think it is a good baseline, and good to have in the profile
Lagally: one change requested, will approve so can merge
… any final problems with merging this?
… hearing none, merging.
pull 94 - date and time formats
<kaz> PR 94 - time format - initial draft
McCool: why do we have the SHOULD for UTC? What is the purpose?
… MUST would simplify processing, but SHOULD does not help there
Lagally: after discussion... will make UTC with Z mandatory
<kaz> FYI, ISO 8601
McCool: also corner case with 24:00 and fractional seconds, see TD spec for canonical form
pull 92
<kaz> PR 92 - Define protocol binding for events - closes #42
Lagally: define protocol binding for events
Ben: reached resolution in the last call to add a local biblio entry
Lagally: which one are we using?
… the WHATWG spec
Lagally: is that subject to change?
McCool: we could always cite the spec as of a specific date
Ben: respec says should fix the ref in spec
McCool: used to be a way to send updates, but I have not been able to find it lately
… also, I think it is ok to override if necessary
Ben: I should mention these are basically identical
McCool: so referencing the W3C version accomplishes the same goal as freezing at the current WHATWG spec
Kaz: talked to PLH about this, they suggested using the WHATWG spec
Lagally: but... how do we get a URL for the spec on a current date?
McCool: is there a URL format or an archive to refer to dated versions?
… this is also needed for W3C living standards, btw
<kaz> kaz: this is a common problem, so would suggest we talk with PLH and Ralph again
McCool: suggest we merge as is (with the WHATWG ref) then create an issue to resolve this (e.g. by referring to dated WHATWG spec, updating the respec database, etc)
Lagally: ok, let's do that, and I will create an issue to update the reference
… (creates wot-profile issue to reference stable version of SSE)
McCool: never mind, I looked it up and WHATWG explicitly says snapshots are non-authoritative
… so it still looks like using the W3C version is our best approach
Ben: done; reverted
events
<kaz> PR 92 - Define protocol binding for events - closes #42
Lagally: let's look at subscribe ml: events
McCool: limit is an issue, if there is one, it should be a lower bound
Ben: minimum number comes from web browser
… this is implementation specific, however
… and implementors may not be able to honor a higher limit, it is out of their control
… and it's possible they will change over time
… so a specific limit is dangerous
McCool: better then to just deal with this as an error condition
Lagally: could add a note about limits, perhaps?
Ben: constraint is on the client side, not the server side
… all our errors are server side
McCool: and I can think of scenarios where a server might want to support 1000s of subscribers
… not clear what kind of limit makes sense in all use cases
Lagally: so what kind of error makes sense? 500?
… is 500 a last resort?
Ben: 503, service not available
McCool: should we look at all the codes and see what's appropriate?
Ben: in practice, people will use a library and the library will return its own code
Ben: in practice people use large error classes
McCool: and the scripting API does that too
<kaz> FYI, HTTP status codes
Ben: problem is if we specify a particular error code and the library does not do that, it will cause implementation pain
Ben: tried a lot of libraries, not all of them worked; spec is not difficult to implement using raw HTTP
McCool: what does the actual SSE spec say?
… it gives a set of error codes, but is there one specifically for a failed subscription?
… I think we can ignore errors on the client side...
<kaz> -> Server-Sent Events (Superseded Recommendation)
Lagally: let's look at the spec
… API and protocol need to be lumped together
… which parts do people have to implement?
Ben: we just require the protocol, not the API
… but the way the spec is written, hard to reference just the protocol
Lagally: we can add a chapter ref, e.g. to Chapter 5, when we cite the reference
Ben: no objections to clarifying which section of the spec we are referring to
… but risky to define new behavior, e.g. specified error code
McCool: we could just add a line saying the Javascript API does not need to be implemented
Ben: could do that right now
Lagally: I think we need to do a little more review first
McCool: I am ok with delegating to ml the decision to merge after ben's update
Ben: let's also file a separate issue about the error
Ben: would also like to talk more about async decisions
McCool: agree, and we were delayed by vacations in august, but we need to discuss this in a broader forum
… will try to bring this up in the main call soon
<kaz> [adjourned]