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

From: Giuseppe Bilotta <[email-masked]>
Date: Sat, 15 Aug 2009 21:21:19 +0200

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

---

From: Toby A Inkster <[email-masked]>
Date: Sun, 16 Aug 2009 15:04:04 +0100

> if SVG is not supported, and finally to PNG if neither of the previous

This seems fairly unnecessary to me.

Firstly, (X)HTML already provides fallbacks for the OBJECT element.  
The fallbacks in your example could be written as:

	<object data="somefile.svg">
	  <object data="somefile.mng">
	    <img src="somefile.png" alt="some sensible text" />
	  </object>
	</object>

Secondly, HTTP connection negotiation already allows browsers to tell  
servers a specific list of content types they accept, and servers to  
deliver a file based on that information.

Thirdly, both the above techniques are already supported in existing,  
real-life browsers. A hypothetical "fallback:" URL scheme would not  
work in existing browsers, only being supported by shiny new browsers  
that were released after the fallback scheme was standardised. Thus  
anyone caring about backwards compatibility with older browsers (and  
surely backwards compatibility with older user agents is the entire  
point of providing fallbacks) would not use the scheme.

-- 
Toby A Inkster
<mailto:[email-masked]>
<http://tobyinkster.co.uk>

---

From: Giuseppe Bilotta <[email-masked]>
Date: Sun, 16 Aug 2009 17:45:28 +0200

On Sun, Aug 16, 2009 at 4:04 PM, Toby A Inkster<[email-masked]> wrote:
> Firstly, (X)HTML already provides fallbacks for the OBJECT element. The
> fallbacks in your example could be written as:
>

Using nested objects to provide fallback for other tags (img, video,
audio, whatever might come up next) looks to me like a horrible hack.
Not only It's painfully verbose to write, needing all attributes to be
specified for nested objects, but it also breaks DOM and complicates
manipulation via JavaScript and whatnot.

> servers a specific list of content types they accept, and servers to deliver
> a file based on that information.

I would really like to know if this has ever really been used
successfully. I gave a look to the Accept: headers sent by the three
browsers on my machine, and they are as follows:

Iceweasel: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
Konqueror: "text/html, image/jpeg;q=0.9, image/png;q=0.9,
text/*;q=0.9, image/*;q=0.9, */*;q=0.8"
Opera: "text/html, application/xml;q=0.9, application/xhtml+xml,
image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1"

The Iceweasel one is essentially useless for the multimedia case.
Konqueror's is slightly less useless (and it's missing some important
formats such as SVG and MNG), and even Opera's, which is the most
detailed, fails to report support for image formats that are actually
supported. And I don't see this improving a little bit when support
for multimedia format will be taken into consideration.

And of course, this disregards the fact that not all people have
complete access to the features of the web servers that hosts them,
and may not be able to configure it to handle content negotiation
properly.

> real-life browsers. A hypothetical "fallback:" URL scheme would not work in
> existing browsers, only being supported by shiny new browsers that were
> released after the fallback scheme was standardised. Thus anyone caring
> about backwards compatibility with older browsers (and surely backwards
> compatibility with older user agents is the entire point of providing
> fallbacks) would not use the scheme.

I do realize that the fallback scheme can hardly be backported to past
versions, but the whole point of it is to future-proof the next
versions, not the older one. It's a long-term approach. In fact,
that's the reason why I'm surprised something like it has not been
proposed much earlier on in the history of the Web.

_Of course_ it won't be globally deployable until it's widely
supported, but the same can be said about any new format or technology
that comes up: PNG, the failed MNG, SVG, the audio and video tags in
HTML5, and who knows what else will come up further down the road.

The big difference being, if the fallback scheme is adopted, it will
make things much easier for future enhancements. And (provided it's
cleanly defined) it wouldn't be too hard to implement either.

---

From: Kristof Zelechovski <[email-masked]>
Date: Sun, 16 Aug 2009 19:40:57 +0200

An URI should not contain several other assorted URI.  URI are meant to be
readable, as far as it is possible.
As you have shown, it would be straightforward to use an attribute of type
URI set instead.  
I consider it a feature that markup languages are verbose.  The more concise
the language, the harder it is to achieve interop.  If you find it to be an
obstacle, you can just use a suitable code generator.
Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Giuseppe Bilotta
Sent: Saturday, August 15, 2009 9:21 PM
To: [email-masked]
Subject: [Uri-review] Proposal for a 'fallback' URI scheme

