Re: [browser-payment-api] Suggest two alternative payment method identifier proposals (#34)

@adrianba,

Thanks very much for writing these up. I like option 1 and have in my head that one could usefully dereference the payment method URI to get the spec that defines the method-specific data (request and response) as well as any other information about the identifier. 

I understand there are disagreements about "why people use URIs." I disagree with this statement: "The intent of a URL is to load or locate a resource and may only be done sometimes with this proposal." I would be more comfortable with: "For many people, when they see a URL the expect to be able to dereference it, which may lead to confusion as this specification would not require that the URLs be dereferenceable."

Regarding: "Experience with XML namespaces suggests that optional downloading resources from identifiers tends to encourage user agents to hard code common identifiers for performance reasons potentially leading to a closed or unbalanced system."

I think the spec could say something like this:
 * GOOD PRACTICE: Offer human-readable payment method specifications when people dereference these URIs.
 * Conforming user agents SHOULD NOT automatically dereference these URIs because this specification suggests that the identified resources are human readable documents.

@mattsaxon, 

I would not want an equivalence test in general to require a network request. 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/34#issuecomment-195375779