Re: Comments on HTTP API before publishing FPWD

On 07/14/2016 11:29 AM, Adrian Hope-Bailie wrote:
> 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.

#4 is an HTTP response to #3.

#8 is an HTTP POST based on the callback URL provided during step #4.

Google Draw, file is here and you now have access (but please make a
copy to make your changes):

https://docs.google.com/drawings/d/1HTz4mkOrzLzTNKO0rgsiXE1oeJhQFQFQzg7xwNuQimE/edit

>> *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?

I'd rather make incremental progress on the glossary if possible noting
that getting glossary terms "right" is a horribly long and time
consuming process that I don't think a FPWD should be dependent on. :)

There isn't anything so terribly wrong with the terminology that we have
now that would create an issue in an FPWD.

>> *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.

Define what you mean by "push based payment" - sounds like we're
miscommunicating.

> 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).

+1, happy to make this change, I'll do this tonight.

> 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.

My understanding is that Payment Apps are still the top priority and
that will be reflected in the time allotted to the subject on the telecon.

-- 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/

Received on Thursday, 14 July 2016 18:17:58 UTC