Hello all,

---

From: Giuseppe Bilotta <[email-masked]>
Date: Sun, 16 Aug 2009 20:32:02 +0200

> readable, as far as it is possible.

Collecting multiple URIs together does not necessarily make the URI
less readable. In fact, something like:

fallback:|image.png|image.gif

is way more readable than most data: URIs.

As for having a single URI act as collector for multiple URIs, I don't
really see what the big problem is. I cannot think of a better way to
provide multiple reference points in a standardized, uniform way. I'm
open to suggestions for alternatives, of course.

> As you have shown, it would be straightforward to use an attribute of type

It would be possible where, exactly? Even CSS3 itself does not offer
this possibility everywhere. For example, a place where it would be
_very_ important (the background-image property) does not allow the
specification of alternative sources, since the comma-separated list
of URIs has a different meaning in that case.

> obstacle, you can just use a suitable code generator.

I have no problems with verbosity. The problem is the lack of a
significant feature. Neither HTML nor CSS, despite their verbosity,
provide a uniform, consistent way to define fallbacks for missing or
unsupported content. CSS3 has extremely limited support for fallbacks
with the content: property, HTML allows some nested-object hacks.
Neither solution is satisfactory, the CSS3 one due to its extremely
limited scope, the HTML one because it completely breaks meaningful
document handling.

The fallback scheme would provide a uniform, consistent way to define
fallbacks for missing and/or unsupported content, a mechanism that
would work in HTML, CSS, and any other context where URIs can be
specified.

---

From: Kristof Zelechovski <[email-masked]>
Date: Sun, 16 Aug 2009 20:43:32 +0200

Certainly, the example you give
	fallback:|image.png|image.gif
is readable; however, you could very easily treat the fallback URI scheme to
create unreadable monstrosities.
I would rather have the host language mechanisms extended to allow URI sets
where appropriate.
Even if you find the HTML fallback model unmanageable, it would be a HTML
problem and I believe it could be fixed within HTML itself.
Chris

---

From: Giuseppe Bilotta <[email-masked]>
Date: Sun, 16 Aug 2009 21:44:18 +0200

> create unreadable monstrosities.

The example I give would be the most typical usage of the fallback
scheme. Even more complex things like

fallback:|sound.ogg|http://mirror.example.com/sounds/sound.ogg|sound.mp3|http://mirror.example.com/sounds/sound.mp3

would still be more readable than your typical data: uri.

And you can create unreadable monstroisities with almost any URI
scheme. The WWW is _full_ of monstrous http URLs.

> problem and I believe it could be fixed within HTML itself.

So you would rather have different, inconsistent ways to specify
fallbacks, one for each different kind of language, rather than a
single, unified, consistent way to do it?

---

From: Kristof Zelechovski <[email-masked]>
Date: Sun, 16 Aug 2009 22:44:41 +0200

Different formal languages use different constructs to get similar
semantics.  It is not inconsistent; these languages are different by
definition.  It would be inconsistent if these constructs were used in
incompatible ways, which is not what I would expect to happen.  The fallback
URI scheme would not prevent that anyway.
Chris

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Sun, 16 Aug 2009 17:28:13 -0400

> is way more readable than most data: URIs.

Except that those aren't actually URIs; where's the scheme, 
authority, and path?  At best they're relative URIs, and embedding 
relative URIs inside a purportedly absolute URI of a different scheme 
makes no sense.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: Toby A Inkster <[email-masked]>
Date: Sun, 16 Aug 2009 22:57:34 +0100

> audio, whatever might come up next) looks to me like a horrible hack.

Using nested OBJECT elements to provide fallbacks is not a "hack" -  
it's how that element was designed to be used. Take a look at this  
example from the HTML 4.01 recommendation:

http://www.w3.org/TR/html401/struct/objects.html#h-13.3.1

| <P>                 <!-- First, try the Python applet -->
| <OBJECT title="The Earth as seen from space"
|         classid="http://www.observer.mars/TheEarth.py">
|                     <!-- Else, try the MPEG video -->
|   <OBJECT data="TheEarth.mpeg" type="application/mpeg">
|                     <!-- Else, try the GIF image -->
|     <OBJECT data="TheEarth.gif" type="image/gif">
|                     <!-- Else render the text -->
|      The <STRONG>Earth</STRONG> as seen from space.
|     </OBJECT>
|   </OBJECT>
| </OBJECT>

