Skip to main content

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

Document history

Date Rev. By Action
2020-04-27
00 Amy Vezza
The following approval message was sent
From: The IESG
To: rfc-ise@rfc-editor.org,
    Adrian Farrel ,
    draft-dold-payto@ietf.org
Cc: IETF-Announce ,
    …
The following approval message was sent
From: The IESG
To: rfc-ise@rfc-editor.org,
    Adrian Farrel ,
    draft-dold-payto@ietf.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-dold-payto-12

The IESG has completed a review of draft-dold-payto-12 consistent with
RFC5742.

The IESG has no problem with the publication of 'The 'payto' URI scheme for
payments'  as an Informational RFC.

The IESG has concluded that there is no conflict between this document and
IETF work.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-dold-payto/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-dold-payto/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary



2020-04-27
00 Amy Vezza IESG has approved the conflict review response
2020-04-27
00 Amy Vezza Closed "Approve" ballot
2020-04-27
00 Amy Vezza Conflict Review State changed to Approved No Problem - announcement sent from Approved No Problem - announcement to be sent
2020-04-24
00 Cindy Morgan Conflict Review State changed to Approved No Problem - announcement to be sent from IESG Evaluation
2020-04-24
00 Benjamin Kaduk
[Ballot comment]
Section 2

What's the intended relationship between the "opts" and the generic URI
query component?  It feels surprising to see it written this …
[Ballot comment]
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.
2020-04-24
00 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2020-04-24
00 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-04-23
00 Erik Kline
[Ballot comment]
[ section 5 ]
* How should an application know how large an instruction field to use? What
  happens to the transaction …
[Ballot comment]
[ 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"
2020-04-23
00 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-04-23
00 Benjamin Kaduk
[Ballot comment]
Section 2

What's the intended relationship between the "opts" and the generic URI
query component?  It feels surprising to see it written this …
[Ballot comment]
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 "paytoo://" (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.
2020-04-23
00 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-04-23
00 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-04-23
00 Alissa Cooper [Ballot comment]
I agree with Barry.
2020-04-23
00 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-04-23
00 Éric Vyncke [Ballot comment]
I second Barry's remark about the described use of IANA registry.

-éric
2020-04-23
00 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-04-23
00 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-04-22
00 Roman Danyliw
[Ballot comment]
Section 8.  The text helpfully discusses how interactive applications need to handle the URL with caution.  I might have added additional text that …
[Ballot comment]
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.
2020-04-22
00 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-04-22
00 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-04-22
00 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-04-21
00 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-04-06
00 Amy Vezza Placed on agenda for telechat - 2020-04-24
2020-04-04
00 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-04-04
00 Barry Leiba
[Ballot comment]
With respect to Section 10 in the document:
Neither IANA nor participants in the IETF will have any necessary expertise to evaluate registration …
[Ballot comment]
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.
2020-04-04
00 Barry Leiba Ballot comment text updated for Barry Leiba
2020-04-04
00 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-04-04
00 Barry Leiba Created "Approve" ballot
2020-04-04
00 Barry Leiba Conflict Review State changed to IESG Evaluation from AD Review
2020-04-04
00 Barry Leiba New version available: conflict-review-dold-payto-00.txt
2020-03-26
00 Alissa Cooper Conflict Review State changed to AD Review from Needs Shepherd
2020-03-26
00 Alissa Cooper Shepherding AD changed to Barry Leiba
2020-02-03
00 Alissa Cooper Removed from agenda for telechat
2020-01-27
00 Cindy Morgan Placed on agenda for telechat - 2020-02-06
2020-01-26
00 Adrian Farrel IETF conflict review requested