Meeting minutes
Housekeeping
Lagally: proposed agenda, note future agendas for looking at wide review feedback
Lagally: minutes from Feb 22, 2023
<kaz> Feb-22
Lagally: any objections to approving the call notes?
… hearing none, approved
wide reviews
<kaz> wot-profile issue 358 - Wide review
Lagally: to recap, started wide review
… however, the schedule may need to be updated
McCool: note that asked for wide review to create issues in our repo
Lagally: ok, looks like they have noticed our request, let's see if there are any issues
… and also any other new issues
Lagally: seems to be no wide review issues yet
PR 330
<kaz> wot-profile PR 330 - Cloud Events Message Format
Lagally: some followup conversation on cloud message format
… regarding cloud events, I think we need to make a clear policy decision
Ege: suggest however we skip this for now since it's informative
… in particular security and async actions
Kaz: regarding PR #330, not sure we can discuss without Ben. If we need his participation for this PR, we should invite him to one of the Profile calls rather than we discuss this without him today.
Ege: regarding policy, in current spec (maybe old text), said reduce impl burden...
McCool: still, suggest we prioritize normative topics today; since security is WIP, that leaves async actions
PR 271
<mlagally_> wot-profile PR 271 - Common constraints - identifiers
Lagally: this is in the normative section, implementation of a conversation we had about identifiers
<kaz> diff - 8. Identifiers
<Ege> w3c/
McCool: issue is we can't have contradictory assertions about requiring immutable identifiers in one place and not allowing them in another
Ege: also, in some cases we are repeating assertions already in the TD spec
<kaz> Ideally, any required immutable identifiers SHOULD only be made available via affordances, such as a property, whose value can only be obtained after appropriate authentication and authorization, and managed separately from the TD identifier.
McCool: agree with ege; we can have an informative statement referencing another assertion in another spec, but repeating it should be avoided
Ege: in the end profiles define TDs which need to follow the TD spec
Lagally: still, TD may have assertions that are not applicable
… if there are anything contradictory, please point them out, we don't want that
Ege: if there are some assertions that are not applicable, if there is a subset, may need a mechanism for this
… but if it's simply that we don't use some features, don't really have to say anything
McCool: we need to be clear by what we mean by "not using a feature" - it can be not mentioning something, and there can be forbidding use of a feature
Ege: question is whether the profile doc can override an assertion in the TD spec
<kaz> related issue 349 - Are all TD 1.1 assertions valid in all profiles?
Lagally: please create a PR
McCool: subset may be confusing; meant in mathematical sense, but...
… still, suggest we look at actions
Kaz: question is which level of text should be included in profile, normative or not, etc.
… for example, some things could just be guidelines, and then reference other specs for normative content
… more important things can be normative
… still seems to be some overlap and confusion that need to decide how to resolve
… e.g. maybe some TD text should be moved to this spec
Lagally: let's look at P1 issues, esp async actions
Actions
<kaz> Priority 1 issues
Lagally: specific issues?
Ege: remember discussion, not sure there are specific issue, but problem is testing
… some discussion about removing it; how needed is it?
… also, it tends to result in large TDs or those that don't follow TD spec
Lagally: if does not follow, please create issues
Ege: some TDs submitted for testing were very large
Lagally: what is the problem with that?
Ege: feel the schema definitions are not being using in the intended way; additional responses being used to model interactions
Lagally: what is "enough" implementations?
Ege: at least one more on thing side and two more on consumer side
Lagally: want draft first, then implementations
Ege: also a question about how needed it is
… e.g. discussion of removing device flow for OAuth, that's ok
Lagally: in many use cases async actions are widely used
… if TD does not allow us to model payload formats, it becomes a problem
… seems to be overkill to go a binding template for one or two payload formats
… feel that profile is redefining a payload format and behavior
Luca: we tried to implement async actions, do think that actions in general should be treated asynchronously
… we are missing some features, for example a way to observe actions, part of the problem
… at least, when we try to implement that part, saw there was a problem
<Ege> also relevant comment about this: https://
Luca: but in general, actions *are* asynchronous, if we assume they are synchronous it leads to a lot of problems
… another issue is multiple invocations of an actions
… lots of clarification is needed, but in general I don't feel we can get away with not doing then
McCool: to clarify, you think async actions are important, and are working on an implementation?
Luca: correct, but also see some problems in the current spec, e.g. event mechanism
Lagally: let me capture the event problem in an issue...
McCool: note that queuing etc. has various issues and different behavior have different use cases
… also need to worry about arbitrary space being used for a queue
Kaz: think we need to think about where this goes... does it belong in profiles?
… can discuss it here, but may have to bring to other TFs later
Lagally: have some problems with that from timeline perspective
… at end of charter, don't see problem with specifying additional behavior since TDs does not really say anything specific here
… do feel this behavioral description is a profile topic
Kaz: if we really do want to include all this information that is not described by other specs, then spec should be called "Implementation Details" or something
Lagally: that does not really help anybody...
Lagally: Profiles is about how to use existing features in an unambiguous way, so imo this makes sense
Kaz: still, I think this discussion is broader than profiles
… think we need to think about how to describe it within which specification(s) more
Lagally: we do have a spec, an implementer has raised some issues about some loopholes
… do not want to reopen such fundamental things that have already been decided
… have a chapter which has already been reviewed, etc.
Ege: don't oppose async actions themselves, but feel TD is immature at this point, can't describe some of this
… also tried to implement queued actions, need to dig into threading, etc.
… much simpler to implement actions that overwrite another one
… since queue is more difficult for implementors, so...
Lagally: propose a consensus, that we remove queuing and use overwriting
McCool: agree, KISS principle, but maybe we want an event if an action gets overwritten/cancelled by another action posted
Luca: ok, let me look into it and see what I can do about a PR
Lagally: issue 369
<kaz> comments on Issue 369 based on the discussion today
<benfrancis> FYI The current actions protocol binding is not a queue. It doesn't say that actions can not be performed in parallel.
<kaz> [adjourned]