Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document describes an approach for creating packages of files for use on the web. The approach is to package them using a new application/package
media type. To access packages related to other files on the web, clients that understand packages of files look for a Link
header or (in HTML documents) a <link>
element with a new link relation of package
. Other formats may define format-specific mechanisms for locating related packages.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The Technical Architecture Group has put together this draft for comment and to indicate future direction. It is likely this draft will be handed on to a task force or working group to go through the rest of the process.
The technical proposals within this draft (namely new media type and link relation) will eventually require review and registration at IETF. That process has not started yet.
This document was published jointly by the Web Applications Working Group and the Technical Architecture Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to www-tag@w3.org (subscribe, archives) and public-webapps@w3.org (subscribe, archives). All comments are welcome.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains public lists of any patent disclosures (Technical Architecture Group, Web Applications Working Group) made in connection with the deliverables of the groups; those pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 August 2014 W3C Process Document.
Today's websites rely on multiple files. If a user visits http://www.bbc.co.uk/ they will need to download about 160 files to view the page in its entirety. The HTML page they download at http://www.bbc.co.uk/ contains references to stylesheets, scripts, images and other files, each of which may contain references to further files themselves. Many of these resources will themselves have been originally developed as separate resources and merged to avoid the client having to make multiple requests: CSS and Javascript files are concatenated together; images are merged and used with CSS spriting. These concatenation and spriting techniques are rudimentary forms of packaging for performance.
The web is becoming more modular. Web components [components-intro] provide developers with the means to create reusable components, such as date pickers, carousels or tab layouts, that can be reused in other web pages. These components are defined through HTML, Javascript and CSS but may also require other resources such as images and data to operate. Meanwhile ES6 Modules [ECMASCRIPT] will result in smaller, self-contained and cross-referencing Javascript files. This modularity requires packaging for ease of distribution.
Many websites are no longer simple providers of content: they are applications that use web technologies to deliver their user interface. Initiatives such as Firefox OS and Chrome OS demonstrate the potential of trusted, installable applications built with web technologies. To be used in this way, applications must be self-contained packages of resources that can be tested and signed.
Packages of content and data are not only useful for web applications. Digital publishing requires the packaging of content, stylesheets, fonts and media. Data publication typically requires data and metadata to be packaged together. Archiving requires the packaging of whole websites into dated bundles.
There are existing and upcoming solutions to these problems. On the performance side, HTTP/2 includes the facility to push multiple representations to clients as the result of a single request. Providing packages is orthogonal to the use of HTTP/2. Developers who cannot yet use HTTP/2 may find that using packages can provide performance benefits through reducing numbers of requests. All developers will benefit from being able to package modules and components in ways that make them easy to deliver and reuse.
There are also a plethora of packaging formats, such as:
Most of these formats are based on zips, which have three main drawbacks:
This document specifies a new format for packages which does not have these drawbacks: the Streamable Package Format defined in section 3. Streamable Package Format. It defines a package
link relation to point to packages from other resources in section 4. package Link Relation. But first, in section 2. Using Packages, this document describes patterns of use for packages that address the requirements described in this introduction.
This section is non-normative.
This section demonstrates how package-aware applications could use packages.
Packages can be used to populate caches associated with multiple URLs without making multiple requests. This may be beneficial in some cases to avoid the latency involved in making multiple connections, particularly for servers and clients that don't support SPDY or HTTP/2.
Packaging can also damage performance: packages may be bloated by more resources than are actually necessary for the requested page, or may be badly ordered such that resources that are required early in the display of a web page are provided late in a package. Packaging is not a silver bullet for performance issues.
In this scenario, a browser is pointed at the page http://example.org/shop
which returns the HTML:
<html> <head> <link rel="package" href="/lib/brand.pack" scope="/lib/brand/"> <link rel="stylesheet" href="/lib/brand/main.css"> ... </head> ... </html>
As it starts to receive the page, the browser starts to send off requests for other resources. It recognises the rel="package"
links (described in section 4. package Link Relation) as meaning that the files referenced by those links contain useful resources for the display of the page. It starts to download them, taking note of their scope (described in section 4.1 Package Scope).
When the browser comes to download the resource http://example.org/lib/brand/style.css
, it checks to see if that resource is included in the scope of a package. In this case, the URL starts with http://example.org/lib/brand/
so the browser can guess that it is included in the http://example.org/lib/brand.pack
package and not make a separate request for the stylesheet.
The http://example.org/lib/brand.pack
package contains the main CSS stylesheet, but also font files and images that are used as background images within the CSS:
Content-Location: http://example.org/lib/brand.pack Expires: Mon, 07 Apr 2014 00:00:00 GMT --mqt84qpfq8xf3qpmdicdma; Content-Location: brand/main.css Content-Type: text/css @font-face { font-family: 'Shop'; src: url('shop.woff') format('woff'); } body { background-image: url('images/bg.jpg') no-repeat center center fixed; ... } --mqt84qpfq8xf3qpmdicdma; Content-Location: brand/shop.woff Content-Type: application/font-woff Expires: Mon, 06 Apr 2015 00:00:00 GMT ... --mqt84qpfq8xf3qpmdicdma; Content-Location: brand/images/bg.jpg Content-Type: image/jpeg Expires: Mon, 06 Apr 2015 00:00:00 GMT ... --mqt84qpfq8xf3qpmdicdma;--
As the package is loaded, the browser cache is populated with the content of http://example.org/lib/brand/main.css
, http://example.org/lib/brand/shop.woff
and http://example.org/lib/brand/images/bg.jpg
. Because the package is streamed, the browser can use the CSS straight away, but the supporting resources are loaded rapidly after.
A couple of days later, on revisiting the page, the browser notices that its cached copy of http://example.org/lib/brand/main.css
has expired. It requests that CSS file separately to update its cache. There is no need to request the font or the background image as these haven't expired.
If we progress further with the 2NN Contents of Related
status code, it would be good to add a scenario that shows that in action.
Package-aware caches SHOULD populate their caches using packages that are indicated through:
rel=package
Link
HTTP header in the response to a requestrel=package
<link>
tag in an HTML document
The rel=package
link relation is described in section 4. package Link Relation.
Package-aware caches SHOULD delay requesting resources within the scope of a package that they are downloading, until the package has been processed.
If a package contains another package that is recognised by the package-aware cache, that package SHOULD be used to populate the cache in the same way.
If a package is in the Streamable Package Format (described in section 3. Streamable Package Format), package-aware caches SHOULD determine the cachability and other characteristics of each part of the package by examining (in order of priority):
If a package is in the Streamable Package Format, package-aware caches should be aware that there may be multiple parts with the same part URL but with different types or languages. Caches should be populated with attention paid to the Vary
header to determine which headers are significant. Package-aware caches SHOULD only use the first part with the same content-negotiated characteristics.
Packages can be used to provide installable web applications, both within marketplaces and simply on the web.
In this scenario, a browser is pointed at https://editor.example.com/
. It fetches the home page of the site, and sees:
<html> <head> <link rel="package" href="/editor.zip" scope="/" type="application/widget"> ... </head> ... </html>
The browser recognises that there is a rel=package
link in the HTML page whose scope is the entirety of the website, and whose type is a package format that it recognises. It pops up a dialog to ask the user whether they would like to install the application locally, and downloads and installs it if the user agrees.
Package-aware installers SHOULD prompt for the installation of packages that are indicated through:
rel=package
Link
HTTP header in the response to a requestrel=package
<link>
tag in an HTML documentwhere:
The rel=package
link relation is described in section 4. package Link Relation.
If a package is in the Streamable Package Format (described in section 3. Streamable Package Format), it SHOULD include a Link
header in the package header with rel=describedby
to explicitly point to the resource within the package that describes the package. Alternatively, it SHOULD use a rel=start
or rel=first
to point to the resource which is the starting point for the application (ie the initial page to load). Otherwise, the first part of the package should be a suitable starting point.
Packages can be used to distribute code libraries that are made up of multiple components (modules). For this to work smoothly, they need to be recognised by package management systems such as Bower.
A developer wants to use a time-handling Javascript package within their own code. They point their package management system at the location of the Javascript package, https://example.org/time.pack
. The package management system retrieves the package:
Content-Type: application/package Link: <component.json>; rel=describedby --p993fj39qp3aj8pjacda Content-Location: component.json Content-Type: application/json ... package definition ... --p993fj39qp3aj8pjacda Content-Location: time.js Content-Type: text/javascript Link: <locale.pack>; rel=package; scope=locale/ ... main Javascript ... --p993fj39qp3aj8pjacda Content-Location: locale.pack Content-Type: application/package ... package of locale-specific data ... --p993fj39qp3aj8pjacda--
It unpacks the package into the relevant directory on the developer's machine, but also includes the package itself in the developer's file system so that the package can be referenced by the developer in the website itself:
<html> <head> <link rel="package" href="/scripts/utils/time.pack" scope="/scripts/utils/time" type="application/package"> <script src="/scripts/utils/time.js"></script> ... </head> ... </html>
Package managers that handle Streamable Package Format packages SHOULD unpack nested packages; these indicate implicit dependencies within the package.
Creators of Streamable Package Format packages for distribution SHOULD NOT include a Content-Location
header in the package header as this prevents them from being reused in other locations.
Data on the web often gains context from other, related, data and documentation. Packages can enable data reusers to quickly get hold of all the relevant data and documentation they need in a single, discoverable, bundle, while simultaneously making that data available directly on the web.
This pattern is of particular relevance to the CSV on the Web Working Group.
An online news report references some recent demographic statistics, pointing to http://example.org/stats/imd.csv
. When a data scientist happens on the reference, they fire up their data analysis application and points it at the URL. The HTTP response looks like:
HTTP/1.1 200 OK Content-Location: /stats/imd.csv Content-Type: text/csv Link: <imd.pack>; rel=package ... CSV file ...
The CSV file is standard CSV: it contains no metadata that describes the types or meaning of any of the columns that it contains, or about the codes that have been used to identify the geographies that the data covers. Fortunately, the data analysis application is package aware. It recognises the rel=package
link and automatically downloads the package, which looks like:
Content-Location: http://example.org/stats/imd.pack Content-Type: application/package Link: <datapackage.json>; rel=describedby --nu0hv0ag70eahoea0e0a Content-Location: datapackage.json Content-Type: application/json ... machine-readable description of the package ... --nu0hv0ag70eahoea0e0a Content-Location: imd.csv Content-Type: text/csv ... statistical data ... --nu0hv0ag70eahoea0e0a Content-Location: geographies.csv Content-Type: text/csv ... data about the geographies covered by the statistics ... --nu0hv0ag70eahoea0e0a Content-Location: imd.pdf Content-Type: application/pdf ... human-readable documentation of the data ... --nu0hv0ag70eahoea0e0a--
The data analysis application uses the information in datapackage.json
to handle the types of the values in the original data correctly, and to display them with nice labels. It provides easy access to the linked information from geographies.csv
and shows the data scientist the human-readable documentation that has been made available.
Package-aware data analysis software SHOULD follow rel=package
links in HTTP headers to access additional information about data that it retrieves by HTTP.
Data publishers SHOULD use the Link
header to provide packages of information when individual (context-free) data files are requested.
This section defines the Streamable Package Format (SPF) which has the media type application/package
.
SPF is designed to be consistent with multipart media types. However it is not defined as a multipart/*
subtype because these types require the inclusion of a boundary
parameter in their media type. Setting this parameter is burdensome in situations when the publisher is not able to configure the server. It is also unnecessary as the boundary can be ascertained from the content of the file.
An example SPF file is as follows:
--gc0pJq0M:08jU534c0p Content-Location: /index.html Content-Type: text/html <html> <head> <script src="/scripts/app.js"></script> ... </head> ... </html> --gc0pJq0M:08jU534c0p Content-Location: /scripts/app.js Content-Type: text/javascript module Math from '/scripts/helpers/math.js'; ... --gc0pJq0M:08jU534c0p Content-Location: /scripts/helpers/math.js Content-Type: text/javascript export function sum(nums) { ... } ... --gc0pJq0M:08jU534c0p--
This SPF file includes three parts — /index.html
, /scripts/app.js
and /scripts/helpers/math.js
— and uses the boundary gc0pJq0M:08jU534c0p
.
The general structure of an SPF file is described by the following [ABNF]:
spf = [ header CRLF ] 1*( part CRLF ) "--" boundary "--" header = *( message-header CRLF ) part = "--" boundary CRLF *( message-header CRLF ) CRLF [ message-body ]
Should a package include a header for itself? Should it be in the same message-header
format as is used elsewhere? This is flexible if somewhat verbose, and enables us to lean on well-known existing methods of expressing metadata rather than inventing a custom format.
An SPF file MAY start with an optional package header that provides metadata about the package itself. The syntax of this header is the same as that of the header within each part of the package. See section 3.2 Parts for details.
An example package that includes a package header is shown below.
Content-Type: application/package Content-Location: http://example.org/exampleWidget.pack Link: <config.xml>; rel=describedby --j38n02qryf9n0eqny8cq0 Content-Location: config.xml Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <widget xmlns = "http://www.w3.org/ns/widgets" id = "http://example.org/exampleWidget" version = "2.0 Beta" height = "200" width = "200" viewmodes = "fullscreen"> ... </widget> ... other parts ... --j38n02qryf9n0eqny8cq0--
The package metadata explicitly:
Content-Type
headerhttp://example.org/widget.pack
through the Content-Location
headerLink
headerA package file is comprised of a number of parts, separated by boundaries. Each part comprises a header and a body.
In ABNF, the definition of message-header
and of message-body
are taken from [RFC2616] and are:
message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string> message-body = entity-body | <entity-body encoded as per Transfer-Encoding> entity-body = *OCTET
The body of a part can be any binary data. It MUST NOT include the boundary used in the package.
The header of a part follows the same syntax as the header for an HTTP response, and can reuse any HTTP header. This header MUST include a Content-Location
header which provides the part URL. The URL provided by the Content-Location
header MUST be a relative URL and MUST NOT be a scheme-relative URL. The URL is resolved using a base URL that is the location of the package. Other URLs used within the part header (for example in Link
headers) or in the body of the part (for example within src
attributes if the part is an HTML document) MUST be resolved using the part URL as the base URL.
Applications that process packages SHOULD ignore parts which do not have a Content-Location
header, or whose Content-Location
header is not a relative URL or is a scheme-relative URL. Such parts contain information about resources from a different origin than the package itself, which might not be trustworthy.
It is possible for multiple parts within a package to have the same part URL, either because they have exactly the same Content-Location
header or because their Content-Location
headers resolve to the same URL. Parts with the same part URL SHOULD be distinguishable by having different values for other headers commonly used for content negotiation, such as Content-Type
or Content-Language
. When these headers are used to distinguish between parts, they SHOULD be listed within the Vary
header for the parts that share the same part URL. For example:
--r 87q0ewahn8o9fqrt0cadkm Content-Location: /events/extensible-web-summit-2014 Content-Type: text/html Vary: Content-Type ... HTML page about the Extensible Web Summit 2014 ... --r 87q0ewahn8o9fqrt0cadkm Content-Location: /events/extensible-web-summit-2014 Content-Type: text/calendar Vary: Content-Type ... iCalendar event for the Extensible Web Summit 2014 ... --r 87q0ewahn8o9fqrt0cadkm--
When a part is itself a Streamable Package Format package, its package header should become the part header. For example:
Content-Location: http://example.org/brand.pack --uf8eanfueq8yr8x03qyx8fq Content-Location: brand/main.css Content-Type: text/css Link: <brand/font.pack>; rel=package; scope=brand/font/ @font-face { font-family: 'BrandFont'; src: url('font/brand.woff') format('woff') url('font/brand.ttf') format('truetype'); } ... rest of the CSS ... --uf8eanfueq8yr8x03qyx8fq Content-Location: brand/font.pack Content-Type: application/package --j808fd8apfhac;fe9a Content-Location: font/brand.woff Content-Type: application/font-woff ... font in WOFF format ... --j808fd8apfhac;fe9a Content-Location: font/brand.ttf Content-Type: application/font-sfnt ... font in Truetype format ... --j808fd8apfhac;fe9a-- --uf8eanfueq8yr8x03qyx8fq--
A boundary is used to separate the parts within the package. The same boundary is used throughout the package. The boundary used within an SPF file MUST NOT appear within the body of any part in the package. The boundary can be identified by an application by taking the string after the initial "--"
of the first line that starts with a "--"
.
The definition of boundary
is taken from [RFC2046] and is:
boundary = 0*69bchars bcharsnospace bchars = bcharsnospace / " " bcharsnospace = DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
Note that this places the restriction on the boundary that it must not be more than 70 characters long and it cannot end in a space character.
The fragment identifier scheme for the application/package
media type can be used to identify a part of the package or a fragment of a part.
In general, links should be made directly to resources on the web rather than to parts of packages. The particular package(s) that a resource appears in may be an ephemeral phenomenon.
The general syntax of a fragment identifier for Streamable Package Format documents is one or more param=value
pairs, separated by semi-colons. In ABNF:
fragment = parameter *( ";" parameter ) parameter = ( "url" "=" value ) / ( "rel" "=" relation-type ) / ( "type" "=" ( media-type / quoted-mt ) ) / ( "lang" "=" Language-Tag ) / ( "fragment" "=" value ) value = quoted-string / string-no-sc quoted-string = < as defined in [RFC2616] > string-no-sc = < any string that does not contain a semicolon > relation-type = < as defined in [RFC5988] > media-type = < as defined in [RFC5988] > quoted-mt = < as defined in [RFC5988] > Language-Tag = < as defined in [RFC5646] >
Note that when used within a URL, some characters within the fragment identifier, such as #
, should be escaped.
The fragment identifier MUST contain either a url
parameter or a rel
parameter and MUST NOT contain both of these parameters. These parameters are used to construct an initial list of candidate parts as follows:
url
parameter is specified, this is interpreted as a (possibly quoted) URL that is resolved relative to the base URL of the package to create a candidate parts URL. The candidate parts are those parts whose part URL is equal to the candidate parts URL.
rel
parameter is specified, the package header is examined for Link
headers whose rel
parameter is equal to the rel
parameter of the fragment identifier. There may be several such Link
headers, which are used to create a list of candidate part URLs by resolving the target URL of each link against the base URL of the package. The candidate parts are those parts whose part URL is equal to any of the candidate part URLs.
If the type
or lang
parameters are specified in the fragment identifier, these are used to further narrow down the candidate parts:
type
parameter is specified, the candidate parts are filtered down to only those that have a Content-Type
header whose media type matches the (possibly quoted) media type provided by the type
parameter.
lang
parameter is specified, the candidate parts are further filtered down to only those that have a Content-Language
header whose media type matches the language tag provided by the lang
parameter.
If there are no parts in the list of candidate parts then the fragment identifier does not identify any fragment of the package. Otherwise, the identified part is the first part within the list of candidate parts.
If the fragment identifier specifies a fragment
parameter, the value of that parameter is used to identify a fragment within the identified part, according to the media type for that part (as given by its Content-Type
header).
For example, the URL:
http://example.org/downloads/editor.pack#url=/root.html;fragment=colophon
refers to an element whose id is colophon
within the part of the package whose part URL is http://example.org/root.html
. This should be the same as:
http://example.org/root.html#colophon
As an example of using the rel
and type
parameters, imagine a package like:
Content-Location: http://example.org/downloads/spending.pack Link: </metadata/spending>; rel=describedby --ux3pqy9qcpfmqfexptbv43q8p Content-Location: /metadata/spending Content-Type: text/turtle Vary: Content-Type ... Metadata about the package in Turtle format ... --ux3pqy9qcpfmqfexptbv43q8p Content-Location: /metadata/spending Content-Type: application/ld+json Vary: Content-Type ... Metadata about the package in JSON-LD format ... --ux3pqy9qcpfmqfexptbv43q8p--
The URL:
http://example.org/downloads/spending.pack#rel=describedby;type=application/ld+json
would identify the second of the parts in the package. The rel=describedby
in the fragment identifier indicates that the target URL of the Link
header should be used to locate the relevant part. Since there are two parts whose part URL is http://example.org/metadata/spending
, the type=application/ld+json
parameter is used to narrow the selection down to the second of the parts, whose Content-Type
header matches.
As it contains other files, Streamable Package Format files may contain active content (such as scripts) which, if run, may have devastating effects. Applications should treat all files contained within a package with the same care as they would if they had been received individually.
Packages in the Streamable Package Format contain assertions about the content of resources at other locations on the web (indicated through the part URL). Applications that process files in the Streamable Package Format should be aware that the content might not match that at the part URL. section 2.1 Populating Caches discusses the implications of this when packages are used to populate caches.
This section is non-normative.
This section contains some recommendations and guidelines for the creation of packages in the Streamable Package Format.
Packages may be compressed in their entirety or the individual parts of the package may be compressed independently. In the latter case, the part headers should indicate the compression algorithm that has been used on the part during the packaging process using a Transfer-Encoding
header.
Not sure what to recommend here. Presumably compressing the entire file undermines its streamability so the recommendation should be to compress individual parts?
The first part in a package should usually provide a starting point for understanding or making use of the other resources in the package. For example, it might be:
The remaining parts should be ordered based on the priority with which they need to be loaded to enable the contents of the package to be used (with high priority parts earlier in the package), and based on the size of the part (with larger parts later in the package). For a web application, a suitable order might be:
As described in section 3.2 Parts, you can provide any HTTP header for the parts within a package and must provide a Content-Location
header. Some HTTP headers are inappropriate because the part is not, in fact, an HTTP response. Other HTTP headers that may be useful for applications are:
Transfer-Encoding
, if the part has been individually compressed
Vary
, if there are multiple parts with the same part URL
Content-Type
, Content-Encoding
and/or Content-Language
to provide different metadata about the representation
Cache-Control
and/or Expires
to control the caching of the individual parts
ETag
and/or Last-Modified
to support subsequent conditional fetching of the resource
Link
to indicate relationships between the file and other files in the package or on the web
package
Link Relation
The package
link relation refers to a package in which a representation of the link's context URL or related resources can be found. There are no constraints on the format of the package (the package may be a zip, or any of the other package formats listed in , for example).
Would it be helpful to distinguish between a package in which the link's context resource itself can be found, and one which only contains related resources?
The package
link relation can be used wherever link relations can be used, such as in links within web pages:
<a href="editor.gzip" rel="package">download this application</a>
or links within the header of an HTML page:
<link rel="package" href="http://example.org/exampleWidget.zip" type="application/widget">
or links within an HTTP header:
Link: </downloads/spending.pack>; rel=package; type=application/package
When referring to a package, it is often useful to provide an indication of what the package contains so that an application retrieving the package can anticipate which resources it can get from the package rather than directly. This can be indicated by specifying a package scope, which is a URL. Applications can use this as a hint that indicates that any resources whose URL starts with the package scope can be found within the package. If no package scope is indicated in a link, applications MUST NOT make any assumptions about the contents of the package.
In an HTML document, the package scope is indicated through a scope
attribute on the <a>
or <link>
element that references the package. This attribute contains a URL that is resolved against the base URL of the HTML document. For example:
<a href="editor.gzip" rel="package" scope="/">download this application</a>
indicates that the entire website that includes the page in which this link is found is contained within the package, while:
<link rel="package" href="http://example.org/exampleWidget.zip" type="application/widget" scope="http://example.org/exampleWidget/">
indicates that any resources whose URLs start with http://example.org/exampleWidget/
can be found within http://example.org/exampleWidget.zip
.
In an HTTP Link
header, the package scope is indicated through a scope
link extension. The value of this link extension has the same syntax and is resolved in the same way as the anchor
parameter as defined in [RFC5988]. (In summary, it is a URL wrapped in double quotes, which is resolved against the requested URL.)
For example if the response to a request to http://example.org/data/spending-201405.csv
includes the header:
Link: </downloads/spending.pack>; rel=package; type=application/package; scope="spending-"
this implies that the package at http://example.org/downloads/spending.pack
contains all resources whose URL begins with http://example.org/data/spending-
(including the requested http://example.org/data/spending-201405.csv
).
application/package
Media Type RegistrationThis registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA within the media type registry in accordance with [RFC6838].
application
package
pack
package
Link Relation RegistrationThis registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA within the Registry of Link Relations in accordance with [RFC5988].
package