Re: [Uri-review] Review request for payto URI scheme, draft 01

[Florian Dold <[e-mail]>]

On 4/13/2018 10:34 PM, Larry Masinter wrote:
> On // and /: 
> 
> RFC 7595 section 3.2:
> 
>    Schemes that are not intended for use with relative URIs SHOULD avoid
>    use of the forward slash "/" character in order to avoid unintended
>    processing, such as resolution of "." and ".." (dot segments).
> 
>    Schemes SHOULD avoid improper use of "//".  The use of double slashes
>    in the first part of a URI is not a stylistic indicator that what
>    follows is a URI: double slashes are intended for use ONLY when the
>    syntax of the <scheme-specific-part> contains a hierarchical
>    structure.  In URIs from such schemes, the use of double slashes
>    indicates that what follows is the top hierarchical element for a
>    naming authority (Section 3.2 of RFC 3986 has more details).  Schemes
>    that do not contain a conformant hierarchical structure in their
>    <scheme-specific-part> SHOULD NOT use double slashes following the
>    "<scheme>:" string.

I do not see any inherent conflict here, since the
<scheme-specific-part> indeed contains a hierarchy, though often of
depth exactly two.

Some (currently imaginary) payment system's account identifier could
contain, for example, country and state as part of the hierarchical
identifier:

  payto://futurebank/usa/alabama/joe-exampleguy?amount=USD:50.00

Here "futurebank" is the target account type, and
"/usa/alabama/joe-exampleguy" is the account identifier.

(and further hierarchical sub-elements could be different accounts held
by the same identity, etc.)

Maybe the spec should stress that <scheme-specific-part> indeed contains
a hierarchy, and that a verbatim "/" in the account identifier would
have to be encoded (as %2F)?

> RFC 7595 Section 3.3
> 
> 
>    While URIs might or might not be defined as locators in practice, a
>    scheme definition itself MUST be clear as to how it is expected to
>    function.  Schemes that are not intended to be used as locators
>    SHOULD describe how the resource identified can be determined or
>    accessed by software that obtains a URI of that scheme.

Yes, I agree that this should be more clearly explained in the spec.

The resource represented by a payto URI is a partially filled-out pro
forma invoice, with the (mandatory) beneficiary identified by the
authority and path and other (optional) details (such as amount, debitor
name, etc.) given in the query part.

(Of course "pro forma invoice" is a much broader concept than what payto
provides, but so far we haven't found terminology that is a better match
yet.)

And payto URIs are handled by invoking the application registered with
the target account type ("payment method" in the old terminology).
Typically this application can settle/pay an invoice to such a target
account.

(The application might be part of the browser itself, for example when
an appropriate Web Payment handler is available.)

Best,
Florian