W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: Larry Masinter <masinter@adobe.com>
Date: Fri, 22 May 2009 08:29:57 -0700
To: "marcosc@opera.com" <marcosc@opera.com>, public-pkg-uri-scheme <public-pkg-uri-scheme@w3.org>, public-webapps <public-webapps@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118CD8A471A@nambx04.corp.adobe.com>
I didn't think "widget" had ever gone away.

The document you pointed at says:

" This document is not a specification as of this time, though it is likely to become one once consensus has been reached on its fundamental direction. In the meantime, this document must be considered to sit outside the Widgets 1.0 family of specifications and to contain no normative content. "

I'm not sure what the "vengeance" is. It seems pretty clear that
there must be some requirement that keeps the group from being
comfortable about reusing or extending some existing URI scheme, 
such as using "thismessage" (RFC2557 defines for multipart/related
but could be reused), "file" (consider the widget as a little
mounted file system), "cid" (to pick up the UUID but add a 
path component.

The requirements for new URI schemes for permanent registration 
are given in RFC 4395, and the ones I'd be concerned about here 

* the scheme is well-defined. In particular, terms in the
definition are either part of common usage or are defined in the
document or in referenced document.

* there are requirements that require a new scheme rather
 than reusing an existing one.

* Security considerations are explicit.

If the widget: scheme is intended for inter-package references
then there are security issues with that. If not, then why the UUID?


Received on Friday, 22 May 2009 16:36:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC