Re: [Uri-review] [uri-review] Review Request for Icon URI Scheme

["Joe Smith" <[e-mail]>]

"Pierre-Antoine LaFayette" <[e-mail]> wrote:
>
>I've put together a draft document for an icon URI scheme,
>used for displaying platform specific icons in web pages,
>that I would like to get some feedback on.

I have no particualar issue with the basic idea, but I have some conerns 
with current specification.

>An icon URI MUST resolve to an icon image resource.

Fine. If the URI resolved to something else, it would defeat the whole idea.
However, I have concerns about the phase "icon image resource".  What is an 
icon image resource? Where is that defined? I'm not sure it is. Perhaps a 
phrasing like "image resouce representing the icon", or somthing of that 
nature would be better.

>The fextension or the mediatype sections of the URI MUST be used to
>resolve the respective platform icon for a filetype

That is poorly worded. It could be read as an implemenation may choose to 
resolve the the url to the platform icon, or to some other "icon image 
resource", but that if it chooses to resolve to the platform icon, it must 
utilize the fextention or mediatype to resolve it (as opposed to telepathy, 
or something).

I'm pretty sure you intended something like: "the resolved icon MUST be the 
platform icon for the specified fextention or mediatype."

I'm still not comfortable with that. I feel it should be "SHOULD". There may 
be valid reasons to substitute icons other than the platform icons. For 
example, there exist browser that are design to approximate how a page would 
be seen if viewed on a mobile device[1]. In that case, the correct behavior 
would be to use icons other than those of the platform, namely the icons 
that the mobile device would use.

> If an icon is not available for the specified filetype, applications
> MUST return a default icon.

Oddly this only requires some default icon, not necessarily the platform's 
default icon. But it would be a bad idea to specify the platform's default 
icon as a MUST. If that is desired add it like "... a default icon, which 
SHOULD be the system icon for files of unknown type." This would permit 
platforms that don't support file icons to just always use some default, 
since "an icon is not available for the specified type" would always be 
true. That sounds fine.

> The icon resource's dimensions MUST match the size indicated
> in the URI or use the default size.

Given the security concerns, this is reasonable.

> Applications are REQUIRED to support icon URI resolution by
> file extension.

Fair enough, although i would qualify this with ", unless the platform does 
not support icons for file extentions." or something like that.

> The size MUST be either an integer value representing the
> size of the icon in square pixels ...

Square pixels sounds like you are talking about a unit of px^2, so 100 
square pixels is 10x10. Perhaps there is annoter clearl way to indicate that 
you mean that the pixels should be square, so the resulting icon image 
resource is square.

> In the event that the platform does not support
> one of the keyword icon sizes or a user-provided
> size, the application SHOULD scale the icon appropriately.

Out of curiosity, what other oprtion does the application have? It MUST 
return an "icon image resource" of the specified dimention. The only other 
options seem to be to add padding to a smaller icon, or use a default icon 
of the exact size.


Other notes:

The urls "icon:" and "icon:;small" are valid according to the spec, by way 
of the definition of mediatype having no requrred elements. Since such a URI 
invokes the mediatype production, section 5.2 applies, so the resulting icon 
will be the default icon. That is suitable behavior, although it was not 
clear that that was intended. If it was intended, i would suggest incluing 
them as examples so implementers don't accidentally miss that.

There is no way to request the icon representing a folder or directory, 
since they have no file extention, and no registered mime-type. 
freedesktop.org has created the unofficial mimetype 'inode/directory', but 
that has not been registered, and as far as I know neither Windows nor OS X 
utilize this type. This is a shame since directories are pretty much 
universal. other special icons may not be portably availble, but directories 
generally are.

Your format does not permit encoding of mime type parameters, depite the 
fact that those can form an integral part of the mime type, and RFC2045 
permits mimetypes with required parameters. It is possible that the icon 
could vary based on the parameter.

You specification should probably touch on supporting scalable icons, such 
as SVG (text/svg) icons. (Some platforms do support svg icons). Basically 
they must just expose it in the same way it exposes such an image from an 
img tag that has hight and width attributes set as specificed, and make sure 
there is no acess to the image content. Any later resizing og the image, 
either by the browser zoom or by manipulation of the DOM object will not 
leak any information to the webapp, so everything is fine.

In a similar fashion a browser could treat Microsft icons (ico files, 
image/vnd.microsoft.icon) in a scalable fashion. Fundementally that format 
could be thought of like a bitmap with hinting information for use use when 
downscaling the image. If the broswer supports the format like that, then it 
would always use the most apporiate version even when being dynamically 
resized, but without leaking information to a webapp.


[1] An example is the application iPhoney, except that I am not sure if the 
iPhone is even a platform with file icons. If it does have support, it is by 
nature of still having that port of OS X intact, but I don't belive any 
offical appication ever shows file icons, and I don't think the API exposes 
icons. But a similar app for to simulate a Windows Mobile browser could 
exist, and Windows Mobile does support file icons.