[widgets] Media Type Registration for application/widget

Dear IETF,
As part of the Widgets 1.0: Packaging and Configuration Specification 
progressing to Last Call, the W3C Web Applications Working Group would 
like to begin registration procedures for the "application/widget" MIME 
type.

We have written a draft of the registration text for you to review and 
comment (full text below). The section in our specification that defines 
the registration can be found here:

http://dev.w3.org/2006/waf/widgets/#media-type-registration-for-applicationw

Our Last Call Review Period ends 19 of November, 2009.

Kind regards,
Marcos

------------

Media Type Registration for application/widget

This appendix registers a new MIME media type, "application/widget" in 
conformance with BCP 13 and W3CRegMedia.

This registration is for community review and will be submitted to the IANA.

Type name:
     application

subtype name:
     widget

Required parameters:
     None.

Optional parameters:
     None.

Encoding considerations:
     Widget packages are binary data and thus are encoded for MIME 
transmission. As a widget package is binary, it requires encoding on 
transports not capable of handling binary. The same guidelines that 
apply to application/octet-stream apply to widget packages (see [MIME]).

Security considerations:
     In addition to the security considerations specified for Zip files 
in the [Zip-MIME] registration, there are a number of security 
considerations that need to be taken into account when dealing with 
widget packages and configuration documents.

     As the configuration document format is [XML] and will commonly be 
ecoded using [Unicode], the security considerations described in 
[XML-MIME] and [UTR36] apply. In additon, implementers need to impose 
their own implementation-specific limits on the values of otherwise 
unconstrained attribute types, e.g. to prevent denial of service 
attacks, to guard against running out of memory, or to work around 
platform-specific limitations.

     The configuration document allows authors, through the feature 
element, to request permission to enable third-party runtime components 
and APIs. As these features are outside the scope of this specification, 
significant caution needs to be taken when granting a widget the 
capability to use a feature. Features themselves define their own 
security considerations.

     Widget packages will generally contain ECMAscript, HTML, CSS files, 
and other media, which are executed in a sand boxed environment. As 
such, implementers need to be aware of the security implications for the 
types they support. Specifically, implementers need to consider the 
security implications outlined in the [CSS-MIME] specification, the 
[ECMAScript-MIME] specification, and the [HTML-MIME] specification.

     As widget packages can contain content that is able to 
simultaneously interact with the local device and a remote host, 
implementers need to consider the privacy implications resulting from 
exposing private information to a remote host. Mitigation and in-depth 
defensive measures are an implementation responsibility and not 
prescribed by this specification. However, in designing these measures, 
implementors are advised to enable user awareness of information 
sharing, and to provide easy access to interfaces that enable revocation 
of permissions.

     As this specification relies on the standardized heuristics for 
determining the content type of files defined in the [SNIFF] 
specification, implementers need to consider the security considerations 
discussed in the [SNIFF] specification.

     As this specification allows for the declaration of IRIs within 
certain elements of a configuration documents, implementers need to 
consider the security considerations discussed in the [IRI] specification.
Interoperability considerations:

     Some issues can arise with regards to character encodings of file 
names, the length of zip relative paths, and the use of certain strings 
as file names.

     This specification does not put a restriction on the byte length of 
a Zip relative path, so a user agent needs to be able to deal with Zip 
relative paths that have lengths longer than 250 bytes. As some 
operating systems have restrictions on how long a path length can be, 
authors need to keep the lengths of relative paths at less than 250 
bytes. Unicode code points may require more than one byte to encode a 
character, which can result in a path whose length is less than 250 
characters but whose size is greater than 250 bytes.

     Authors need to be aware that, at the time of publication, there 
are interoperability issues with regards to using characters outside the 
safe-chars range for file or folder names in a Zip archive when using 
Zipping tools bundled with operating systems. The interoperability 
issues have arisen from non-conforming implementations of the [ZIP] 
specification across operating systems: very few, if any, correctly 
support encoding file names in Unicode.

     In the case where the Zip relative path is encoded using [UTF-8], 
the language encoding flag (EFS) needs to be set.

     If an author chooses to use the utf8-chars, they need to thoroughly 
test their widgets on various platforms prior to distribution; otherwise 
it is suggested that authors restrict file and folder names to the 
safe-chars (characters in the US-ASCII range). In addition, having 
excessively long path names (e.g. over 120 characters) can also result 
in interoperability issues on some operating systems.

     Authors need to avoid using forbidden characters when naming the 
files used by a widget. These characters are reserved to maintain 
interoperability across various file systems and with [URI]s.

     Authors need to avoid using the following words as either a folder 
or a file-name in a Zip relative path as they are reserved by some 
operating systems (case-insensitive): CON, PRN, AUX, NUL, COM1, COM2, 
COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, 
LPT6, LPT7, LPT8, LPT9, CLOCKS$. For example, the following names are 
ok: "CON-tact.txt", "printer.lpt1", "DCOM1.pdf". However, "com3.txt" 
"Lpt1", "CoM9.gif" would not be.

     In addition, authors need to avoid having a "." U+002E FULL STOP as 
the last character of a file or folder name as some operating systems 
will remove the character when the file is extracted from the Zip 
archive onto the device. Furthermore, avoid having the space character 
(SP) at the start or end of a file name; and take caution when using the 
"+" U+002B PLUS SIGN, as it might cause issues on some operating systems.


Published specification:
     http://www.w3.org/TR/widgets/

Applications that use this media type:
     User agents that claim conformance to this specification.

Magic number(s):
     50 4B 03 04

File extension(s):
     wgt

Macintosh file type code(s):
     None.

Person & email address to contact for further information:
     Steven Pemberton, member-webapps@w3.org

Intended usage:
     Common.

Restrictions on usage:
     None.

Author:
     The W3C's Web Applications Working Group

Received on Wednesday, 28 October 2009 15:36:43 UTC