Skip to main content

IETF conflict review for draft-dold-payto
conflict-review-dold-payto-00

Yes


No Objection

Murray Kucherawy
Robert Wilton
Warren Kumari
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)

Note: This ballot was opened for revision 00 and is now closed.

Ballot question: "Is this the correct conflict review response?"

Erik Kline
No Objection
Comment (2020-04-23) Not sent
[ section 5 ]
* How should an application know how large an instruction field to use? What
  happens to the transaction if the instruction field would be subject to
  lossy conversion?

[ section 7.1 ]
* "the routing number and the account number": is it slightly more clear to say
  "the routing number followed by the account number"?

  Same consideration in 7.3: "BIC and IBAN" -> "BIC followed by IBAN"
Murray Kucherawy
No Objection
Robert Wilton
No Objection
Roman Danyliw
No Objection
Comment (2020-04-22) Sent
Section 8.  The text helpfully discusses how interactive applications need to handle the URL with caution.  I might have added additional text that the target application processing the URI would handle the associated authentication/authorization issues required to process the transaction.

Section 8.  With regard to authentication/authorization issues, I would wonder about the issues of non-interactive application handling

Section 8.  The text also helpfully notes that “Unless a payto URI is received over a trusted, authenticated channel, user might not be able to identify the target of a payment”.  I might also note that the transport security services used to process transaction encoded in the URI are handled by the application and out of scope.
Warren Kumari
No Objection
Éric Vyncke
No Objection
Comment (2020-04-23) Sent
I second Barry's remark about the described use of IANA registry.

-éric
Barry Leiba Former IESG member
Yes
Yes (2020-04-04) Sent
With respect to Section 10 in the document:
Neither IANA nor participants in the IETF will have any necessary expertise to evaluate registration requests in the sort of registry described, and no one will be well served by the creation of such a registry at IANA.  It would be far better to have a registration process be described in this document involving experts from the industry as reviewers and maintenance of the registrations by an industry organization, rather than by IANA.

I strongly urge the authors to set this up now and to document it in the "payto" document, rather than suggesting that IANA might be asked to create some sort of registry later.
Alissa Cooper Former IESG member
No Objection
No Objection (2020-04-23) Sent
I agree with Barry.
Alvaro Retana Former IESG member
No Objection
No Objection () Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2020-04-24) Sent for earlier
Section 2

What's the intended relationship between the "opts" and the generic URI
query component?  It feels surprising to see it written this way, as opposed
to separate ABNF for the separate components to parallel RFC 3986.

Section 3

   bank's banking application) to choose which account to pay with.  An
   application SHOULD allow dereferencing a payto URI even if the
   payment target type of that URI is not registered in the "Payment
   Target Types" sub-registry.  Details of the payment MUST be taken
   from the path and options given in the URI.  The user SHOULD be

This text could perhaps be more clear about whether dereferencing payto URIs
with payment target type unknown to the application (vs. merely
unregistered) is advisable.  Since the (e.g.) path semantics are dependent
on the payment target type, it seems pretty risky to try to dereference an
unknown type.

Section 4

     INVALID (authority missing):  payto:iban/12345

I don't see how this is "authority missing"; it fails to match earlier
because the initial prefix is not "payto://" (it has no solidus).

Section 5

In an IETF-stream document, BCP 18 would require some internationalization
story for the "message" and "instructions".  (As an ISE document, this is
not bound by the BCP, of course.)  The discussion in Section 6 would not
suffice for this purpose.

Section 11.2

https://www.npci.org.in/documents/UPILinkingSpecificationsVersion10draft.pdf
is failing to load for me.
Deborah Brungard Former IESG member
No Objection
No Objection () Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection () Not sent