Re: [PATCH 2/2] doc: Add State and Role properties to DPP API

[James Prestwood <prestwoj@gmail.com>]

Hi Jesse,

On Thu, 2022-06-23 at 12:30 -0400, Jesse Lentz wrote:
> Hi James,
> 
> Thanks for your feedback.
> 
> > > +Properties     string State [readonly, optional]
> > > +
> > > +                       Reflects the DPP state. Possible values
> > > are
> > > "presence",
> > > +                       "authenticating", and "configuring".
> > 
> > I think a "stopped" state would also be needed.
> 
> As a user of the API, I can infer that DPP is inactive if "State" is
> undefined. A non-optional State property with an explicit "inactive"
> value should provide equivalent information; would you prefer the
> latter
> approach?

Yeah, I think having an explicit value is best. I think it makes it
easier to handle for the consumer of the API.

> 
> > > +               string Role [readonly, optional]
> > > +
> > > +                       Reflects the DPP role. Possible values
> > > are
> > > "enrollee"
> > > +                       and "configurator"
> > 
> > I don't think you actually need this one. The role should be
> > implied by
> > however you started DPP:
> > 
> > StartEnrollee() -> enrollee
> > StartConfigurator() -> configurator
> > ConfigureEnrollee() -> configurator
> 
> One use case that I'm trying to address is when a user launches the
> front-end app while DPP is already active. There are two ways that I
> can
> think of to handle this:

Ah, ok this is fine then. Having the property would be the simplest way
to handle this case.

> 
> 1) The front-end stops and re-starts DPP if the user requests it.
> This
> only requires iwd to provide State, so that the front-end can see if
> a
> previous invocation must be stopped.
> 
> 2) iwd provides sufficient information via properties to restore the
> previous invocation: State, Role, and URI.
> 
> I originally had option 2 in mind, but if DPP invocations are
> intended
> to be transient, then perhaps option 1 would be more appropriate. Let
> me
> know what your thoughts are, and I'll send a revised patch.

Out of curiosity do you need these properties purely for displaying to
the user? If so I wonder if they shoud go on a new interface, e.g.
DeviceProvisioningDiagnostics.

We have a similar concept with AccessPointDiagnostics and
StationDiagnostics. These interfaces hold extra information that isn't
really needed to use IWD generally, but more debugging or displaying
information in a UI. These seem to fit more into that category than
needed for DPP in general.

> 
> Thanks.
> 
> Sincerely,
> Jesse