W3C home > Mailing lists > Public > public-payments-wg@w3.org > April 2016

Re: CfC to publish documents as FPWD of the Web Payments WG

From: Michael[tm] Smith <mike@w3.org>
Date: Wed, 13 Apr 2016 14:50:06 +0900
To: Shane McCarron <shane@spec-ops.io>, Payments WG <public-payments-wg@w3.org>
Message-ID: <20160413055006.GT30358@sideshowbarker.net>
Shane McCarron <shane@spec-ops.io>, 2016-04-12 17:59 -0500:
> Archived-At: <http://www.w3.org/mid/CAJdbnOAKvyp9Za6v1JXcv5CPqeMeM5+hqP2==tq4tKXeAb7O4w@mail.gmail>
> 
> Along these lines.... and not to bury the working group in administrativia,
> but I am super open to adopting a working model like the following:
> 
>    - Propose changes via PR
>    - Debate PRs until agreed or rejected
>    - Merge PRs that are agreed
>    - Automatically rev the WD via Echidna (W3C publication tool that just
>    works) daily if there are merges.

Yes, that is a model which is working well now for a number of other WGs.

> Again, this is just a way of doing publications post-FPWD.  A lot of W3C
> working groups use it.

Yes, and more will be moving to it soon (for example, the Web App Security WG)

> It generates a lot of "churn" when a document is in flux, but... it means
> nothing public-facing is stale.

Right. A major problem we have had for years with working drafts in the
https://www.w3.org/TR/ tree is that under the old publishing regime, those
documents become immediately obsolete the day they are published, because
in most any active WG, the editors are actively making changes to the spec
source that render the https://www.w3.org/TR/ version irrelevant.

That situation causes real problems in that there are often cases where a
naive reviewer goes in and does a detailed thorough review of a months-old
spec version in https://www.w3.org/TR/ not knowing the editors of the spec
have already made many changes to spec, some of which may have (or often
do) invalidate the review.

That situation is a serious waste of time for both the reviewer and the
working group. But that is the kind of situation we can completely avoid by
using the autopublishing system to ensure that the contents of the working
drafts available in https://www.w3.org/TR/ are always fresh and up to date
with the spec source.

  —Mike

