Re: CfC on publishing HTTP API and Core Messages - ACTION REQUIRED

Hi -

We (Google) do not have plans to implement either of the proposed
specifications, and as such, I will probably have limited time myself to
comment on and engage with them. That said, I do think the WG can work on
these specs in parallel, and as such, I have no objection to publishing
both the HTTP API and Core Messages specifications. This means I am a (1)
for both specifications.

I would support re-naming "Core Messages" to "HTTP Core Messages" in the
meantime for clarity, but this is not a blocking request.

Thanks,

Zach

On Mon, Aug 15, 2016 at 11:09 AM, Shane McCarron <shane@spec-ops.io> wrote:

> Thanks for initiating this CfC!  Spec-Ops comments are below:
>
> The HTTP API:
>
> 1.  Spec-Ops supports publishing an FPWD to raise awareness of this
> important part of our work and encourage the broader community to review
> and comment on the spec.
>
> As an aside, Spec-Ops plans to build at least two implementations of this
> spec. We feel strongly that open source implementations of this protocol
> are key building blocks to the future of commerce.
>
> Note that I am an editor on this and the Core Messages specs, so I suspect
> I am slightly biased.
>
>
> The Core Messages API:
>
> 1. Spec-Ops supports publishing an FPWD of this spec.  Having a separate
> document in which the messages are defined will help with consistency of
> approach as the ecosystem we are defining expands. Moreover, using a
> separate document to manage the definitions allows for a clean separation
> between the payload of the communications and the protocol.
>
> Spec-Ops is open to changing the name of the spec to HTTP API Core
> Messages if that would help alleviate concerns about any premature
> architectural implications.
>
> With my editor hat on, I want to stress that I expect the messages here to
> remain consistent with those in the Browser Payments API and Payment App
> specs.  The essentials of all these messages can (and must) remain
> harmonized or the burden on developers will be unreasonable going forward.
>
>
>
>
> --
> Shane McCarron
> Projects Manager, Spec-Ops
>