Given that the preferred content is an applet, the first fallback is  
a video, the second fallback is an image and the last fallback is  
some HTML text, I don't see how a fallback URI scheme could even cope  
with this use case. e.g.

	<img src="fallback:TheEarth.py|TheEarth.mpeg|TheEarth.gif"
	     alt="The Earth as seen from space." />

seems inappropriate given that only one of the three files, the GIF,  
is an image.

> manipulation via JavaScript and whatnot.

The syntax isn't fantastic - a lot of HTML syntax comes from  
historical compromises. The <audio> and <video> elements in HTML5  
have slightly more elegant mechanisms for fallback content. e.g.

	<audio src="sound.mp4">
		<source src="sound.ogg" type="audio/ogg;codecs=vorbis">
		<source src="sound.mp3" type="audio/mp3">
		<p>Download <a href="sound.mp4">my sound</a>.</p>
	</audio>

> successfully.

Indeed. It's reasonably common to use Accept to decide whether to  
serve an XHTML page as application/xhtml+xml or text/html for older  
browsers that can't handle the former.

It's also common in the linked data world to use connection  
negotiation to send HTML to human visitors and RDF data to automated  
software.

My own homepage, http://tobyinkster.co.uk/ is connection negotiated  
between 9 different formats.

> I gave a look to the Accept: headers sent by the three

> The Iceweasel one is essentially useless for the multimedia case.

Firefox 3.5 (and Iceweasel is just an unbranded version of Firefox)  
actually sends context-sensitive Accept headers. If you request a web  
page, you will see the above. When Firefox downloads an image as the  
result of finding an <img> element, then it sends a different image- 
specific set of types. (For the HTML5 <video> and <audio> elements,  
it sends a less good one - this is an open bug, #489071 on Bugzilla.)

> formats such as SVG and MNG)

SVG's media type is image/svg+xml which matches the image/* wildcard.  
MNG doesn't have a registered media type, but image/x-mng and video/x- 
mng are often used; both of these are matched by Konqueror's wildcards.

> , and even Opera's, which is the most
> supported.

