Re: Comments on HTTP API before publishing FPWD

On 14 July 2016 at 16:46, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 07/14/2016 10:27 AM, Adrian Hope-Bailie wrote:
> > I have submitted a PR with some concrete changes that: - sync the
> > diagram with the accompanying text: - change the flows to be more
> > aligned with what the group has agreed upon for pull-based payment
> > methods (like basic card) - add issue markers
> >
> > https://github.com/w3c/webpayments-http-api/pull/2
> >
> > I tried to separate these into commits that could be cherry-picked
> > if necessary.
>
> +1, LGTM.
>
> > Some general comments:
> >
> > *Flow diagram* This created a lot of confusion in the f2f. - We
> > should drop the term token/tokenized. I'm not sure it adds any value
>
> I'm fine w/ dropping the tokenized language and doing basic card for now.
>
> > - Step 11 in the current flow doesn't seem feasible in a client
> > server setup. This looks like server push.
>
> Step 11 is the HTTP response from step 8, which is possible in a
> client/server setup. How could we make this more clear? Is it necessary
> to make it more clear before FPWD?
>

Right! Sorry, the confusion comes from 4 and 8 which are not an HTTP
request/response pair.
They are a payment request/response pair and the labels make that confusing.

What tool are you using for this diagram, I can have a stab at a new
version.


>
> > *Terminology* If we are going to pull the terminology in we need to
> > fix it up asap. If it's going to be used in public working drafts it
> > needs a clean up.
>
> I'm fine w/ making a pass on this, but don't think it's necessary before
> FPWD.
>

Really? I'm not crazy about that but I'd like to hear what the group thinks.

Perhaps we can use a static snapshot that we edit inline and then push back
to the shared glossary when it stabilizes?

>
> > *Push Payments* We need to demonstrate both a push and a pull based
> > payment. This is still very pull based.
>
> Agree that we should do some work in the push-based payments case, but
> seeing as how none of our other specs talk about push-based payments, I
> don't think it's necessary to get this in there (other than possibly an
> issue marker) before FPWD.
>

PaymentRequest is very agnostic in this regard.
It feels like HTTP is very pull-focused in comparison.


>
> > If there is a significant amount of work to do on this document then
> > I would not encourage us to push it to FPWD yet and to hold off until
> > the group can give it due attention.
>
> We agreed to do a CfC at the face-to-face based on an implementation,
> demonstrated interest, and desire to move this specification forward. A
> friendly reminder that FPWD does not mean everyone has to agree on the
> content. Where there is disagreement, we can put in an issue marker and
> publish.
>

I will not object to publishing if the issues in the text are also in the
issue list and any issues in the list are also in the text as markers (if
appropriate). This is roughly the same process we went through with Payment
Request and Payment Method Identifiers so I feel like we're being
consistent.

I have asked the group to submit their issues before Tuesday.

Bare in mind though that we are doing what we agreed we'd not do and that
is ask the group to dedicate time to this work ahead of the Payment Apps
work which is higher priority. I am certainly keen to move this forward but
not at the expense of work on Payment Apps.


> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Web Browser API Incubation Anti-Pattern
> http://manu.sporny.org/2016/browser-api-incubation-antipattern/
>
>