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

[Pierre-Antoine LaFayette <[e-mail]>]

Thank you for providing such an in depth review of the draft. I will be
making changes to the draft to address some of the concerns you raised. Not
including a special syntax for folder icons was an oversight. The "parent"
directory icon is also one that I would like to include. I did not allow the
encoding of mime types for simplicity sake. I felt that the vast usage of
the media type would be on standard types whose icons don't vary based on
the parameter. I can't think of one that does off the top of my head. I will
look into the SVG icons; I was not aware that they were available on some
platforms. Concerning the ambiguous wording, I will do my best to update the
language used so as to make the details of the specification more clear to
implementors.

Thanks!

On 28 May 2010 12:27, Joe Smith <[e-mail]> wrote:

>
> "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.
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>



-- 
Pierre.