Re: Bikeshed: Renaming the VC HTTP API

Beside the credit Mike gets for the most creative sentence in this thread
so far, I must admit that "VC-HAPI" is easy to see, say, and spell. And
it's technically accurate to boot.

=Drummond

On Tue, Jul 20, 2021 at 3:29 PM Mike Varley <mike.varley@securekey.com>
wrote:

> Instead of HTTP, how about “Web”? VC-WAPI (vic-wapi)
>
> Or we can drop the ‘ttp’ and go for VC-HAPI – (vc-happy)
>
>
>
> This vc-wapi is interfering with my waci but not my fapi, gets along
> pretty well with chapi but now I need a gnap. Rar.
>
>
>
> MV
>
>
>
> *From: *Mahmoud Alkhraishi <mahmoud@mavennet.com>
> *Date: *Tuesday, July 20, 2021 at 10:08 AM
> *To: *Mike Prorock <mprorock@mesur.io>, Ted Thibodeau Jr <
> tthibodeau@openlinksw.com>
> *Cc: *W3C Credentials CG <public-credentials@w3.org>
> *Subject: *Re: Bikeshed: Renaming the VC HTTP API
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> I agree with Michael's point about the audience, this IMO is intended for
> a technical audience and should therefore make sense to devs.
>
>
>
> On the proposed names so far:
>
>
>
> +0.8 to VC API --> Nice and simple and wouldn't mind it.
> +0.7 to VC Storage and Transport API --> No real issues with it it just
> seems hard to say VCSTAPI doesn't roll of the tongue.
>
>
>
> + 1 to VC Exchange ( and to answer Manu's earlier question I think
> cross-trust boundary exchange would be in scope) --> I personally think
> this is by far the best name.
>
>
>
> Not at all a fan of VC Delivery or including HTTP in the name. we can
> easily place the restriction to HTTP only in the spec itself.
>
>
>
>
>
> Regards,
>
> Mahmoud Alkhraishi
>
> Lead Developer
>
> P: (647) 447-2151
>
>
>
>
>
> ------------------------------
>
> *From:* Mike Prorock <mprorock@mesur.io>
> *Sent:* Tuesday, July 20, 2021 9:56 AM
> *To:* Ted Thibodeau Jr <tthibodeau@openlinksw.com>
> *Cc:* W3C Credentials CG <public-credentials@w3.org>
> *Subject:* Re: Bikeshed: Renaming the VC HTTP API
>
>
>
> Good points by Ted.  Redundancy in naming is rather irritating.
>
>
>
> Variants of:
>
> "Verified Credentials API"
>
> or
>
> "VC Storage and Transport API"
>
> make sense to me.
>
>
>
> Non technical decision makers we typically deal with (including in
> non-tech markets such as Ag) are familiar with the term API as a way for
> programs to communicate, and if we are specifying an API I am hesitant to
> remove API from the name, unless we do something like:
>
>
>
> "Verifiable Credential Interchange" or "Verifiable Credential Exchange"
>
>
>
> which also seem sane and descriptive to me
>
>
> Mike Prorock
>
> CTO, Founder
>
> https://mesur.io/
>
>
>
>
>
>
>
> On Tue, Jul 20, 2021 at 9:49 AM Ted Thibodeau Jr <
> tthibodeau@openlinksw.com> wrote:
>
>
> On Jul 17, 2021, at 11:45 AM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
> > Not many are enthused by the name "VC HTTP API"; it doesn't exactly roll
> off of the tongue. The catch-all term is also confusing debates (again, see
> the most recent perma-thread about the VC HTTP API).
>
>
> As I suggested the other day (
> https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0111.html)
> --
>
>    VC Storage and Transfer API
>
> -- seems appropriate since folks are talking about VCs going
> into Wallets (and similar) as well as VCs being passed from
> Issuer to Holder to Holder to Verifier.
>
> For those who like shorter names, VC-STAPI (vee-see-stappy)
> doesn't seem bad.
>
>
> I also want to discourage any name that combines HTTP with
> Protocol.  It's important to remember that every acronym
> must be expanded at some point, and the "HyperText Transfer
> Protocol ... Protocol" will be sure to get a fair bit of
> notice from the Department of Redundancy Department.  :-)
>
> Be seeing you,
>
> Ted
>
>
>
>
>
> --
> A: Yes.                          http://www.idallen.com/topposting.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
>
> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
> Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
>                              //              http://twitter.com/TallTed
> OpenLink Software, Inc.      //              http://www.openlinksw.com/
>          20 Burlington Mall Road, Suite 322, Burlington MA 01803
>      Weblog    -- http://www.openlinksw.com/blogs/
>      Community -- https://community.openlinksw.com/
>      LinkedIn  -- http://www.linkedin.com/company/openlink-software/
>      Twitter   -- http://twitter.com/OpenLink
>      Facebook  -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
>
>
>
> This email and any attachments are for the sole use of the intended
> recipients and may be privileged, confidential or otherwise exempt from
> disclosure under law. Any distribution, printing or other use by anyone
> other than the intended recipient is prohibited. If you are not an intended
> recipient, please contact the sender immediately, and permanently delete
> this email and its attachments.
>