The Archive and Package (arcp) URI schemeThe University of ManchesterOxford RoadManchesterUnited Kingdomstain@apache.orgMozilla Corporationmarcos@marcosc.com
General
Internet-DraftThis specification proposes the
Archive and Package URI scheme arcp.arcp URIs can be used to consume or reference hypermedia
resources bundled inside a file archive or an
application package, as well as to resolve URIs for
archive resources within a programmatic framework.This URI scheme provides mechanisms to generate a
unique base URI to represent the root of the archive,
so that relative URI references in a bundled resource
can be resolved within the archive without having to
extract the archive content on the local file system.An arcp URI can be used for purposes of isolation
(e.g. when consuming multiple archives),
security constraints (avoiding “climb out” from the archive),
or for externally identiyfing sub-resources
referenced by hypermedia formats.Mobile and Web Applications
may bundle resources such as stylesheets with
relative URI references
(section 4.2)
to scripts, images and fonts. Resolving
and parsing
such resources within URI handling frameworks may require
generating absolute URIs and applying
Same-Origin security policies separately for
each app.Software that is accessing resources bundled inside an
archive (e.g. zip or tar.gz file) can struggle to consume
hypermedia content types that use relative
URI references such as ../css/,
as it is challenging to establishing the base URI
(section 5.1)
in a consistent fashion.Frequently the archive might be unpacked locally,
implying base URIs like file:///tmp/a1b27ae03865/
to represent the root of the archive. Such URIs are temporary,
might not be globally unique, and could be vulnerable to
attacks such as “climbing out” of the root directory.An archive containing multiple HTML or
Linked Data resources, such as in a
BagIt archive , may be using
relative URIs to cross-reference constituent files,
making it challenging to index or annotate such resources.Consumptions of archives might be performed
in memory or through a common framework, abstracting
away any local file location.Consumption of an archive with a consistent base URL
should be possible no matter from which location it was retrieved,
or on which device it is inspected.When consuming multiple archives from untrusted sources
it would be beneficial to have a Same Origin policy
so that relative hyperlinks can’t escape the particular archive.The file: URI scheme
can be ill-suited for purposes such as above, where a
location-independent URI scheme is more flexible,
secure and globally unique.This specification proposes the
Archive and Package URI scheme arcp as
an alternative to addressing resources
within an archive, application or package.For the purpose of this specification, an archive is a
collection of sub-resources addressable by name or path.
This definition covers typical archive file formats like
.zip or tar.gz and derived +zip media types ,
but also non-file resource packages like
an LDP Container ,
an installed Web App ,
or a BagIt folder structure .For brevity, the term archive is used throughout this
specification, although from the above it can also mean
a container, application, aggregation or package.The main purpose of arcp URIs is to provide consistent identifiers as absolute
URIs for nested resources. This specification does not define a new network
protocol, however we suggest an abstract resolution protocol that
implementations can apply using existing protocols or
programming frameworks.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
.The arcp URI scheme follows the syntax for hierarchical
URIs according to the following productions:The arcp-authority component provides a unique identifier for the opened archive. See for details.The path-absolute component provides the absolute path of a resource
(e.g. a file or directory) within the archive. See
for details.The query component MAY be used, but its semantics is undefined by this specification.The “fragment” component MAY be used by implementations according
to and the implied media type of the
resource at the path. This specification does not specify how
to determine the media type.The purpose of the authority component in an arcp URI is
to build a unique base URI for a particular archive. The
authority is NOT intended to be resolvable without former
knowledge of the archive.The authority of an arcp URI MUST be valid according to
these productions:The prefix uuid, combines with the UUID production as defined in , e.g.
uuid,2a47c495-ac70-4ed1-850b-8800a57618cfThe prefix ni, combines with the alg-val production as defined in , e.g.
ni,sha-256;JCS7yveugE3UaZiHCs1XpRVfSHaewxAKka0o5q2osg8The prefix name, combines with the reg-name production
as defined in , e.g. name,app.example.com.The production authority matches its definition in .
As this necessarily also match the above prefixed productions,
those should be considered first before falling back to this production.The path-absolute component, if present,
MUST match the production in and provide
the absolute path of a resource
(e.g. a file or directory) within the archive.Archive media types vary in constraints and possibilities on
how to express paths, however implementations SHOULD use / as
path separator for nested folders and files.It is RECOMMENDED to include the trailing / if it is known
the path represents a directory.This specification does not constrain what format
might constitute an archive, and neither does it require
that the archive is retrievable as a single bytestream or file.Examples of retrievable archive media types include
application/zip, application/vnd.android.package-archive,
application/x-tar, application/x-gtar and
application/x-7z-compressed.Examples of non-file archives include
an LDP Container ,
an installed Web App ,
or a BagIt folder structure .The authority component identifies the archive itself.Implementations MAY assume that two arcp URIs with the
same authority component relate to resources within the same
archive, subject to limitations explained in this section.The authority prefix, if present, helps to inform consumers
what uniqueness constraints have been used when identifying
the archive, without necessarily providing access to the archive.If the prefix is uuid, followed by a UUID ,
this indicates a unique archive identity.If the prefix is uuid, followed by a v4 UUID
(section 4.4),
this indicate uniqueness based on a random number generator.
Implementations creating random-based
authorities SHOULD generate the v4 random UUID using
a suitable random number generator .If the prefix is uuid, followed by a v5 name-based UUID
(section 4.3),
this indicates uniqueness based on an existing archive location,
typically an URL.
Implementations creating location-based
authorities from an archive’s URL SHOULD generate the
v5 UUID using the URL
namespace 6ba7b811-9dad-11d1-80b4-00c04fd430c8
and the particular URL.
Note that while implementations cannot resolve which location was
used, they can confirm the name-based UUID if the location
is otherwise known.If the prefix is ni, this indicates a unique archive identity
based on a hashing of the archive’s bytestream or content.
Implementations can assume that resources within an
ni arcp URIs remains static, although the implementation may
use content negotiation or similar transformations.
The checksum MUST be expressed
according to the alg-val production in
(section 3).
Implementations creating hash-based authorities from an archive’s
bytestream SHOULD use the hash method sha-256 without truncation.If the prefix is name, this indicates that the authority
is an application or package name, typically as installed
on a device or system.
Implementations SHOULD assume that an unrecognised name
authority is only unique within a particular installation,
but MAY assume further uniqueness guarantees for names under
their control.
It is RECOMMENDED that implementations creating
name-based authorities use DNS names under their control,
for instance an app installed as app.example.com can
make an authority name,app.example.com to refer to its
packaged resources, or name,foo.app.example.com to refer to a
foo container distributed across all installations.The uniqueness properties are unspecified for arcp
URIs which authority do not match any of the prefixes defined in
this specification.The path component of an arcp URI identify individual
resources within a particular archive, typically
a directory or file.If the path is / - e.g. <arcp://uuid,833ebda2-f9a8-4462-b74a-4fcdc1a02d22/> -
then the arcp URI represent the archive itself,
typically represented as a root directory or collection.If the path ends with / then the path represents
a directory or collection.The arcp URIs can be used for uniquely identifying
the resources independent of the location of the archive,
such as within an information system.Assuming an appropriate resolution mechanism which have
knowledge of the corresponding archive, an arcp URI
can also be used for resolution.Some archive formats might permit resources
with the same (duplicate) path, in which case it is undefined from
this specification which particular entry is described.This specification do not define the protocol to
resolve resources according to the arcp URI scheme.
For instance, one implementation might rewrite arcp URIs to
localized paths in a temporary directory, while
another implementation might use an embedded HTTP server.It is envisioned that an implementation will
have extracted or opened an archive in
advance, and assigned it an appropriate authority according
to . Such an implementation
can then resolve arcp URIs, e.g. by using
in-memory access or mapping paths to the extracted archive on
the local file system.Implementations that support resolving arcp URIs SHOULD:Fail with the equivalent of Not Found if the authority is unknown.Fail with the equivalent of Gone if the authority is known, but the content of the archive is no longer available.Fail with the equivalent of Not Found if the path does not map to a file or directory within the archive.Return the corresponding (potentially uncompressed) bytestream if the path maps to a file within the archive.Return an appropriate directory listing if the path maps to a directory within the archive.Return an appropriate directory listing of the archive’s root directory if the path is /.Not all archive formats or implementations will have the
concept of a directory listing, in which case
the implementation MAY fail such resolutions with the
equivalent of “Not Implemented”.It is not undefined by this specification how an implementation
can determine the media type of a file within an archive. This could
be expressed in secondary resources (such as a manifest),
be determined by file extensions or magic bytes.The media type text/uri-list MAY be used to represent
a directory listing, in which case it SHOULD contain only URIs
that start with the arcp URI of the directory.Some archive formats might support resources which are
neither directories nor regular files (e.g. device files,
symbolic links). This specification does not define the
semantics of attempting to resolve such resources.This specification does not define how to change an archive
or its content using arcp URIs.If the authority component of an arcp URI matches the alg-val
production, an application MAY attempt to resolve the authority
from any .well-known/ni/ endpoint as specified in
section 4,
in order to retrieve the complete
archive. Applications SHOULD verify the checksum of the
retrieved archive before resolving the individual path.The productions for UUID and alg-val are restricted to
URI safe ASCII and should not require any encoding considerations.Care should be taken to %-encode the directory and file segments
of path-absolute according to (for URIs) or
(for IRIs).When used as part an IRI, paths SHOULD be expressed using
international Unicode characters instead of %-encoding as ASCII.Not all archive formats have an explicit
character encoding specified for their paths.
If no such information is available for the archive format,
implementations MAY assume that the path component
is encoded with UTF-8 .Some archive formats have case-insensitive paths, in
which cases it is RECOMMENDED to preserve the casing
as expressed in the archive.As multiple authorities are possible for the same
archive (), and path interpretation
might vary, there can be interoperability challenges when
exchanging arcp URIs between implementations. Some considerations:Two implementations describe the same archive
(e.g. stored in the same local file path), but using
different random-based UUID authorities. The implementations may
need to detect equality of the two UUIDs out of band.Two implementations describe an archive retrieved
from the same URL, with the same location-based UUID authority,
but retrieved at different times. The implementations might disagree
about the content of the archive.Two implementations describe an archive retrieved
from the same URL, with the same location-based UUID authority, but retrieved
using different content negotiation resulting in different
archive representations. The implementations may disagree
about path encoding, file name casing or hierarchy.Two implementations describe the same archive bytestream
using the hash-based authority, but they have used
two different hash algorithms. The implementations may
need to negotiate to a common hash algorithm.Two implementations access the same archive,
which contain file paths with Unicode characters,
but extracted to two different file systems. Limitations
and conventions for file names in the local file system
(such as Unicode normalization, case insensitivity, total path length)
may result in the implementations having
inconsistent or inaccessible paths.As when handling any content, extra care should be taken when
consuming archives and arcp URIs from unknown sources.An archive could contain compressed files that expand to
fill all available disk space.A maliciously crafted archive could contain paths with characters
(e.g. backspace) which could make an arcp URI invalid or
misleading if used unescaped.A maliciously crafted archive could contain paths
(e.g. combined Unicode sequences) that cause the
arcp URI to be very long, causing issues in information
systems propagating said URI.An archive might contain symbolic links that, if
extracted to a local file system, might address files
outside the archive’s directory structure. Implementations SHOULD
detect such links and prevent outside access.An maliciously crafted arcp URI might contain ../ path segments,
which if naively converted to a file:/// URI might address
files outside the archive’s directory structure. Implementations
SHOULD perform Path Segment Normalization
before converting arcp URIs.In particular for IRIs, an archive might contain multiple
paths with similar-looking characters or with different
Unicode combine sequences, which could be used to mislead users.An URI hyperlink might use or guess an arcp URI authority
to attempt to climb into a different archive for
malicious purposes. Applications SHOULD employ
Same Orgin policy checks if
resolving cross-references is not desired.While a UUID or hash-based authority provide some level of
information hiding of an archive’s origin, this should not
be relied upon for access control or anonymisation. Implementors
should keep in mind that such authority components in many
cases can be predictably generated by third-parties, for
instance using dictionary attacks.This specification requests that IANA registers the following
URI scheme according to the provisions of .Scheme name: arcpStatus: provisionalApplications/protocols that use this protocol:
Hypermedia-consuming application that handle archives
or packages.Contact: Stian Soiland-Reyes stain@apache.orgChange controller: Stian Soiland-ReyesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.UTF-8, a transformation format of ISO 10646UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK]URI Resolution Services Necessary for URN ResolutionRetrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. This memo defines an Experimental Protocol for the Internet community.Uniform Resource Identifier (URI): Generic SyntaxA Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]Internationalized Resource Identifiers (IRIs)This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.Randomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.A Universally Unique IDentifier (UUID) URN NamespaceThis specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]Defining Well-Known Uniform Resource Identifiers (URIs)This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]The Web Origin ConceptThis document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]Naming Things with HashesThis document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.Guidelines and Registration Procedures for URI SchemesThis document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.Multipurpose Internet Mail Extensions (MIME) Part Two: Media TypesThis second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]URI TemplateA URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]Additional Media Type Structured Syntax SuffixesA content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes.The "file" URI SchemeThis document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs.The BagIt File Packaging Format (V0.97)This document specifies BagIt, a hierarchical file packaging format for storage and transfer of arbitrary digital content. A "bag" has just enough structure to enclose descriptive "tags" and a "payload" but does not require knowledge of the payload's internal semantics. This BagIt format should be suitable for disk-based or network-based storage and transfer. BagIt is widely used in the practice of digital preservation.The app: URL SchemeWidget URI schemeLinked Data Platform 1.0Web App ManifestFirefox OS security overviewMozilla FirefoxResearch Object Bundle 1.0An document store application has received a file
document.tar.gz which content will be checked for consistency.For sandboxing purposes it generates a UUID v4
32a423d6-52ab-47e3-a9cd-54f418a48571 using a pseudo-random generator.
The arcp base URI is thus:The archive contains the files:./doc.html which links to css/base.css./css/base.css which links to ../fonts/Foo.woff./fonts/Foo.woffThe application generates the corresponding arcp URIs and uses those for URI resolutions to list resources and their hyperlinks:The application is now confident that all hyperlinked files are
indeed present in the archive. In its database it notes which tar.gz file
corresponds to UUID 32a423d6-52ab-47e3-a9cd-54f418a48571.If the application had encountered a malicious hyperlink
../../../outside.txt it would first resolve it to
the absolute URI <arcp://uuid,32a423d6-52ab-47e3-a9cd-54f418a48571/outside.txt> and
conclude from the “Not Found” error that the path /outside.txt was not
present in the archive.A web crawler is about to index the content of the URL
http://example.com/data.zip and need to generate absolute URIs
as it continues crawling inside the individual resources of the archive.The application generates a UUID v5 based on the
URL namespace 6ba7b811-9dad-11d1-80b4-00c04fd430c8 and
the URL to the zip file:Thus the location-based arcp URI for indexing the ZIP content isListing all directories and files in the ZIP, the crawler finds the URIs:When the application encounters http://example.com/data.zip some time later
it can recalculate the same base arcp URI. This time the ZIP file has been
modified upstream and the crawler finds additionally:If files had been removed from the updated ZIP file the
crawler can simply remove those from its database,
as it used the same arcp base URI as in last crawl.An application where users can upload software distributions
for virus checking needs to avoid duplication as users
tend to upload foo-1.2.tar multiple times.The application calculates the sha-256 checksum of the uploaded
file to be in hexadecimal:The base64url encoding of the binary version of the checksum is:The corresponding alg-val authority is thus:From this the hash base arcp URL is:The crawler finds that its virus database already contain entries
for:and flags the upload as malicious without having to scan it again.An application is relating BagIt archives
on a shared file system, using structured
“bag” folders and manifests rather than individual archive files.The BagIt payload manifest /gfs/bags/scan15/manifest-md5.txt lists the files:The application generates a random UUID v4
ff2d5a82-7142-4d3f-b8cc-3e662d6de756 and adds the corresponding
arcp URI to the bag metadata file /gfs/bags/scan15/bag-info.txtIt then generates arcp URIs for the files listed in the manifest:When a different application on the same shared file system encounter
these arcp URIs, it can match them to the correct bag folder by
inspecting the External-Identifier metadata.An application exposes in-memory objects
of an Address Book as a
Linked Data Platform container ,
but addressing the container using arcp URIs instead of
http to avoid network exposure.The arcp URIs are used in conjuction with a generic
LDP client library (developed for http), but connected
to the application’s URI resolution mechanism.The application generates a new random UUID v4
12f89f9c-e6ca-4032-ae73-46b68c2b415a for the
address book, and provides the corresponding arcp URI
to the LDP client:The LDP client resolves the container with content negotiation
for the text/turtle media type, and receives:The LDP client resolves the relative URIs to retrieve each of the contacts:A virtual file system driver on a mobile operating system
has mounted several packaged applications for resolving
common resources. An application requests the rendering
framework to resolve a picture from
<arcp://uuid,eb1edec9-d2eb-4736-a875-eb97b37c690e/img/logo.png>
to show it within a user interface.The framework first checks that the authority
uuid,eb1edec9-d2eb-4736-a875-eb97b37c690e is valid to access
according to the Same Origin policies or permissions of the
running application. It then matches the
authority to the corresponding application package.The framework resolves /img/logo.png from within
that package, and returns an image buffer it already had
cached in memory.A photo gallery application on a mobile device uses arcp URIs
for navigation between its UI states.
The gallery is secured so that other applications can’t normally
access its photos.The application is installed as the app name
gallery.example.org as the vendor controls example.org,
making the corresponding name-based arcp URI:A user is at the application state which shows the newest photos as thumbnails:The user selects a photo, rendered with metadata overlaid:The user requests to “share” the photo, selecting
messaging.example.com which uses a common arcp
URI framework on the device.The photo gallery registers with the device’s
arcp framework that the chosen messaging.example.com gets
read permission to its /photos/137 resource.The sharing function returns a URI Template :Filling in the template, the gallery requests to pop up:The arcp framework checks its registration for messaging.example.com
and finds the installed messaging application. It performs permission
checks that other apps are allowed to navigate to its /share state.The messaging app is launched and navigates to its “sharing”
UI, asking the user for a caption.The messaging app requests the arcp framework to retrieve
<arcp://name,gallery.example.org/photos/137>
using content negotiation for an image/jpeg representation.The arcp framework finds the installed photo gallery
gallery.example.org, and confirms the read permission.The photo gallery application returns a JPEG representation after
retrieving the photo from its internal store.After the messaging app has completed sharing the picture bytestream,
it request the UI framework to navigate to:The UI returns to the original view in the photo gallery.If the messaging app had attempted to retrieve the arcp URIthen it would be rejected by the arcp framework as permission was not
granted.However, if such access had been granted, the gallery could
return a text/uri-list of the newest photos:This examples show that although an arcp URI represents a resource,
it can have different representations or UI states
for different apps.This specification is inspired by two original URI scheme proposals from W3C,
app from and widget from
.The app URI scheme was used by packaged web apps in Mozilla’s Firefox OS
and to identify resources in
Research Object Bundles , however the W3C Notes
did not progress further as W3C Recommendation track documents, and their URI
schemes were never formally registered with IANA.While the focus of the previous proposals was to specify how to resolve
resources from within a packaged application, this specification generalize the
URI scheme to support referencing and identifying resources within any
archive, package or application, and adding flexibility for how resources
can be resolved.The authors would like to thank Graham Klyne,
Carsten Bormann, Roy T. Fielding, S Moonesamy,
Julian Reschke and Frank Ellermann
for valuable feedback and suggestions.