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

Larry Masinter <> Sat, 14 April 2018 05:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7D67126C0F for <>; Fri, 13 Apr 2018 22:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fh-bK9tNnR9X for <>; Fri, 13 Apr 2018 22:46:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46C6C126BF0 for <>; Fri, 13 Apr 2018 22:46:32 -0700 (PDT)
Received: by with SMTP id u86so7627550pfd.2 for <>; Fri, 13 Apr 2018 22:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=FSPoQFYVeri14wMQe3LCkE3Y0Vl7XspdMM8U6KCO3/4=; b=uyJXGq+hX4ogiLtbXgf5eaNTSYmJ1Y4WTm9Rj6cz7Xkcc+hN9SGvM3/5dtnZV2j8Ce UXC0vNbj3v+dGtrSyO8U8rY5sHUy8jUJMDJ6rd7VCtWhZCVfifUKs8eevmvZpquU3Jf6 wiI6iy5ph/3np4bTUW/3OZ51rxrtmqWdlM+YxI2NPWrbxvprX7RXrTQCByK048V4pdb+ DR5i2uHCuhInZfk/E1KI1tdPJ1hhWthY4oIR9pAL7Q+yfjFROUNVEyO6Gs8kF82JtGRj w/+CbLthDH/+4KeFfl7rH1OAkidHaBV/yi7ubhNVB1dkIERayowiMhf+QYxg6I8bpSAK 4FEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=FSPoQFYVeri14wMQe3LCkE3Y0Vl7XspdMM8U6KCO3/4=; b=Zy2vDEIRIppRdL8VQbLSTltQanW8VSQiBE8WqzIi8f0rTUiClAYICejGkF9moAms+T 80/BZSv36v2KP7I4miPSjDtxM7oDhRypkzKlquyRXlNMEHBQa/JDorcFYegc13RKpkZ5 5JlzPyZ4mDDYxxE2xWdkl9aR+BTRW6Dpwg6P1QC+gq4OTeu6yQnAFSrHt5yENk4dJRnw /IuU9mFjFA4c0Fe2K+99BHPe0e7owpJ0Kg+1mKCt4O/m/QS7rlk7uvclFcdkjcr9qI6C Z0JhnonvGQt3IkVijtbMVAPgdZZTASMdkCaIypC9BNfClvTEPNGv8buAPU1r7VHHG/Dc 67oA==
X-Gm-Message-State: ALQs6tCKq/aQhMXTfheb924EIEVmawb5sVaE3mumaed+k/Rf9weBZVVw WV1wA8YiUcu6NufmDrTRe2cbhjqi
X-Google-Smtp-Source: AIpwx4+mWoPjlWadCfEkjKD8MEeFbJrfwt+xu56ZofGXTFkzfsQ9PbO3GBBOI7SwcMZlN8Kf29ACVQ==
X-Received: by with SMTP id u8mr6476016pgv.333.1523684791500; Fri, 13 Apr 2018 22:46:31 -0700 (PDT)
Received: from TVPC ( []) by with ESMTPSA id p1sm14195153pgc.15.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 22:46:30 -0700 (PDT)
Sender: Larry Masinter <>
From: Larry Masinter <>
X-Google-Original-From: "Larry Masinter" <>
To: "'Florian Dold'" <>
Cc: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Fri, 13 Apr 2018 22:46:29 -0700
Message-ID: <001301d3d3b3$f020bb40$d06231c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Archived-At: <>
Subject: Re: [Uri-review] Review request for payto URI scheme, draft 01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Apr 2018 05:46:34 -0000

On // and /.

The definition of "payto" is a good example of WHY RFC 7595 gives the advice about avoiding them.
You say you want to use "standard libraries" without writing a  custom parser. But there is no standard library, there are lots of little URI-parsing hacks, and there are likely many heuristic libraries that do things you might not want (like case-folding or normalizing the authority name or turning // or /./ or /xx/../ into / because they worked mostly and it mostly doesn't matter. Which is OK in most cases.

Saying a data structure is "hierarchical" does not apply to one that is always a hierarchy of exactly two levels, without any applications that would use the hierarchical nature.

Your registry of payment names may need a dispute process -- what if two different payment processors both claim to "own" (and release incompatible additions to) a widely used payment type.

I think you might relook at Graham's advice to consider an application/payto+json MIME type and schema instead; you'll get parsers and validators and other goodies, easy integration and extensibility. MIME type are easy and a schema is easier. If you need to stuff it in a URI use data:.

A lot of work went into RFC 7595/BCP 35, and I wish you would take it more seriously, rather than try to lawyer through.