Re: [w3c/webpayments-method-identifiers] feat: rewrite all the things (#35)

domenic commented on this pull request.



>          </p>
+        <ol class="algorithm">
+          <li>Let <var>url</var> be the result of running the <a>URL parser</a>
+          on <var>input</var>.
+          </li>
+          <li>If failure, <a>throw</a> a <code>TypeError</code> exception.
+          </li>
+          <li>If running <a>potentially trustworthy URL</a> with <var>url</var>

Do you really want to allow about:blank, about:srcdoc, wss: URLs, file: URLs, etc.? (All are potentially trustworthy.)

Do you want to allow usernames or passwords in the URL?

What is wrong with queries?

We probably need to synchronize https://w3c.github.io/payment-method-manifest/#fetch-payment-method-manifests step 2 with this.

>          </p>
-        <ul>
-          <li>Let <em>A</em> be the first payment method identifier string and
-          let <em>B</em> be the second payment method identifier string.
+        <ol class="algorithm">
+          <li>Let <var>urlA</var> be the result of running the <a>URL
+          parser</a> on <var>inputA</var>.

Generally since you don't want to get access to the blob URL store you probably want to use the basic URL parser

>          </p>
+        <ol class="algorithm">

This algorithm would be better operating on parsed URLs, not on strings. Most places that call it seem to serialize the parsed URL before calling it, which is pretty pointless since it's just going to parse it again.

>        </h2>
       <p>
-        W3C expects to publish a small number of payment method specifications
-        that define abstractions across similar payment methods (such as credit
-        card payments, tokenized payments, or credit transfers). W3C expects
-        these payment methods will be implemented in a wide variety of third
-        party payment apps. W3C identifies these payment methods with (short)
-        strings; W3C expects to mint these strings in payment method
-        specifications published by the Web Payments Working Group.
+        The <a href="https://w3.org">W3C</a> expects to publish a small number
+        of payment method specifications that define abstractions across
+        similar payment methods (such as credit card payments, tokenized
+        payments, or credit transfers). The <a href="https://w3.org">W3C</a>

Probably only the first "W3C" should be linked

>          </h2>
         <p>
-          For W3C strings, user agents MUST use exact string matching.
+          For a<a>standardized payment method identifiers</a>, user agents MUST

missing space; mismatched pluralness

>          </h2>
         <p>
-          For W3C strings, user agents MUST use exact string matching.
+          For a<a>standardized payment method identifiers</a>, user agents MUST
+          compare strings in a <a data-cite=
+          "HTML#case-sensitive">case-sensitive</a> manner (code point for code

/cc @annevk we should probably move this to Infra (no action item for now on this document though)

>          </p>
       </section>
     </section>
     <section>
       <h2>
+        Security consideration
+      </h2>
+      <p>
+        The URLs relied upon by this specification are only expected to be used
+        by APIs, or internally by the user agent. As such, there is no
+        expectation that URLs defined in this specification would ever be
+        rendered or passed around by end-users.

I'm not sure this is quite accurate, given the existence of https://w3c.github.io/payment-method-manifest/... It's not very clear in general, and it's not clear what it has to do with security considerations.

> @@ -98,16 +81,17 @@
         Introduction
       </h2>
       <p>
-        To use Payment Request API, merchants (or their service providers) must
-        know how to handle payment method specific data for those methods they
-        claim to accept. This allows the API to abstract away the details of
-        specific payment methods and to add new ones over time without changing
-        the API specification.
+        To use the <a data-cite="payment-request">Payment Request API</a>,
+        merchants (or their service providers) need know how to handle payment
+        method specific data for those methods they claim to accept. This
+        allows the API to abstract away the details of specific payment methods
+        and to add new ones over time without changing the <abbr title=
+        "application programming interface">API</abbr>.

Probably the first use of API in the document should get this treatment, not one middle-way through the document. Although IMO it's not necessary at all.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-method-identifiers/pull/35#pullrequestreview-35210287