W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [Widgets] URI Scheme revisited.... again

From: Mark Baker <distobj@acm.org>
Date: Wed, 8 Oct 2008 15:05:47 -0400
Message-ID: <e9dffd640810081205u42bff798sfb7f80e135065623@mail.gmail.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: public-webapps <public-webapps@w3.org>

On Wed, Oct 8, 2008 at 12:07 PM, Marcos Caceres
<marcosscaceres@gmail.com> wrote:
> Hi Mark,
> On Wed, Oct 8, 2008 at 4:28 PM, Mark Baker <distobj@acm.org> wrote:
>> Marcos - IIRC, there was little or no support for a widget URI scheme
>> in the discussion on www-tag.  Why are you continuing to move ahead
>> with it?
> Sorry Mark, I'm afraid that your recollection on this issue is wrong.
> Firstly, I was not aware that the TAG dictated what Web Apps works on.

You misunderstand me, Marcos.  I said "the discussion on www-tag", not
"What the TAG said".  I was hoping the push back from myself, Roy
Fielding, Larry Masinter and others would have convinced you that a
new URI scheme is undesirable and unnecessary.

> Secondly, the TAG is interested in solving this problem as much as we
> are [1]. Thirdly, TAG members have requested time at TPAC to meet with
> Web Apps to allow us to move forward on this issue  (if there was
> little support, then why do they want to meet with us? [2]). Fourthly,
> we continue to push for a URI scheme because we can't resolve DOM
> nodes in widgets to nothing (and we see the use of the "file://"
> scheme as bad (and not standardized) and "http://" as too complex for
> V1). There is no way for us to ignore the URI issue, so we need help
> in resolving it. Asking us to stop working on this is not an option.
> However, if you can help us or point us in the right direction then
> please do so!

See below ...

>> Note that you'll still have to get this past IANA who maintains the
>> registry.  IANA uses a process specified in RFC 4395 which says;
>>   The use and deployment of new URI schemes in the Internet
>>   infrastructure is costly; some parts of URI processing may be
>>   scheme-dependent, and deployed software already processes URIs of
>>   well-known schemes.  Introducing a new URI scheme may require
>>   additional software, not only for client software and user agents but
>>   also in additional parts of the network infrastructure (gateways,
>>   proxies, caches) [11].  URI schemes constitute a single, global
>>   namespace; it is desirable to avoid contention over use of short,
>>   mnemonic scheme names.  For these reasons, the unbounded registration
>>   of new schemes is harmful.  New URI schemes SHOULD have clear utility
>>   to the broad Internet community, beyond that available with already
>>   registered URI schemes.
>>  -- http://tools.ietf.org/html/rfc4395#section-2.1
> We have evaluated other options and none seem suitable.

Can you point me to these evaluations?

> However, I we
> are always open to suggestions of schemes to investigate (so long as
> they are in line with our packaging requirements; hence, no MIME
> formats for version 1.0 please!).
> The requirement for the URI scheme is as follows:
> R6. Addressing Scheme
> A conforming specification MUST specify or recommend an addressing
> scheme to address the individual resources within the widget resource
> at runtime. The addressing scheme MUST be able to address individual
> widget instances, while potentially allowing widgets to address each
> other. The addressing scheme MUST NOT expose the underlying file
> system (if any) to the instantiated widget and an instantiated widget
> MUST NOT be able to address resources outside the widget resource via
> the addressing scheme. The addressing scheme SHOULD be one that web
> authors would feel comfortable using or to which they are already
> accustomed.
> Motivation:
>    Ease of use, compatibility with other standards, current
> development practice or industry best-practice, and security.
> Rationale:
>    To allow resources to be resolved and normalized within DOM
> attributes. To make it easy for authors to address and load resources
> into their instantiated widgets, either declaratively or
> programmatically. For example, addressing a resource via an IRI
> reference (e.g. <img src="images/bg.png'/> where the src attribute
> resolves to something akin to "widget://myWidget/images/bg.png"). To
> disable access that could lead to potentially unsafe manipulation by
> widget instances to the underlying file system (if any) or other
> resources which are not instances of the same widget or resources
> contained in the widget resource used to create the current set of
> widget instances.

Any hierarchical URI scheme would seem to be able to meet those
requirements.  So why not, for the sake of argument, file:?

Received on Wednesday, 8 October 2008 19:06:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC