Network Working Group                                          T. Clarke
Internet-Draft                                                      BATC
Expires: February 1, 2009                                  July 31, 2008


        Application Extension Bundle description Language (AEBL)
                         draft-tclarke-aebl-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.



















Clarke                  Expires February 1, 2009                [Page 1]

Internet-Draft                    AEBL                         July 2008


Abstract

   This memo presents an RDF [refs.RDF] vocabulary for describing an
   application extension bundle [refs.aeb].  An application extension
   bundle, otherwise known 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.  An integral piece of
   an application extension bundle is the metadata describing the
   bundle.  The described RDF vocabulary contains required and optional
   metadata fields used by an application extension bundle to describe
   itself.








































Clarke                  Expires February 1, 2009                [Page 2]

Internet-Draft                    AEBL                         July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Relationship to XPI  . . . . . . . . . . . . . . . . . . .  4
     1.2.  A Note on Examples . . . . . . . . . . . . . . . . . . . .  4
   2.  AEBL Namespace and primary subject . . . . . . . . . . . . . .  5
   3.  Verbs  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Required . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  id . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.2.  version  . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.3.  type . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.4.  name . . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.5.  targetApplication  . . . . . . . . . . . . . . . . . .  7
     3.2.  Optional . . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  description  . . . . . . . . . . . . . . . . . . . . .  7
       3.2.2.  creator  . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.3.  developer  . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.4.  translator . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.5.  contributor  . . . . . . . . . . . . . . . . . . . . .  8
       3.2.6.  homepageURL  . . . . . . . . . . . . . . . . . . . . .  8
       3.2.7.  iconURL  . . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.8.  licenseURL . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.9.  hidden . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.10. targetPlatform . . . . . . . . . . . . . . . . . . . .  9
       3.2.11. requires . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.12. incompatible . . . . . . . . . . . . . . . . . . . . . 10
       3.2.13. updateURL  . . . . . . . . . . . . . . . . . . . . . . 10
       3.2.14. updateKey  . . . . . . . . . . . . . . . . . . . . . . 10
   4.  versions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  The aeb URL Scheme . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Updates  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Verbs  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
       6.1.1.  signature  . . . . . . . . . . . . . . . . . . . . . . 14
       6.1.2.  updates  . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20













Clarke                  Expires February 1, 2009                [Page 3]

Internet-Draft                    AEBL                         July 2008


1.  Introduction

   An application extension bundle (AEB) [refs.aeb] encapsulates all the
   data required to extend an application.  Often referred to as a
   plug-in or add-on, an AEB is a specific format designed to be
   application and platform agnostic.  An application accepting an AEB
   is referred to as a target application.  A key component of an AEB is
   descriptive metadata such as the AEB version, requirements, authors,
   etc.  The application extension bundle description language (AEBL) is
   an RDF [refs.RDF] vocabulary for the metadata needed by an AEB.

1.1.  Relationship to XPI

   The AEBL vocabulary is based on an RDF vocabulary used by the Mozilla
   XPInstall [refs.XPInstall] addon system, sometimes known as XPI.  XPI
   is a compelling format containing much of the metadata 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 and the AEBL standardize XPI and
   remove the Mozilla specific details.  The original version of AEBL is
   nearly an exact copy of the XPI format with minor changes and
   clarifications.  AEBL should, however, be considered a fork of XPI
   and further changes to XPI may not be reflected in AEBL.

1.2.  A Note on Examples

   Examples presented in this document will be presented in specific
   serializations of RDF such as rdf+xml and Notation3 [refs.N3Primer].
   The AEBL vocabulary is not restricted to these specific serializaions
   and any valid RDF serialization format should be considered equally
   valid for use with AEBL.  Specific implementations of AEBL may be
   restricted to one or more serializations.

   All examples assume the following prefixes

   @prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
   @prefix aebl: <urn:2008:03:aebl-syntax-ns#>.














Clarke                  Expires February 1, 2009                [Page 4]

