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

annevk commented on this pull request.



>          </p>
+        <ol class="algorithm">
+          <li>Let <var>url</var> be the result of trying to <a data-lt=
+          "URL Parser">parse</a> <var>potential URL</var>.
+          </li>
+          <li>If failure, <a>throw</a> a <code>TypeError</code> exception.

"If _url_ is failure"

>          </p>
+        <ol class="algorithm">
+          <li>Let <var>url</var> be the result of trying to <a data-lt=
+          "URL Parser">parse</a> <var>potential URL</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>
+          returns <code>"Not Trustworthy"</code>, <a>throw</a> a
+          <code>SecurityError</code> exception.

Different exception really necessary? You'll have to write some tests to make sure it's thrown before a non-null query...

>            </li>
-          <li>If either <em>urlB.query</em> or <em>urlB.fragment</em> are not
-          <em>null</em> terminate the algorithm with a result of <em>no
-          match</em> and discard <em>B</em> from further matching.
+          <li>
+            <a>Serialize</a> <var>urlA</var> and <var>urlB</var> and attempt to
+            <a>validate</a> each. If either throws, return false.

I was hoping you'd abstract validate a bit somehow instead. Parse -> serialize -> parse seems really hacky.

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

identifiers*

>          </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. However, in the off-chance that
+        they are, implementers need to be aware of the <a data-cite=
+        "!URL#security-considerations">security considerations</a> from the
+        [[!URL]] specification.

Surely you should know whether they ever are? This seems a little weird.

-- 
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-35036362