[Uri-review] Proposal for a 'fallback' URI scheme

[Giuseppe Bilotta <giuseppe.bilotta at gmail.com>]

Hello all,

recently, I've found myself thinking about the necessity to introduce
a uniform, standard way to provide a fallback mechanism to access
alternative sources of data. I'm a total newbie when it comes to this
kind of things, but I've read as much as I could about the scheme
proposal and I'm compiling the first draft for submission (by the way,
the page http://www.ietf.org/ietf-ftp/1id-abstracts.txt linked to by
https://datatracker.ietf.org/idst/upload.cgi returns a 404).

There are still a couple of points that I would like to clarify about
the proposal, so I thought that I would ask here before submitting the
first draft. If it's more appropriate to conduct all discussions after
the draft is submitted instead, please tell me so and I'll submit the
draft with clear indications of the points that I know already for
sure need to be discussed.

The general idea is to have an URI scheme like the following:

fallback:<sep><url>[<sep><url>]...

i.e. the literal string "fallback" naming the scheme, followed by the
literal string ":", followed by a number of URLs separated by a given
separator. The first character is a separator itself to allow any
given character (that does not appear in any of the URLs) to be used
as separator.

A typical example would be something like:

fallback:|somefile.svg|somefile.mng|somefile.png

A supporting agent would then load the SVG file, or fall back to MNG
if SVG is not supported, and finally to PNG if neither of the previous
is supported.

The general idea is that by allowing this mechanism it is possible to
"future-proof" agents: for example, if the most widely deployed
browsers support fallback:, and a new image format is introduced in
the future, the fallback: mechanism can be used in the transition
period where only a minority of browsers support the given format
(sparing us something like the PNG vs GIF transition period; or think
of the present MNG vs APNG situation).

The mechanism can also be used to provide the same resource from
different hosts. And finally, it could also be used to provide the
same resource with different protocols (for exampe, if a future
'browser-to-browser' protocol is developed, supporting browsers can
offload the requests to the server by relying on other clients that
already have the resource, while non-supporting browsers would still
rely on more traditional protocols such as HTTP).

The need for such a fallback mechanism is also shown for example by
the introduction in CSS3 content module draft of the syntax "content:
url(someurl), url(someotherurl)" which is however CSS3-specific.
Having something similar at a more generic level would allow the
fallback mechanism to be used e.g. in HTML 'img' tags (or in the
'video' and 'audio' tag of the upcoming HTML5 specification).

I hope this is enough to justify why such a scheme would be useful.
Regarding the scheme itself, there are three points on which I would
like to have a clearer idea before submitting the draft, and for which
I would like the opinion of experts:

1. probably the most important: since fallback URIs act as a container
to multiple URLs, it is possible that such URLs contain special
character such as slashes, colons, question marks and number signs
(/:?#). My initial idea was to keep the embedded URLs verbatim, but
more recently I've been thinking that it might be more appropriate to
escape them. What would be the better approach?

2. since one of the inteded use of the fallback URI scheme is to
provide URLs to alternative formats, some way to specify the mime type
of the target content for each embedded URL would give agents the
option to only access the first supported URL, rather than trying them
all in sequence. A syntax that allowed an optional mime type to be
specified for each URL would thus be better. However, this is only
easily feasible if the URLs are encoded. Suggestions?

3. Should any URI be allowed inside a fallback URI, or only URLs?

I welcome any comment, critique and suggestions.

Best regards all,

-- 
Giuseppe "Oblomov" Bilotta