Application Extension Bundle (AEB)
draft-tclarke-aeb-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

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/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on February 1, 2009.

Abstract

This memo presents a file format for describing an application extension bundle. An application extension bundle, otherwise know as an add-on, extension, plug-in, suite, or package, is an encapsalation of all the data needed to add functionality to a plug-in based application.

Table of Contents

1.  Introduction
    1.1.  Relationship to XPI
2.  File Format
3.  Required Files and Directories
    3.1.  /content
    3.2.  /platform
    3.3.  /icon
    3.4.  /license
4.  Multiple item AEB
5.  Failure to Install
6.  Shared Files
7.  References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

An application extension bundle (AEB) encapsulates all the data required to extend an application. Often refered to as a plug-in or add-on, an AEB is a specific format designed to be application and platform agnostic. AEB defines common file formats and directory layouts. Extension and specification points are defined by a target application.

1.1.  Relationship to XPI

The AEB format is based on the XPI format used by the Mozilla XPInstall (, “Mozilla XPInstall,” .) [refs.XPInstall] addon system. XPI is a compelling format containing much of the metadata and encapsulation information needed for an AEB. However, the XPI format is tightly coupled to the Mozilla project and the description documents often refer to specific XPI engine implementation details. AEB standardizes XPI and removes the Mozilla specific details. The original version of AEB is nearly an exact copy of the XPI format with minor changes and clarifications. AEB should, however, be considered a fork of XPI and further changes to XPI may not be reflected in AEB.

2.  File Format

An AEB is a ZIP archive (, “.ZIP File Format Specification,” .) [refs.zip] containing AEB specific files and target application files. The AEB specific files within the ZIP must use commonly compatible ZIP options. Since ZIP is a defacto standard, the features which are commonly compatible are not explicitly stated here but can be determined by a survey of available ZIP libraries. The version of the published ZIP specification at the time this document was written is 6.3.2. Optional compression algorithms and ZIP file extensions may be supported by a target application for target application specific files. An AEB may also exist as a directory hierarchy on a file system or file system-like service. (such as an FTP site) This is intended for use while devoloping an AEB. An AEB should be deployed as a ZIP archive. The file extension of an AEB ZIP archive must be .aeb unless a particular system does not support file extensions. When an AEB is associated with a MIME type (such as when served by an HTTP server) the MIME type should be application/x-aeb. The MIME type may be application/zip or application/octet-stream. A target application may impose additional file extension and MIME type restrictions. (for example, .myapp.app and application/x-aeb+x-myapp) A target application imposing additional restrictions may only require those restrictions on AEBs targetting only the target application. An AEB with multiple target applications must use only the restrictions in this document. A target application should always accept files meeting only the restrictions in this document.

3.  Required Files and Directories

Every AEB must contain an install manifest in /install.rdf. This file contains a AEB metadata written in the application extension bundle description language (AEBL) (Clarke, T., “Application Extension Bundle description Language (AEBL),” July 2008.) [refs.aebl]. This file shall be serialized in RDF+XML format. The root directory may also contain the following directories.

3.1.  /content

This contains most of the AEBs extension files. The contents of this directory are specific to a target application but generally contain files which will be installed in the target application.

3.2.  /platform

The /platform directory may contain sub-directories for each platform declared in the install.rdf file. The contents of the sub-directory corresponding to the current platform are unioned with the /content directory. If both directories contain a specific file, the /platform directory takes precedence. Not all platforms declared in the install.rdf file require a /platform directory.

3.3.  /icon

This directory generally contains icon files referenced in the install.rdf file. These should not be installed by the target application.

3.4.  /license

This directory generally contains license files referenced in the install.rdf file. There should not be installed by the target application.

4.  Multiple item AEB

An AEB may contain multiple AEB archives if the multiple item AEB type is specified in the install.rdf file. The /content and /platform directories should contain only files with the .aeb extension. These must be AEB ZIP archives. AEB archives in the /content directory shall be installed on all platforms and AEB archives in a sub-directory of /platform shall be installed on that platform. The installation order may be arbitrary but a target application may define a specific order. Failure to install any AEB archive in a multiple item AEB shall result in failure to install the entire multiple item AEB.

5.  Failure to Install

Installation of an AEB shall be an atomic operation. Failure to install an AEB shall remove a partially installed AEB.

6.  Shared Files

If an AEB request installation of a resource which is already present in the target application, the resource should be reference counted. When an AEB with a shared resource (a resource with a reference count greater than one) should only remove the resource if decrementing the reference count yields a new reference count of zero.

7. References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.