[AppStream] Allowed chars in the AppStream ID

[Simon McVittie]

On Mon, 2016-10-10 at 20:47 +0100, Richard Hughes wrote:
> If we're supporting the appstream:// url
> prefix

The // in URIs has a specific meaning: it declares that the next thing
in the URI is an *authority* in the form [userinfo@]host[:port].
AppStream IDs aren't that (they are syntactically close to being a host
written backwards, although with somewhat different semantics).

https://tools.ietf.org/html/rfc3986#section-3.2

Meanwhile, the presence or absence of "/" indicates whether there is a
hierarchical path, which I'm fairly sure AppStream isn't intentionally
using either:

https://tools.ietf.org/html/rfc3986#section-1.2.3

If an appstream: URI is meant to refer to the resource "the AppStream
component named com.example.FooApp", shouldn't it be
appstream:com.example.FooApp, without the // part that denotes an
authority? (See also mailto: and news: URIs, and the non-standard apt:
URI scheme that's sometimes used in Debian/Ubuntu, all of which use
non-hierarchical paths.)

This might incidentally mean that you can dodge the userinfo@ thing and
allow more unescaped characters in the URI, in the same way that
mailto:simon.mcvittie at collabora.co.uk correctly has an unescaped "@" in
the RFC 3986 "path" component without introducing ambiguity with the
"userinfo" form.

In general it is never conceptually correct to just put a URI scheme on
something as a prefix; you have to escape the suffix appropriately for
the part of the URI it is to be used as (the same way that the Python
code `"file://" + absolute_path` is technically incorrect, because
absolute_path might contain spaces or whatever). If AppStream IDs are
sufficiently constrained, then the escaping operation might in practice
be something you can optimize out by noting that there is no allowed
character that would require escaping; but in the conceptual model it's
still there.

Regards,
    S