Internet-Draft                    AEBL                         July 2008


2.  AEBL Namespace and primary subject

   AEBL elements are defined in the AEBL namespace.  The AEBL namespace
   is urn:2008:03:aebl-syntax-ns.  This namespace is subject to change
   before acceptance of this Internet Draft as an RFC.  The primary
   subject (the analog of an XML root element) is
   urn:aebl:install-manifest.












































Clarke                  Expires February 1, 2009                [Page 5]

Internet-Draft                    AEBL                         July 2008


3.  Verbs

3.1.  Required

3.1.1.  id

   A unique identifier for the AEB.

   o  A UUID [refs.UUID] in the form {00000000-0000-0000-0000-
      000000000000}

   o  An Internet email [refs.email] style address as a string.  This
      need not represent an existing email account but uses the same
      format.  Ex. aebname@organization.tld

   The id shall not change when the version of an AEB changes.  Version
   information is stored in the version (Section 3.1.2) verb.

   The following regular expression matches an id.

^([A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4})|((\{{0,1}([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12}\}{0,1}))$

3.1.2.  version

   The version verb identifies the version of the AEB.  The format of
   the object shall conform to the specification in the version numbers
   (Section 4) section.

3.1.3.  type

   The type verb indicates the type of extension stored in the AEB.
   Valid types are listed below.

   2  Functionality extensions and general extensions not fitting
      another category

   4  Themes and skins which change the look of a GUI application

   8  Locale and language extensions which add additional natural
      language translations

   32 Multiple item AEB [refs.aeb]

   >=16384  Types defined for a specific target application







Clarke                  Expires February 1, 2009                [Page 6]

Internet-Draft                    AEBL                         July 2008


3.1.4.  name

   The name verb indentifies the name of this AEB.  This is designed to
   be presented to a user and shall not be used for comparison or unique
   identification purposes.  The id (Section 3.1.1) verb is used to
   uniquely identify an AEB.

3.1.5.  targetApplication

   This verb defines a potential target application.  There must be at
   least one targetApplication defined in an AEB and there may be
   multiple targetApplications defined in an AEB.


<urb:aebl:install-manifest> aebl:targetApplication [ aebl:id "{00000000-0000-0000-0000-000000000000}" ].


3.1.5.1.  id

   This identifies the target application.  The format is identical to
   the main id (Section 3.1.1) verb.

3.1.5.2.  minVersion

   This identifies the minimum version of the target application
   required.  The format is the same as the version (Section 3.1.2)
   verb.

3.1.5.3.  maxVersion

   This identifies the maximum version of the target application
   required.  The format is the same as the version (Section 3.1.2)
   verb.

3.2.  Optional

3.2.1.  description

   This is a short description of the AEB intended for display to the
   user.  This should fit on one short line of text.  A specific target
   application may impose more strict length requirements.

3.2.2.  creator

   The creator verb identifies the name for the creator or prinicipal
   developer of the AEB.  This is inteded for display to the user.





Clarke                  Expires February 1, 2009                [Page 7]

Internet-Draft                    AEBL                         July 2008


3.2.3.  developer

   The developer verb identifies an additional developer of the AEB.
   The principal developer should be named with the creator
   (Section 3.2.2) verb.  Additional developers are named with the
   developer verb.  There must be one and only one creator
   (Section 3.2.2) verb if a developer verb is present.  There is no
   limit to the number of developer verbs allowed but a target
   application may provide more strict limits.  This is intended for
   display to the user.

3.2.4.  translator

   The translator verb identifies language translators.  There is no
   limit to the number of translator verbs allowed but a target
   application may provide more strict limits.  This is intended for
   display to the user.

3.2.5.  contributor

   The contributor verb identifies additional contributor to the AEB.
   There is no limit to the number of contributor verbs allowed but a
   target application may provide more strict limits.  This is intended
   for display to the user.

3.2.6.  homepageURL

   The URL for the AEB's homepage.  If present, this must be a valid
   URL.  This is intended for display to the user.

3.2.7.  iconURL

   The URL for a 32x32 pixel icon intended for display to the user.
   This will typically be displayed in a list of AEBs in the target
   application.  The icon should be a common image file format such as
   PNG, JPG, or ICO.  A target application may further restrict the
   acceptable file types.  Target applications must accept the AEB URL
   scheme (Section 5) and may accept other URL schemes.

3.2.8.  licenseURL

   The URL for a file containing license text.  This is intended for
   display to the user.  A target application may display this in any
   way but this will typically be displayed in an "accept/reject" dialog
   box during AEB installation.  A target application must accept plain
   text files in UTF-8 format and may accept other file formats.  A
   target application must accept the AEB URL scheme (Section 5) and may
   accept other URL schemes.  There is no limit to the number of



Clarke                  Expires February 1, 2009                [Page 8]

Internet-Draft                    AEBL                         July 2008


   licenseURL verbs preset.  All licenseURL files must be displayed but
   a target application may use any ordering.

3.2.9.  hidden

   This is a boolean value.  If true, the AEB is considered a hidden
   AEB.  A target application should not display this AEB in a list of
   installed AEBs.  A target application may have a way to enable the
   display of hidden AEBs.  This is intended to prevent the user from
   seeing or removing AEBs which are considered a core piece of a target
   application.  Care should be used when marking an AEB as hidden.  A
   target application may disallow hidden AEBs.  The value is case
   insensitive.  Valid positive values are: 1, t, and true.  Valid
   negative values are: 0, f, and false.

3.2.10.  targetPlatform

   This specifies the target platform for this AEB.  There is no limit
   to the number of targetPlatform verbs allowed.  This should contain
   either an operating system target or a complete application binary
   interface (ABI) target.  A target application defines valid target
   strings.  Some examples are WINNT, Linux, i686-pc-linux-gnu, and
   x86_64-msvc8.

3.2.11.  requires

   This verb identifies another AEB requirement of this AEB.  The format
   is identical to targetApplication (Section 3.1.5) but the target id
   refers to an AEB id.  There is no limit to the number of requires
   allowed.  A target application may install the AEB if a required
   target is not present but should disable the AEB until the target
   becomes available.  In addition to the id (Section 3.1.5.1),
   minVersion (Section 3.1.5.2), and maxVersion (Section 3.1.5.3) verbs,
   requires may contain a targetApplication verb.

3.2.11.1.  targetApplication

   The format of this verb is identical to the higher level
   targetApplication (Section 3.1.5) verb.  It is used to further
   restrict a requires (Section 3.2.11).  If present, it indicates that
   the requires only applies when the target application meets the
   specification of targetApplication.  This is intended to specify AEB
   requirements which are different depending on the target application
   of the AEB.







Clarke                  Expires February 1, 2009                [Page 9]

Internet-Draft                    AEBL                         July 2008


3.2.12.  incompatible

   This verb identifies extensions which are incompatible with this AEB.
   The format is identical to requires (Section 3.2.11) but the
   identified extension and version must not be present in the target
   application.

3.2.13.  updateURL

   This URL provides an update manifest file with information about AEB
   updates.  This URL should use the https scheme.  If a non-secure
   scheme is specified, an updateKey (Section 3.2.14) should be
   specified.  Further information on the format of this URL is
   presented in updates (Section 6).

3.2.14.  updateKey

   This contains a base64 encoded public key used to verify update
   signatures.  The key is comprised of the encryption algorithm
   identifier, following by a colon then the base64 encoding.  The data
   contained in the encoding is specific to the encryption algorithm
   identifier.  A target application which does not support the
   specified encryption algorithm must refuse updates for this AEB.
   There may be multiple updateKey verbs each providing a key for a
   different encryption algorith.  It is suggested that the updateURL
   (Section 3.2.13) use the https scheme and the updateKey verb not be
   used.  Further information is presented in updates (Section 6).

   An example updateKey


<urb:aebl:install-manifest> aebl:updateKey "x509:MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK426erD/H3XtsjvaB5+PJqbhj
                                                    Zc9EDI5OCJS8R3FIObJ9ZHJK1TXeaE7JWqt9WUmBWTEFvwS+FI9vWu8058N9CHhD
                                                    NyeP6i4LuUYjTURnn7Yw/IgzyIJ2oKsYa32RuxAyteqAWqPT/J63wBixIeCxmysf
                                                    awB/zH4KaPiY3vnrzQIDAQAB".
















Clarke                  Expires February 1, 2009               [Page 10]

Internet-Draft                    AEBL                         July 2008


4.  versions

   Version numbers are period separated version fields.  A target
   application or AEB defines the specific meaning of various version
   fields.  This document defines the format and comparison rules only.
   There must be at least one version field and there is no limit to the
   number of allowed version fields.  Each version field is comprised of
   four parts: abcd.  Parts a and c are integers greater than or equal
   to 0.  Parts b and d are ASCII encoded strings.  Part a is required.
   If part b, c or d is present, all parts to the left are required.  A
   part may be an asterisk (*) indicating an infinite value for that
   part and is greater than all other values allowed for that part
   except * which is equal.  If a part contains a * the parts to the
   right shall be ignored.

   The following regular expression matches a version.

^(((-?\d+)|\*)((([a-zA-Z+_]+)|\*)(((-?\d+)|\*)(([a-zA-Z+_]+)|\*)?)?)?)(\.((-?\d+)|\*)((([a-zA-Z+_]+)|\*)(((-?\d+)|\*)(([a-zA-Z+_]+)|\*)?)?)?)*$

   Comparison of two versions is performed left to right.  The first
   version field is compared and if equal, the next version field is
   compared.  Missing or empty fields are equivalent to 0.  Comparison
   of fields is performed left to right on each version part.  The a and
   c fields are considered base 10 and are compared numerically.  Parts
   b and d are ASCII encoded strings and are bytewise compared.  An
   existing string part is always less than a nonexistent string part.
   A target application may interpret strings as case insensitive.  A *
   is always greater than any other value in a part.  The following
   example demostrates comparisons.

1.-1 < 1 == 1.0 == 1.0.0 < 1.1a < 1.1aa < 1.1ab < 1.1b < 1.1c
1.1c < 1.1foo < 1.1pre == 1.1pre0 < 1.1pre1a < 1.1pre1aa < 1.1pre1b < 1.1pre1
1.1pre1 < 1.1pre2 < 1.1pre10 < 1.1.-1 < 1.1
1.1 == 1.1.0 == 1.1.00 < 1.10 < 1.* < 1.*.1 < 2.0

















Clarke                  Expires February 1, 2009               [Page 11]

Internet-Draft                    AEBL                         July 2008


5.  The aeb URL Scheme

   The aeb URL scheme (for example aeb:///icons/small.png) is used to
   reference files stored in an AEB.  The root of an aeb URL refers to
   the root of the AEB archive as defined in [refs.aeb].














































Clarke                  Expires February 1, 2009               [Page 12]

Internet-Draft                    AEBL                         July 2008


6.  Updates

   An AEB may specify an updateURL (Section 3.2.13) which will return an
   update manifest.  If the URL scheme supports MIME types (such as http
   and https) the MIME type of the update manifest must be a valid RDF
   MIME type such as text/rdf+xml.  A target application may limit which
   RDF MIME types are accepted.  The updateURL may contain the following
   values which will be substituted before requesting the manifest.
   Substitutions will be encoded as valid URLs.

   %REQ_VERSION%  The request format version.  Currently this is 1

   %AEB_ID%  The id (Section 3.1.1) of this AEB

   %AEB_VERSION%  The version (Section 3.1.2) of the AEB

   %AEB_MAXAPPVERSION%  The maxVersion (Section 3.1.5.3) specified in
      the AEB of the targetApplication requesting the update manifest

   %AEB_STATUS%  A comma separated list of the status of installed AEBs.
      Each field is the id of the AEB, an equals (=) and a status
      string.  A target application defines the status strings.  If the
      corresponding status is supported by a target application, it
      should use the following strings.

      userEnabled  The AEB is enabled and functional.

      userDisabled  The user has disabled the AEB.

      incompatible  The AEB is installed but is disabled because it is
         not compatible with either the target application version or
         one or more AEB versions.

      blocksListed  If the AEB target of the update manifest request is
         disabled due to incompatibility of another AEB version, this
         AEB is cause.  Multiple AEBs may have this status.

      needsDependencies  The AEB is installed but is disabled because it
         is missing one or more AEB dependencies.

   %APP_ID%  The id (Section 3.1.5.1) of the target application
      requesting the update manifest

   %APP_VERSION%  The version of the target application requesting the
      update manifest






Clarke                  Expires February 1, 2009               [Page 13]

Internet-Draft                    AEBL                         July 2008


   %APP_TARGET%  The OS and ABI platform of the target application
      requesting the update manifest.  The specific format is defined by
      the target application.

   %APP_LOCALE%  The locale of the target application requesting the
      update manifest

   The update manifest is an RDF file simlar to an install manifest.
   The namespace is the same as an install manifest and the primary
   subject is urn:aebl:update-manifest:aebid where aebid is the id
   (Section 3.1.1) of the AEB.

6.1.  Verbs

6.1.1.  signature

   This contains the base64 encoded signature of the update manifest.
   This has the same format as updateKey (Section 3.2.14).  There may be
   multiple signature verbs which correspond to multiple updateKey verbs
   in the install manifest.  The algorithm for generating and verifying
   a signature is determined by the cryptographic algorithm.  The
   portion of the update that should be signed is the updates
   (Section 6.1.2) group.

6.1.2.  updates

   This contains an RDF list with one list element per AEB version
   defined in the update manifest.

6.1.2.1.  version

   This declares the version of the AEB for this list element.

6.1.2.2.  targetApplication

   This declares the target application for this list element.  There
   may be multiple targetApplication tags.  The format is the same as
   Section 3.1.5 with the addition of the following verbs.

6.1.2.2.1.  updateURL

   This is the URL for the AEB corresponding to this version
   (Section 6.1.2.1) and targetApplication (Section 6.1.2.2)
   combination.







Clarke                  Expires February 1, 2009               [Page 14]

Internet-Draft                    AEBL                         July 2008


6.1.2.2.2.  updateInfoURL

   This is a URL for an informational page about this updated AEB.  This
   is intended for display to the user.

6.1.2.2.3.  updateSignature

   This is the signature of the data obtained from Section 6.1.2.2.1.
   This is not needed if the URL scheme is secure (such as https) and
   follows the same rules and suggestions as signature (Section 6.1.1).

   An example update manifest


<?xml version="1.0" encoding="UTF-8"?>

<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:aebl="urn:2008:03:aebl-syntax-ns#">

  <RDF:Description about="urn:aebl:update-manifest:foobar@developer.org">
    <aebl:updates>
      <RDF:Seq>
        <!-- Each li is a different version of the same AEB -->
        <RDF:li>
          <RDF:Description>
            <aebl:version>2.2</aebl:version> <!-- This is the version number of the AEB -->

            <!-- One targetApplication for each application the AEB is compatible with -->
            <aebl:targetApplication>
              <RDF:Description>
                <aebl:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</aebl:id>
                <aebl:minVersion>1.5</aebl:minVersion>
                <aebl:maxVersion>2.0.0.*</aebl:maxVersion>

                <!-- This is where this version of the AEB will be downloaded from -->
                <aebl:updateURL>https://www.mysite.com/foobar2.2.aeb</aebl:updateURL>

                <!-- A page describing what is new in this updated version -->
                <aebl:updateInfoURL>http://www.mysite.com/updateinfo2.2.xhtml</aebl:updateInfoURL>
              </RDF:Description>
            </aebl:targetApplication>
          </RDF:Description>
        </RDF:li>

        <RDF:li>
          <RDF:Description>
            <aebl:version>2.5</aebl:version>
            <aebl:targetApplication>



Clarke                  Expires February 1, 2009               [Page 15]

Internet-Draft                    AEBL                         July 2008


              <RDF:Description>
                <aebl:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</aebl:id>
                <aebl:minVersion>1.5</aebl:minVersion>
                <aebl:maxVersion>2.0.0.*</aebl:maxVersion>
                <aebl:updateURL>http://www.mysite.com/foobar2.5.aeb</aebl:updateURL>
                <aebl:updateHash>sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6</aebl:updateHash>
              </RDF:Description>
            </aebl:targetApplication>
          </RDF:Description>
        </RDF:li>

      </RDF:Seq>
    </aebl:updates>

    <!-- A signature is only necessary if your AEB includes an updateKey
         in its install.rdf. -->
    <aebl:signature>x509:MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
                  ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
                  jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
                  BcVq13ad</aebl:signature>
  </RDF:Description>
</RDF:RDF>





























Clarke                  Expires February 1, 2009               [Page 16]

Internet-Draft                    AEBL                         July 2008


7.  Example


   @prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
   @prefix aebl: <urn:2008:03:aebl-syntax-ns#> .

   <urn:aebl:install-manifest>
      aebl:id "{00000000-0000-0000-0000-000000000000}" ;
      aebl:name "Test AEB" ;
      aebl:version "1.2.3b" ;
      aebl:type "2" ;
      aebl:description "This is a test" ;
      aebl:creator "Trevor Clarke" ;
      aebl:updateURL "https://www.foo.bar/ack" ;
      aebl:iconURL "aeb:///icons/small.png" ;
      aebl:licenseURL "aeb:///licenses/lgpl.txt" ;
      aebl:licenseURL "aeb:///licenses/creativecommons.txt" ;
      aebl:targetApplication [
         aebl:id "{12345678-0000-0000-0000-000000000000}" ;
         aebl:minVersion "1.2" ;
         aebl:maxVersion "1.*" ] ;
      aebl:targetPlatform "WINNT-x86_64-msvc8" .





























Clarke                  Expires February 1, 2009               [Page 17]

Internet-Draft                    AEBL                         July 2008


8.  References

   [refs.RDF]
              "Resource Description Framework (RDF)",
              <http://www.w3.org/RDF>.

   [refs.aeb]
              Clarke, T., "Application Extension Bundle (AEB)",
              I-D draft-tclarke-aeb-00, July 2008.

   [refs.XPInstall]
              "Mozilla XPInstall",
              <http://www.mozilla.org/projects/xpinstall/>.

   [refs.N3Primer]
              Berners-Lee, T., "A Notation3 Primer",
              <http://www.w3.org/2000/10/swap/Primer.html>.

   [refs.UUID]
              "Information technology -- Open Systems Interconnection --
              Remote Procedure Call (RPC)", ISO/IECC 11578:1996,
              <http://www.iso.ch/cate/d2229.html>.

   [refs.email]
              Klensin, J., Ed., "Simple Mail Transfer Protocol",
              RFC 2821, April 2001.

























Clarke                  Expires February 1, 2009               [Page 18]

Internet-Draft                    AEBL                         July 2008


Author's Address

   Trevor R H Clarke
   Ball Aerospace and Technologies Corp
   2875 Presidential Dr.
   Fairborn, OH  45324
   US

   Phone: +1 937 320 7087
   Email: tclarke@ball.com
   URI:   http://www.ballforge.net/








































Clarke                  Expires February 1, 2009               [Page 19]

Internet-Draft                    AEBL                         July 2008


Full Copyright Statement

   Copyright (C) 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.











Clarke                  Expires February 1, 2009               [Page 20]