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

Ben Campbell <> Wed, 06 March 2019 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88A3E12D4F3; Wed, 6 Mar 2019 12:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UgGVMrh9PZ1l; Wed, 6 Mar 2019 12:15:43 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2753712D4EB; Wed, 6 Mar 2019 12:15:40 -0800 (PST)
Received: from bens-macbook.lan ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x26KFaUB086911 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 14:15:37 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1551903338; bh=RR+I1DXJWM4jPO9zA7jPFtdgiZSpbfc15GR0Xcgys98=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=F+Dg9r01eV3aRzYiPR9lFyJXQLdYEsDhiS3k/yHwko3oQbNGth/OnLor00IYiNYW8 2IPUjD3ipmEzZvf1RRwk3DChKFsBJCjMe+wFpoMLYi5zs8CylSMbLyLoslNlVAiz8W nXFmRaBu8nKtYkqae0n8QpZ6LEWnQYkyU/7MFQQM=
X-Authentication-Warning: Host [] claimed to be bens-macbook.lan
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_2824FC82-F5E6-42B4-B74D-F947E447E5BD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 6 Mar 2019 14:15:29 -0600
In-Reply-To: <>
Cc:, dispatch chairs <>, ART ADs <>
To: Florian Dold <>,
References: <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [dispatch] draft-dold-payto-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Mar 2019 20:15:45 -0000

Hi Florian,

(Apologies if I’m repeating something another AD may have already told you.)

The ART ADs have discussed this, and we wonder why this needs to be an IETF stream RFC.

The URI schemes registry is only “first come first serve” *FCFS) for provisional schemes. FCFS registration does not require an RFC.  I see that the draft requests a permanent scheme, however “permanent” status is not appropriate for a new scheme. The normal procedure is to register it as provisional, and later promote it to permanent if it sees widespread use.

Based on that, we don’t see the need to spend DISPATCH agenda time on it. Is there some reason that we are missing?



> On Mar 5, 2019, at 7:22 AM, Florian Dold <> wrote:
> Dear all,
> We've updated the payto:// URI draft, based on the previous feedback on
> this mailing list:
> After consulting with a domain expert for SEPA, we've also changed the
> "sepa" payment target type into a more general "iban" target type (as
> both SEPA and SWIFT use IBANs).  Now an IBAN  (International Bank
> Account Number) can optionally be scoped within a BIC (Bank Identifier
> Scope).
> We'd be happy to hear more feedback on this decision.
> We've tried to explain the question of "why does there need to be a
> unified payto scheme, instead of many schemes for different payment
> systems" in the introduction.  Various applications detect certain URIs
> and make them interactive (mail clients, chat applications, ...).  When
> there is one URI to address payment targets, adding a new payment system
> does not require all these applications to be updated.  For smaller or
> very regional payment systems, it might be impossible to get enough
> recognition to be detected as clickable links in common applications
> otherwise.
> Additionally the "container format" addresses common issues like the
> amount format, as well the distinction between a "message" for humans
> and a machine-readable "instruction" that can't be subject to lossy
> conversions.  Similarly, security and encoding considerations apply to
> all payment target types.
> Both authors will be present at IETF 104.  Would it be possible to
> present/discuss this draft as part of the dispatch session there?
> Best regards,
> Florian
> _______________________________________________
> dispatch mailing list