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

Re: Payment Method Identifiers

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Thu, 5 May 2016 00:30:58 +0200
Message-ID: <CA+eFz_JEJKD-KYt3R7xjat8=EcCF1sWHuWOAO7J6DkvxuhnOxg@mail.gmail.com>
To: Ian Jacobs <ij@w3.org>
Cc: Adrian Bateman <adrianba@microsoft.com>, Zach Koch <zkoch@google.com>, Payments WG <public-payments-wg@w3.org>
> I am hearing Adrian B say “They will never see Recommendation.” Having
“not been recommended” they will not need to be deprecated.

So what is the motivation for having them at all?

On 4 May 2016 at 21:57, Ian Jacobs <ij@w3.org> wrote:

>
> > On May 4, 2016, at 2:44 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
> >
> > > ·        The short string list below effectively covers 5
> organisations. Our goal should be to drive this list to zero before
> Candidate Recommendation.
> >
> > This reinforces my belief that short-strings/aliases are adding more
> complexity than value.
> > I second Manu's caution that once we start using them they will never be
> deprecated.
> >
> > We should also consider Matt Saxon's assertion that the card payments
> method spec should not jsut be for basic card payments and should evolve to
> include new ways of passing card payment data in future (as opposed to
> having a new card payments method spec).
> >
> > i.e. Will we mark these short strings as deprecated in future versions
> of the spec or how do we realistically phase them out?
>
> I am hearing Adrian B say “They will never see Recommendation.” Having
> “not been recommended” they will not need to be deprecated.
> We will need to mark them loudly as such.
>
> Ian
>
>
> >
> > On 4 May 2016 at 19:51, Ian Jacobs <ij@w3.org> wrote:
> >
> > > On May 4, 2016, at 10:39 AM, Adrian Bateman <adrianba@microsoft.com>
> wrote:
> > >
> > > Zach and I discussed this before he sent this mail so I support the
> proposal.
> > >
> > > A couple of additional thoughts:
> > >
> > > ·        The short string list below effectively covers 5
> organisations. Our goal should be to drive this list to zero before
> Candidate Recommendation.
> > >
> >
> > Thanks, that additional bit of information helps.
> >
> > I am also ok with the proposal.
> >
> > This approach simplifies the related topics:
> >
> >  * Equivalence testing (use [1]).
> >  * Minting policy: Anybody can mint their own absolute URLs.
> >  * Identified resources: We can decide later, have flexibility, etc.
> >
> > Ian
> >
> > [1] https://www.w3.org/TR/payment-method-id/#identifier-equivalence
> >
> >
> > > ·        One of the motivations is to not get into the “short-string
> registry” business. Any time someone wants to add themselves to the list,
> they just need to mint a URL and we will use it.
> > >
> > > ·        For now, we are only discussing these strings as identifiers.
> In the future, though, we will no doubt discuss what resources the URLs
> might point to. If we use the relative URL approach that I proposed in
> Option 1a then this potentially puts a lot of network load on whoever hosts
> the base URL.
> > >
> > > This was a problem in the past when W3C hosted DTDs and XML namespace
> schema (in the past, Microsoft’s network was regularly rate limited to
> w3.org because of errant software running on machines behind our proxies
> that was frequently downloading schema definitions).
> >
> > --
> > Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
> > Tel:                       +1 718 260 9447
> >
> >
> >
> >
>
> --
> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
> Tel:                       +1 718 260 9447
>
>
>
>
Received on Wednesday, 4 May 2016 22:56:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 May 2016 22:56:44 UTC