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

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:?

Mark.

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