INTERNET-DRAFT Hadmut Danisch
Category: Experimental Feb 2004
Expires: Sep 1, 2004
Webspacelets - compact webspace units
draft-danisch-webspacelets-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This draft proposes to pack collections of static web objects
belonging together such as HTML pages, graphics etc. into single
archive files and to transport and treat them as a single compact
object.
Hadmut Danisch Experimental [Page 1]
INTERNET-DRAFT Webspacelets Feb 2004
Table of Contents
1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The descriptor . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security and Privacy . . . . . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Hadmut Danisch Experimental [Page 2]
INTERNET-DRAFT Webspacelets Feb 2004
1. General Issues
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1].
Hadmut Danisch Experimental [Page 3]
INTERNET-DRAFT Webspacelets Feb 2004
2. Overview
The web language HTML has become the universal standard for any
kind of written information. One of it's most powerful properties
are Hyperlinks, which allow to reference other objects for
immediate access, and the ability to include graphics stored as
separate data objects. Consequently, most documents written in HTML
do consist of much more than just a single HTML text. They usually
consist of a collection of related HTML pages and other objects
such as graphical elements.
Access to those documents usually causes separate access to every
single one of these objects. Transferring them e.g. as an e-mail
usually require to manually pack and archive them, and to unpack
them before reading.
This draft proposes to pack such a portion of webspace consisting
of tightly related web objects into a single compressed archive
file (like a zip archive), and to extend Web Browsers to treat
these objects as a single file, e.g. when downloading or as
attachments to e-mail.
Such an archive file is called "spacelet".
When displaying the contents of such a spacelet, the browser could
treat it very much as if it were a web server or a directory tree
on its own. URIs with the documents should be relative or relative
to the root omitting the protocol and the server part, e.g. <a
HREF="/fruits/strawberry/index.html">.
Hadmut Danisch Experimental [Page 4]
INTERNET-DRAFT Webspacelets Feb 2004
3. The descriptor
The spacelet should contain a descriptor file with informations
like
- Title/Subject
- Version and Date
- Author
- Validity and Expiry
- Languages
- Location where to look for newer versions
It is still to be defined whether this file is to be an XML file or
any other format.
Hadmut Danisch Experimental [Page 5]
INTERNET-DRAFT Webspacelets Feb 2004
4. Security and Privacy
Security mechanisms are yet to be defined in detail. However, it
is obvious that there are security requirements, most of all the
authenticity and integrity of a spacelet.
As a first approach, security should be compatible with those
mechanisms already contained in common Web Browsers.
The spacelet archive file could have a digital signature, and the
descriptor file could tell details about the signer. If the
signature is made with a secret key certified by those certificate
authorities which are already known to common web browsers
(normally used to verify HTTPS connections). Those keys might
either be new signature keys made especially for spacelet signing,
or simply the same key used for HTTPS web servers (if the
certificate allows object signing). In the latter case, the host
name of the webserver which's certificate was used it to be given
as the signer in the descriptor file.
Web browsers should treat and display spacelets with a digital
signature similar to pages from HTTPS servers (i.e. show icons for
digital signatures or ask whether to trust certificates from
unknown authorities).
Web browsers should also inform or ask the user before following a
link pointing outside the spacelet. E.g. the web pages inside a
spacelet should not be able to include graphics from outside the
spacelet without explicit confirmation of the user to avoid
compromising the user's privacy. Following Hyperlinks should not
lead the user outside the spacelet without explicit approval.
Hadmut Danisch Experimental [Page 6]
INTERNET-DRAFT Webspacelets Feb 2004
References
1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
els," RFC 2119 (March 1997).
Draft History
00 Feb 2004
Author's Address
Hadmut Danisch
Tennesseeallee 58
76149 Karlsruhe
Germany
Phone: ++49-721-843004 or ++49-351-4850477
E-Mail: rfc@danisch.de
Comments
Please send comments to rfc@danisch.de.
Expiry
This drafts expires on Sep 1, 2004.
Hadmut Danisch Experimental [Page 7]