It is unusual that SVG is not explicitly listed while XBitmap is  
(despite being pretty rare these days). SVG can of course be served  
as application/xml though image/svg+xml is far more common. Note that  
the low-priority (q=0.1) wildcard (*/*) matches SVG, though because  
of the priority, PNG, JPEG and GIF will generally be sent in preference.

> And I don't see this improving a little bit when support

It is true that current browser Accept headers are not perfect, but  
they'd be pretty easy to fix up if a little pressure was applied to  
browser vendors.

Content negotiation is also more wide-ranging than just negotiating  
media types. It allows languages to be negotiated (e.g. a French user  
can receive the French version of a document, while a Brazilian user  
will receive a Portuguese version at the same URL) and negotiation of  
charsets too.

Content negotiation uses less bandwidth than fallbacks would. Given:

a browser which didn't support SVG or MNG files would need to  
download all three files to find the one it was capable of  
displaying. With content negotiation it would request a file called  
"somefile" with an Accept header including image/png but not image/svg 
+xml or image/x-mng, thus it would be delivered a PNG file, and not  
waste bandwidth trying to receive the other two files.

Lastly: if browser vendors haven't gotten content negotiation right  
in the ten years since the HTTP 1.1 RFC, why would the fallback  
scheme be any different?

---

From: Giuseppe Bilotta <[email-masked]>
Date: Mon, 17 Aug 2009 00:19:03 +0200

On Sun, Aug 16, 2009 at 10:44 PM, Kristof
Zelechovski<[email-masked]> wrote:
> incompatible ways, which is not what I would expect to happen.

Except that it happens (take CSS3 content vs background-image)

> The fallback

Why would it not?

---

From: Giuseppe Bilotta <[email-masked]>
Date: Mon, 17 Aug 2009 00:23:49 +0200

> relative URIs inside a purportedly absolute URI of a different scheme

The scheme is 'fallback'. As for authority and path, they are not
obligatory components of an URI. Quoting RFC 2396, section 3

3. URI Syntactic Components

   The URI syntax is dependent upon the scheme.  In general, absolute
   URI are written as follows:

      <scheme>:<scheme-specific-part>

   An absolute URI contains the name of the scheme being used (<scheme>)
   followed by a colon (":") and then a string (the <scheme-specific-
   part>) whose interpretation depends on the scheme.

For the proposed fallback scheme, the scheme-specific part is a
sequence of URIs separated by an assigned separator, where absolute
URIs are taken as-is and relative URIs are taken in the context of the
current resource. What does not make sense in this?

---

From: Křištof Želechovski <[email-masked]>
Date: Mon, 17 Aug 2009 00:28:11 +0200

Semantic problems with languages using URI should be solved within that
languages first.  CSS3 is under construction; with your participation,
chances are glitches will be fixed.
You have no say over how the host environment interprets the fallback URI;
the implementors may choose to ignore this and that in your specification
and generally make a mess out of it, documenting it as an "intentional
deviation".  This has already happened before.
Best regards,
Chris

-----Original Message-----
From: Giuseppe Bilotta [mailto:[email-masked]] 
Sent: Monday, August 17, 2009 12:19 AM
To: Kristof Zelechovski
Cc: [email-masked]
Subject: Re: [Uri-review] Proposal for a 'fallback' URI scheme

Why would it not?

---

From: Giuseppe Bilotta <[email-masked]>
Date: Mon, 17 Aug 2009 00:39:34 +0200

On Sun, Aug 16, 2009 at 11:57 PM, Toby A Inkster<[email-masked]> wrote:
> Using nested OBJECT elements to provide fallbacks is not a "hack" - it's how
> that element was designed to be used. Take a look at this example from the
> HTML 4.01 recommendation:
>
> Given that the preferred content is an applet, the first fallback is a
> video, the second fallback is an image and the last fallback is some HTML
> text, I don't see how a fallback URI scheme could even cope with this use
> case. e.g.
>
> seems inappropriate given that only one of the three files, the GIF, is an
> image.

I would say that trying to fit a python applet, an MPEG movie and a
GIF into an img tag would be an abuse of the img tag. _This_ is one
case where nested objects make sense. I didn't say that using nested
object in HTML was a hack, I said that using them to provide fallback
for a given other tag was a hack.

> The syntax isn't fantastic - a lot of HTML syntax comes from historical
> compromises. The <audio> and <video> elements in HTML5 have slightly more
> elegant mechanisms for fallback content. e.g.
>
>        <audio src="sound.mp4">

Ah, interesting, I must have missed this the last time I looked over
the HTML5 draft. I wonder if the img tag could be extended this way
too ...

[snipping various very interesting insights on content negotiation]

> When Firefox downloads an image as the result of finding an
> <img> element, then it sends a different image-specific set of types. (For
> the HTML5 <video> and <audio> elements, it sends a less good one - this is
> an open bug, #489071 on Bugzilla.)

It _did_ sound strange to me that the Accept line would be so useless ...

> SVG's media type is image/svg+xml which matches the image/* wildcard. MNG
> doesn't have a registered media type, but image/x-mng and video/x-mng are
> often used; both of these are matched by Konqueror's wildcards.

The problem with those wildcards is that they are too broad, and since
they give the same quality to all formats, it's really non-distinctive
of the actually supported formats.

> a browser which didn't support SVG or MNG files would need to download all
> three files to find the one it was capable of displaying. With content
> negotiation it would request a file called "somefile" with an Accept header
> including image/png but not image/svg+xml or image/x-mng, thus it would be
> delivered a PNG file, and not waste bandwidth trying to receive the other
> two files.

That was actually the reason for question 2. in my proposal, aiming at
something like

fallback:|image/svg+xml;somfile.svg|image/x-mng;somefile.mng|image/png;somefile.png

but then the syntax would start to get complicated).

> Lastly: if browser vendors haven't gotten content negotiation right in the
> ten years since the HTTP 1.1 RFC, why would the fallback scheme be any
> different?

That's (sadly) a good point.

---

From: Giuseppe Bilotta <[email-masked]>
Date: Mon, 17 Aug 2009 00:44:53 +0200

> chances are glitches will be fixed.

I was trying to aim at a broader, more general solution, which is why
I came here first.

> deviation".  This has already happened before.

As you mention, that has already happened before. It's something that
can happen to any specification, even to language-specific ways to
handle fallbacks, just like anything else.

Of course, just like with everything else, _de facto_ specifications
are what get to count in the real world. But that is not (nor it
should be) a reason not to try proposing ways to handle things.