Re: [dispatch] draft-dold-payto-03

A couple of comments based on a quick review:

- It would be useful to know whether there are people interested in using
this specification, i.e., payers that would parse these URLs and use them
to initiate payments, and/or payees that would like to publish payment
coordinates in this way.

- What value is there in having a common "payto" URI scheme with a
payment-type switch underneath it, vs. just having independent URI schemes
for each payment system?  After all, this document just defiens a
container; it doesn't provide any functionality that works across payment
systems.

- It's unclear to me what the use case is for the query parts.  I can
understand using the authority and path to identify a payment target.  But
things like "amount" and "message" seem like things that would be added by
client software in between parsing a URL and initiating a payment.

- While it's nice that you've created a registry for different payment
types, they seem a little underspecified.  Even assuming it's clear if I
just track down all the references, it would be helpful to at least have an
example of each one.

- I don't think you actually want the whole `authority` production in the
authority portion.  If you're just going to put a payment type identifier
there, then you don't need things like a port number.

On Sat, Feb 9, 2019 at 9:14 AM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Sat, Feb 9, 2019 at 5:31 AM Christian Grothoff <christian@grothoff.org>
> wrote:
>
>> Dear all,
>>
>> Ekr suggested I should e-mail this list and ask for dispatch/processing
>> of the payto:// URI draft.
>>
>> The draft was previously reviewed on uri-review (twice) and adopted
>>
>
> Note, I believe you mean "adapted".
>
> -Ekr
>
>
> according to feedback received on uri-review as well as from an IANA
>> selected anonymous expert.
>>
>> We would like to see it advance towards RFC status. However, Ekrsaid the
>> draft was insufficiently trivial for him to accept RFC 7211 AD
>> sponsorship, and also could not identify a better WG than DISPATCH for
>> it. So here we are.
>>
>> As usual, constructive feedback is welcome and we'll also be at IETF 104
>> for hopefully conclusive discussions after 2 years in the pipeline...
>>
>> Best regards,
>>
>> Christian
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>