urn:2008:03:opticks-aebl-extension-ns# namespace.aeb:// URL identifying an image to use as an extension splash screen. This is an optional verb.helpEntry verbs.
Platform strings are defined as: os-procarch-compiler-debugmode Valid values are:
Combinations currently recognized in Opticks are:
The following are paths allowed in the "content" portion of an AEB.
Icon files can be in any format supported by Qt's QImage. The default supported formats are: bmp, gif, jpg, mng, png, pbm, pgm, ppm, tiff, xbm, and xpm.
License files can be either plain text or Qt richtext which is a subset of HTML. License files ending in ".htm" or ".html" are assumed to be richtext and all other license files are assumed to be plain text.
AEB files may be placed in the $APP_HOME/Extensions/AutoInstall directory. Files in this directory will be automatically installed when Opticks is started. If this method is used, the user will not be prompted to accept license agreements. Only AEB files will be installed from this directory, not unpacked AEB archives.
Files installed via an AEB should not be modified during execution. During the life cycle of an extension install, it is assumed that all installed files remain identical to the files in the original AEB.
| Network Working Group | T. Clarke |
| Internet Draft | BATC |
| <draft-tclarke-aeb-01> | March 2008 |
| Intended status: Informational | |
| Expires: September 2008 |
Application Extension Bundle (AEB)
draft-tclarke-aeb-01
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 in September 2008.
Copyright © The IETF Trust (2008). All Rights Reserved.
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.
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.
The AEB format is based on the XPI format used by the Mozilla XPInstall [2] 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.
An AEB is a ZIP archive [3] 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.
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) [1]. This file shall be serialized in RDF+XML format. The root directory may also contain the following directories.
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.
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.
This directory generally contains icon files referenced in the install.rdf file. These should not be installed by the target application.
This directory generally contains license files referenced in the install.rdf file. There should not be installed by the target application.
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.
Installation of an AEB shall be an atomic operation. Failure to install an AEB shall remove a partially installed AEB.
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.
| [1] | Clarke, T., “Application Extension Bundle description Language (AEBL)”, I-D draft-tclarke-aebl-01, March 2008. |
| [2] | “Mozilla XPInstall”, <http://www.mozilla.org/projects/xpinstall/>. |
| [3] | “.ZIP File Format Specification”, <http://www.pkware.com/documents/casestudies/APPNOTE.TXT>. |
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
| Network Working Group | T. Clarke |
| Internet Draft | BATC |
| <draft-tclarke-aebl-00> | June 2008 |
| Intended status: Informational | |
| Expires: December 2008 |
Application Extension Bundle description Language (AEBL)
draft-tclarke-aebl-00
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 in December 2008.
Copyright © The IETF Trust (2008). All Rights Reserved.
This memo presents an RDF [1] vocabulary for describing an application extension bundle [2]. 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.
An application extension bundle (AEB) [2] 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 [1] vocabulary for the metadata needed by an AEB.
The AEBL vocabulary is based on an RDF vocabulary used by the Mozilla XPInstall [3] 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.
Examples presented in this document will be presented in specific serializations of RDF such as rdf+xml and Notation3 [4]. 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#>.
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.
A unique identifier for the AEB.
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}))$
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.
The type verb indicates the type of extension stored in the AEB. Valid types are listed below.
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.
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}" ].
This identifies the target application. The format is identical to the main id (Section 3.1.1) verb.
This identifies the minimum version of the target application required. The format is the same as the version (Section 3.1.2) verb.
This identifies the maximum version of the target application required. The format is the same as the version (Section 3.1.2) verb.
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.
The creator verb identifies the name for the creator or prinicipal developer of the AEB. This is inteded for display to the user.
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.
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.
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.
The URL for the AEB's homepage. If present, this must be a valid URL. This is intended for display to the user.
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.
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 licenseURL verbs preset. All licenseURL files must be displayed but a target application may use any ordering.
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.
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.
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.
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.
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.
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).
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".
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
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 [2].
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.
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.
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.
This contains an RDF list with one list element per AEB version defined in the update manifest.
This declares the version of the AEB for this list element.
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.
This is the URL for the AEB corresponding to this version (Section 6.1.2.1) and targetApplication (Section 6.1.2.2) combination.
This is a URL for an informational page about this updated AEB. This is intended for display to the user.
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>
<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>
@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" .
| [1] | “Resource Description Framework (RDF)”, <http://www.w3.org/RDF>. |
| [2] | Clarke, T., “Application Extension Bundle (AEB)”, I-D draft-tclarke-aeb-00, June 2008. |
| [3] | “Mozilla XPInstall”, <http://www.mozilla.org/projects/xpinstall/>. |
| [4] | Berners-Lee, T., “A Notation3 Primer”, <http://www.w3.org/2000/10/swap/Primer.html>. |
| [5] | “Information technology -- Open Systems Interconnection -- Remote Procedure Call (RPC)”, ISO/IECC 11578:1996, <http://www.iso.ch/cate/d2229.html>. |
| [6] | Klensin, J., Ed., “Simple Mail Transfer Protocol”, RFC 2821, April 2001. |
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).