> On Tue, Apr 12, 2016 at 5:16 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
> 
> > <wg chair>
> > Thanks Shane this helps us to get to a decision on the way forward.
> > </wg chair>
> >
> > <wg member>
> >
> > It would appear that Ripple is the only member strongly opposed to
> > publishing the Payment Method Identifiers spec at this time.
> >
> > In the interest of getting consensus and moving us forward I withdraw my
> > objection but request that the group urgently address the fact that this
> > document is:
> >
> >    1. Loaded with unanswered questions and issues
> >    2. Incomplete, as it provides very little concrete direction for the
> >    industry on how to define a new payment method and write the appropriate
> >    specifications for this.
> >    3. Ambiguous, as it proposes 3 options for achieving it's goals
> >
> > I ask that this document become a priority deliverable for the WG and that
> > changes to the editor's drafts be pushed to the the WD regularly so that
> > the current draft is not left out in public for much longer.
> >
> > </wg member>
> >
> > On 12 April 2016 at 18:08, Shane McCarron <shane@spec-ops.io> wrote:
> >
> >> Apologies - Ian mentioned that my comments may be unclear.  I am in no
> >> way saying Spec-Ops formally objects to anything.
> >>
> >> On Tue, Apr 12, 2016 at 10:22 AM, Shane McCarron <shane@spec-ops.io>
> >> wrote:
> >>
> >>> Spec-Ops has reviewed the draft specifications.  Many others have
> >>> comment on the details in earlier responses.  We in particular strongly
> >>> agree with the comments made by Adrian Hope-Bailie about the architecture
> >>> and payment method identifier documents.  Our responses to the CFC are
> >>> below:
> >>>
> >>>
> >>>>    - Proposal 1: Publish "Payment Request API" as a FPWD
> >>>>       -
> >>>>       https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/paymentrequest.html
> >>>>
> >>>>
> >>> +1 on publishing this document - while riddled with issues these should
> >>> spark broader community review and comment.
> >>>
> >>>
> >>>>
> >>>>    - Proposal 2: Publish "Payment Request API Architecture" as a FPWD
> >>>>       -
> >>>>       https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/architecture.html
> >>>>
> >>>>
> >>> -1 on publishing this document.  It is misleading in its current form
> >>> and may turn off potential adopters with its too-tight focus on browser
> >>> payment and lack of detail on the overall architecture of payments.
> >>>
> >>>
> >>>>
> >>>>    - Proposal 3: Publish "Payment Method Identifiers" as a FPWD
> >>>>       -
> >>>>       https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/method-identifiers.html
> >>>>
> >>>>
> >>> -1 on publishing this document.  It is too immature to publish at this
> >>> point.
> >>>
> >>>
> >>>>
> >>>>    - Proposal 4: Publish "Basic Card Payment" as a FPWD
> >>>>       -
> >>>>       https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/basic-card-payment.html
> >>>>
> >>>>
> >>> +1 to publish this, as without it the Payment Request API document is
> >>> contextless and would be hard for people to follow.  However, we agree with
> >>> AHB (and others) that the inclusion of WebIDL adds a level of complexity
> >>> that is unnecessary for this and future Payment notes.  The WebIDL should
> >>> be stripped out and replaced with something friendlier / easier for
> >>> non-browser manufacturers to grok.
> >>>
> >>> Spec-Ops is also fine with publishing NONE of these documents, fixing
> >>> the systemic issues with the architecture so that we have a cohesive story,
> >>> and the publishing all of the relevant documents - even if they are
> >>> issue-laden.
> >>>
> >>>
> >>> On Tue, Apr 12, 2016 at 9:15 AM, Adrian Hope-Bailie <
> >>> adrian@hopebailie.com> wrote:
> >>>
> >>>> Having re-read my email I realize my wording is more negative than
> >>>> intended.
> >>>>
> >>>> Ripple is okay with publishing the Payment Request API and Basic Card
> >>>> Payment specifications:
> >>>>
> >>>>    1. if they are both published, and;
> >>>>    2. with the understanding that there is still substantive work to
> >>>>    do on both.
> >>>>
> >>>> We do not support publishing the Payment Method Identifier and
> >>>> Architecture documents as we believe these are not yet ready.
> >>>>
> >>>> On 12 April 2016 at 09:57, Adrian Hope-Bailie <adrian@hopebailie.com>
> >>>> wrote:
> >>>>
> >>>>> After a thorough review of the proposed specifications Ripple's
> >>>>> position is as follows:
> >>>>> (These are the views of Ripple as a WG member and not my personal
> >>>>> views as the chair)
> >>>>>
> >>>>>
> >>>>> *Structure of documents*We believe that the way that the documents
> >>>>> are structured is not optimal and would propose the following new structure:
> >>>>>
> >>>>>    - A stand-alone normative specification which defines the role and
> >>>>>    conformance criteria for a *payment mediator*. The bulk of this
> >>>>>    specification would be produced from content already in the payment request
> >>>>>    API specification and payment apps proposal. This specification should
> >>>>>    define the algorithms for:
> >>>>>       - registration of a payment app
> >>>>>       - updating the stored information about a payment app
> >>>>>       - accepting and validating a payment request
> >>>>>       - calculating the list of payment apps that can process a
> >>>>>       payment based on the intersection of method identifiers in the installed
> >>>>>       payment apps and payment request
> >>>>>       - returning a payment response
> >>>>>
> >>>>>       - A stand-alone normative specification which defines the role
> >>>>>    and conformance criteria for a *payment app*. The bulk of this
> >>>>>    specification would be produced from content already in the payment apps
> >>>>>    proposal. This specification should define the algorithms for:
> >>>>>       - returning a list of supported payment methods
> >>>>>       - processing a payment request
> >>>>>       - returning a payment response
> >>>>>
> >>>>>       - A *payment methods specification* which defines payment
> >>>>>    method identifiers, a data model for payment method data, the process for
> >>>>>    new payment methods to be defined in new payment method messaging
> >>>>>    specifications and the requirements for such a specification. This would be
> >>>>>    based on the existing payment method identifiers specification but require
> >>>>>    substantive additional content.
> >>>>>
> >>>>>
> >>>>>    - A *messaging and extensibility specification* which describes
> >>>>>    how payment request, payment response (and possibly other) messages can be
> >>>>>    extended and the algorithms that should be used to convert between
> >>>>>    in-browser objects (defined in WebIDL) and JSON encoded messages.
> >>>>>
> >>>>>
> >>>>>    - A *user agent API* specification which details the conformance
> >>>>>    criteria for user agents as payment mediators in addition to any extra user
> >>>>>    agent functionality such as gathering of user data prior to payment
> >>>>>    processing. The bulk of this specification would be produced from content
> >>>>>    already in the payment request API specification. This specification will
> >>>>>    have a normative dependency on the payment mediator, messaging and
> >>>>>    extensibility and payment methods specifications and will define API
> >>>>>    endpoints for:
> >>>>>       - registration of a payment app
> >>>>>       - update of a payment app
> >>>>>       - accepting a payment request
> >>>>>       - returning a payment request (to a web based payment app)
> >>>>>       - accepting a payment response (from a web based payment app)
> >>>>>       - returning a payment response
> >>>>>
> >>>>>       - An *HTTP API* specification which details the HTTP client and
> >>>>>    server conformance criteria for HTTP clients/servers as payment apps or
> >>>>>    payment mediators. This specification will have a normative dependency on
> >>>>>    the payment mediator,  payment methods, messaging and extensibility and
> >>>>>    payment apps specifications and will define API endpoints for:
> >>>>>       - registration of a payment app
> >>>>>       - update of a payment app
> >>>>>       - accepting a payment request
> >>>>>       - getting a list of supported payment apps for a given payment
> >>>>>       request
> >>>>>       - getting a payment request
> >>>>>       - accepting a payment response
> >>>>>       - getting a payment response
> >>>>>
> >>>>>
> >>>>> In terms of the existing documents proposed for publication:
> >>>>>
> >>>>> 1. Payment Request API (-0.5)
> >>>>>
> >>>>> We do not support publishing of this specification at this time. We do
> >>>>> not have a formal objection to publishing on the understanding that the
> >>>>> document may have substantive changes before moving to candidate
> >>>>> recommendation as we believe the scope set out by this document is a good
> >>>>> reflection of the direction of the group and is therefor a fair yard stick
> >>>>> for evaluation of patent commitments.
> >>>>>
> >>>>> Our issues with this document are as follows:
> >>>>>
> >>>>>    - The current specification doesn't define clearly how the Payment
> >>>>>    Request API fits into the larger architecture. A brief architecture related
> >>>>>    paragraph that links to the architecture document would be valuable.
> >>>>>    - It is extremely challenging to understand the life-cycle of a
> >>>>>    payment request through this API with no explicit description of the
> >>>>>    processing that is required at the edges of this component. *Nowhere
> >>>>>    in the specification is it explicitly explained that a payment request is
> >>>>>    passed to a payment app for processing.*
> >>>>>    - The aspects of the payment apps specification that describe a
> >>>>>    registration API should be included in this specification.
> >>>>>    - The role of payment mediator versus the additional behavior of
> >>>>>    the user agent to facilitate checkout are intermingled and unclear.
> >>>>>
> >>>>> 2. Payment Request API Architecture (-1)
> >>>>>
> >>>>> We object to publishing this document at this time.
> >>>>>
> >>>>> Our issues with this document are as follows:
> >>>>>
> >>>>>    - The current draft of the document is incomplete and includes
> >>>>>    only the aspects of the payment request architecture that are relevant to
> >>>>>    processing a payment within a user agent. We believe this is misleading in
> >>>>>    terms of the scope of the WG's work.
> >>>>>
> >>>>>
> >>>>> 3: Payment Method Identifiers (-1)
> >>>>>
> >>>>> We object to publishing this document at this time.
> >>>>>
> >>>>> Our issues with this document are as follows:
> >>>>>
> >>>>>    - The current draft of the document provides very little
> >>>>>    substantive value as it contains three proposals that make up the bulk of
> >>>>>    the document.
> >>>>>    - There is no document that describes the role of payment method
> >>>>>    specifications (like the Basic Card Payment Specification) or how these
> >>>>>    should be structured.
> >>>>>    - There is no consensus on the appropriate way to match payment
> >>>>>    method identifiers from the payment request with those supported by a
> >>>>>    payment app.
> >>>>>
> >>>>>
> >>>>> 4. Basic Card Payment (-0.5)
> >>>>>
> >>>>> We do not support publishing of this specification at this time but
> >>>>> believe that if the Payment Request API specification is published then
> >>>>> this specification should be published too. As such we do not have a formal
> >>>>> objection to publishing on the understanding that the document may have
> >>>>> substantive changes before moving to candidate recommendation.
> >>>>>
> >>>>> Our issues with this document are as follows:
> >>>>>
> >>>>>    - The document uses WebIDL to describe extensible data that is
> >>>>>    never processed by the user agent. This gives the impression that user
> >>>>>    agents will need to explicitly support each new payment method which is
> >>>>>    absolutely incorrect.
> >>>>>    - There is no specification that the document references that
> >>>>>    defines the requirements for a payment method specification. As such it is
> >>>>>    impossible to evaluate if this document will meet the needs of payment app
> >>>>>    implementers and payment processors.
> >>>>>
> >>>>> For Ripple,
> >>>>> Adrian
> >>>>>
> >>>>> On 11 April 2016 at 20:22, Nick Shearer <nshearer@apple.com> wrote:
> >>>>>
> >>>>>> We support FPWD publication of all four proposals.
> >>>>>>
> >>>>>> Nick.
> >>>>>>
> >>>>>> On Apr 5, 2016, at 12:29 PM, Adrian Hope-Bailie <
> >>>>>> adrian@hopebailie.com> wrote:
> >>>>>>
> >>>>>> This is a Call for Consensus (CfC) to publish one or more documents
> >>>>>> as First Public Working Drafts (FPWD) of the Web Payments Working Group.
> >>>>>>
> >>>>>>    - Proposal 1: Publish "Payment Request API" as a FPWD
> >>>>>>       -
> >>>>>>       https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/paymentrequest.html
> >>>>>>    - Proposal 2: Publish "Payment Request API Architecture" as a
> >>>>>>    FPWD
> >>>>>>       -
> >>>>>>       https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/architecture.html
> >>>>>>    - Proposal 3: Publish "Payment Method Identifiers" as a FPWD
> >>>>>>       -
> >>>>>>       https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/method-identifiers.html
> >>>>>>    - Proposal 4: Publish "Basic Card Payment" as a FPWD
> >>>>>>       -
> >>>>>>       https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/basic-card-payment.html
> >>>>>>
> >>>>>> For each proposal:
> >>>>>>
> >>>>>>    - We invite responses on this thread to each of the proposals.
> >>>>>>    - Silence will be taken to mean there is no Formal Objection [1],
> >>>>>>    but positive responses are encouraged. Publication as a FPWD does NOT
> >>>>>>    indicate that a document is complete or represent Working Group consensus.
> >>>>>>    - If there are no Formal Objections by 12 April 2016 (1pm EDT),
> >>>>>>    the proposal will carry and the Chairs will request that the Director
> >>>>>>    approve publication as FPWD(s).
> >>>>>>
> >>>>>> The W3C Director takes Formal Objections seriously, and therefore
> >>>>>> they typically require significant time and effort to address. Therefore,
> >>>>>> please limit any Formal Objections to issues related to the scope of these
> >>>>>> documents rather than technical content where the Working Group has not yet
> >>>>>> made a decision. Please include substantive arguments or rationale for
> >>>>>> consideration by the Director.
> >>>>>>
> >>>>>> If there are Formal Objections, the Chairs plan to contact the
> >>>>>> individual(s) who made the Formal Objection to see whether there are
> >>>>>> changes that would address the concern and increase consensus to publish.
> >>>>>> Depending on the number and nature of the Formal Objections, the Chairs
> >>>>>> will either make a decision either to pursue FPWD and report the Formal
> >>>>>> Objections to the Director (as required by W3C Process), or to postpone
> >>>>>> publication until there is greater consensus to publish.
> >>>>>>
> >>>>>> If there is a decision not to publish a document, we will adjust our
> >>>>>> communications to let people know about the Editor's Drafts and the
> >>>>>> decision to delay their publication as FPWDs.
> >>>>>>
> >>>>>> NOTES:
> >>>>>>
> >>>>>>    - Publication of a FPWD is a signal to the broader community that
> >>>>>>    we are seeking review of the specification(s) in their early stages. To
> >>>>>>    frame that discussion, we plan to publish a blog post with the publication:
> >>>>>>       - https://www.w3.org/2016/03/15-wpwg-blog.txt
> >>>>>>    - Publication of a FPWD triggers an event under the W3C Patent
> >>>>>>    Policy.
> >>>>>>    - The Working Group discussed this Call for Consensus at its 17
> >>>>>>    March 2016 teleconference
> >>>>>>       - https://www.w3.org/2016/03/17-wpwg-minutes
> >>>>>>
> >>>>>> For the Chairs, Adrian Hope-Bailie
> >>>>>>
> >>>>>> [1] https://www.w3.org/2015/Process-20150901/#Consensus

-- 
Michael[tm] Smith https://people.w3.org/mike

Received on Wednesday, 13 April 2016 05:50:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:15 UTC