Document a timeline for the WG

[lu-zero]

Profile 1.0 Plan

• We have 49 open issues to solve
• We have 4 pending patches
• Ideally we have ~8 people involved

General Plan

• We spend the next ~6 meetings to address the issues
  • 10 issues per meeting, ~1-2 issue per person
• We complete the document for Profile 1.0
  • The basic HTTP should be complete and ready for REC
    • We have multiple implementations
    • Do we have concerns? (Daniel?)
  • SSE could be ready for REC
    • We have multiple implementations interoperating
    • Concerns on the action behavior described
  • Webhooks
    • We need to confirm we have implementations
    • Same concerns as per SSE regarding action

Outputs

• NOTE-ready document
• Set of inputs for TD 2.0
  • Observable Affordance concerns
  • Protocol overhaul
    • Connection-sharing protocols
  • Composition with bindings
    • protocol bindings
    • payload bindings

Open questions

• Once the Profile 1.0 document is ready shall we push it through the REC process?
• Shall we publish as NOTE?

[benfrancis]

General Plan

Note that it's the HTTP Basic Profile which specifies action operations, the HTTP SSE and HTTP Webhook profiles only cover subscribing to events and observing properties.

What counts as an implementation? A Producer, a Consumer or both? See also: #395.

Some of the 49 open issues are small editorial changes but some are whole new features, particularly for the Webhook profile which is missing some features which could be argued to be essential for practical implementation at scale (e.g. #378 rate limiting). It is also still missing an event payload format (#258, which for some reason is currently tagged as 1.1 but really needs defining to enable interoperability in 1.0).

Open questions

I wouldn't object to 1.0 being published as a NOTE if it lacks sufficient implementations, then just move on to 2.0. But I would prefer to see it proceed to REC if we can.

Some suggested next steps:

1. Reach a Working Group consensus on whether Profile 1.0 can be allowed to specify protocol bindings which go beyond what is currently possible to express declaratively using binding templates in Thing Description 1.1, since that is currently the only way to guarantee interoperability for some operations.
   1. If it can, then I think we have a potential path towards REC
   2. If it can't, then we could consider removing the queryaction, cancelaction and queryallactions operations from the HTTP Basic Profile protocol binding, but I would then question whether that profile has sufficient value over the defaults already defined in the Thing Description specification to be worth publishing. I would also question whether the HTTP SSE and HTTP Webhook profiles can proceed to REC, since they will both define payload binding details which can't currently be expressed with existing binding templates.
2. Fix all the editorial issues
3. Decide which features are essential for the HTTP Webhook profile to be published, specify the essential missing features, and resolve the payload format issue
4. Kick off the CR transition process and publicise a request for implementations
5. Set a deadline for gathering enough implementation experience for PR (based on what we decide counts as an implementation). Then either start the transition to PR, or make a call to publish it as a NOTE instead. (It could be that some profiles proceed to PR and others get moved to a separate NOTE.)

[mlagally]

I agree with @benfrancis.
Notes and guidelines are often overlooked and there will be a variety of diverging implementations, which misses the goal of guaranteeing ad-hoc interoperability, i.e. out of the box.

Let's tie the loose ends together and get the Profile 1.0 specification out of the door by working through the Profile-1.0 issues, finding owners for each of them and address them in due course.