RE: [widgets] Widgets URI scheme... it's baaaack!

> My past standardization experience is that things which "will never be 
> used by the author and will never be exchanged between two 
> implementations" should not be standardized at all. 

I believe the requirements for a URI scheme for use within
packages are similar, if not the same, as the ones that led
to the introduction of "thismessage" in MHTML RFC 2557 (1999)
as an update to RFC 2110 (1997).

http://www.rfc-editor.org/rfc/rfc2557.txt

So I think there is some experience that (at least for
rhetorical purposes) there are requirements for an
explicit URI scheme, e.g., to make the "absolute URI"
calculation explicit.

I'd suggest looking harder at "thismessage", though,
before inventing a new URI scheme for "widget",
especially since it will (should) not appear outside
of the internal operational context.

Reusing existing technology has the advantage of
learning from experience rather than repeating it.

Larry
--
http://larry.masinter.net



-----Original Message-----
From: public-pkg-uri-scheme-request@w3.org [mailto:public-pkg-uri-scheme-request@w3.org] On Behalf Of Jean-Claude Dufourd
Sent: Tuesday, May 26, 2009 8:39 AM
To: public-webapps
Cc: public-pkg-uri-scheme
Subject: Re: [widgets] Widgets URI scheme... it's baaaack!

Marcos, Mark, all,

I am picking up the discussion where Cyril left it some months ago. I 
have read this thread, the Oct 08 one, the proposed URI scheme spec, 
even skimmed through the wam minutes. I still am leaning towards Mark's 
position. It seems to me that the URI scheme is not needed, or if 
needed, the reasons have not yet been "shown".
I am trying to reformulate the situation:

0- the author needs a way to point to resources within the widget package

1- the "URI scheme will never be used by the author" (written by 
Marcos), the author will use relative URIs for resources within the widget.

2- the browser will have to resolve the relative URI to an absolute URI 
because of the DOM spec, hence a possible vulnerability by divulging 
private information (e.g. actual name of current user in file: URI 
example of Apple Dashboard widgets) to scripts running in the widget.

3- Marcos seems to be deducing from 2- that a URI scheme must be defined 
for mandatory internal use in all widget UAs to guarantee that this 
vulnerability does not exist.

3- does not follow logically from 2-.
"Mandating the implementation in the widget UA of a URI resolution that 
does not divulge private information to the widget scripts" is 
sufficient to ensure that the vulnerability mentioned in 2- does not 
happen. The proposed URI scheme could be suggested as an option, but not 
more.

My understanding is that 3- mandates a particular URI scheme which will 
never be used by the author and will never be exchanged between two 
implementations.
My past standardization experience is that things which "will never be 
used by the author and will never be exchanged between two 
implementations" should not be standardized at all. Are there other 
predicates for the need for standardisation ?

Marcos mentions the widget V2 spec and extensibility as one reason for 
adopting the proposed URI scheme. I would like to understand how V2 and 
extensibility could make the URI scheme either seen by the author or 
exchanged between implementations, or make its absence otherwise imperil 
implementations.
Thanks.

Best regards
JC

-- 
JC Dufourd
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France

Received on Friday, 29 May 2009 00:52:16 UTC