jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-wpack-bundled-responses

Commentary: Closes 
 Thanks . Sent 
 The context is The current format says :   that , it seems the format already allows a relative URL in the index section , however , it 'd be better to ask a clarification than guessing its intention . Using a relative URL is supposed to work ? If so , we do n't need to request a bundle format change to resolve 
 More context : https://chromium- This CL is intended to support relative URLs in web bundles for    feature . 
 What do you think about this ? I think the section was introduced by this change in WICG / webpackage . 
 cc : 
 We need to specify how the keys in the index section are parsed , independent of their semantics as s. I 'd intended that to eventually move to the when I removed the algorithms in , with the format spec here being less precise , but I think it was a mistake that I did n't even specify between absolute and relative URLs in the index . We should probably add a sentence here to say which it is . Since we have a use case for relative URLs , let 's pick that one . This spec should say something about what the URLs are relative to . Probably a bundle - defined base URL , which defaults to the location of the bundle but can be overridden by a section 's contents ? And that it 's an error if two sections independently set the base URL without their own definitions disambiguating ? 
 I agree that the spec should clearly say that it supports relative URL . Created . Could you please reivew ? I think when we introduce a new section , the section should be able to override the bundle 's URL . But I do n't know how useful it is yet . 
 This is a good idea , thank you ( and apologies for the delay in providing feedback ) . I have a small suggestion . 
 Thank you , this change looks good to me . I have a small suggestion below . Looks good , but please do run this by before merging .
Mailing list commentary: Hi , WPACK folks . I ' m   . I am working on Web Packaging in Chromium project . We are thinking about changing the spec of Web Bundles to support relative URLs . Currently , the spec says : https://wpack- ( Section 8.7 of [ I-D.ietf httpbis - semantics ] ) , which holds a URL . This is also known as the representation 's URL And draft - ietf - httpbis - semantics-19 says : It seems the spec already supports relative URLs . But we 'd like to make it clear . So , I created this pull request . Do folks here have any opinions on this change of the pull request ? Thanks .
Paragraph (version A):
Representations within a bundle are named by their "Content-Location"
(Section 8.7 of I-D.ietf-httpbis-semantics), which holds a URL.  This
is also known as the representation's URL.
Paragraph (version B):
Representations within a bundle are named by their "Content-Location"
(Section 8.7 of I-D.ietf-httpbis-semantics).  This is also known as
the representation's URL.  It is either an absolute-URI or a partial-
URI (Section 2.7 of RFC7230).  In the latter case, the referenced URL
is relative to the bundle's URL unless an additional section in the
bundle specifies a different base URL.
Draft: draft-ietf-wpack-bundled-responses

Commentary: This PR removes the manifest section . The motivation is to factor the " core " Web Bundles specification to include just the minimal amount needed to support cases like subresource loading , which does not need a manifest . This and other removed sections can be defined in other documents in the future . Adapted from 
 We might want to make sure the impact of removing manifest section from the bundle format on the chromium . Does  have any usages of manifest section ? It seems does n't use it , however , I am wondering whether there is existing use case for that , I am not aware of . 
 I never really understood the motivation of this section , since the primary URL response can contain a header pointing to the manifest . 
 Imagine the situation of application distribution , it is very useful to have a manifest section . For example , we can display the application icon without parsing the HTML of the primary URL . But I agree that the manifest section can be outside the scope of the " core " bundle specification . So removing it from the core spec looks good to me . 
 LGTM ( just for record ) . Thanks for working on this .
Paragraph (version A):
The "manifest" section records a single URL identifying the manifest
of the bundle.  The URL MUST refer to a resource with representations
contained in the bundle itself.
Paragraph (version A):
The bundle can contain multiple representations at this URL, and the
client is expected to content-negotiate for the best one.  For
example, a client might select the one matching an "accept" header of
"application/manifest+json" (appmanifest) and an "accept-language"
header of "es-419".
Paragraph (version A):
If the bundle's contained URLs (e.g. in the manifest and index)
are derived from the request for the bundle, percent-encode [1]
(URL) any bytes that are greater than 0x7E or are not URL code
points [2] (URL) in these URLs.  It is particularly important
to make sure no unescaped nulls (0x00) or angle brackets (0x3C
and 0x3E) appear.
Paragraph (version B):
If the bundle's contained URLs (e.g. in the index) are derived
from the request for the bundle, percent-encode [1] (URL) any
bytes that are greater than 0x7E or are not URL code points [2]
(URL) in these URLs.  It is particularly important to make sure
no unescaped nulls (0x00) or angle brackets (0x3C and 0x3E)
appear.
Draft: draft-ietf-wpack-bundled-responses

Commentary: Closes WICG / webpackage . This is transferred from WICG / webpackage . 
 The WG hummed in favor of this direction at IETF 110 :
Paragraph (version A):
Web bundles provide a way to bundle up groups of HTTP responses, with
the request URLs and content negotiation that produced them, to
transmit or store together.  They can include multiple top-level
resources with one identified as the default by a primaryUrl
metadata, provide random access to their component exchanges, and
efficiently store 8-bit resources.
Paragraph (version B):
Web bundles provide a way to bundle up groups of HTTP responses, with
the request URLs and content negotiation that produced them, to
transmit or store together.  They can include multiple top-level
resources, provide random access to their component exchanges, and
efficiently store 8-bit resources.
Paragraph (version A):
The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII
"1" followed by 3 0s) for this version of bundles.  If the recipient
doesn't support the version in this field, it MUST either ignore the
bundle or fetch and use the content of the "primary-url" field
instead.
Paragraph (version A):
The "primary-url" field identifies both a fallback when the recipient
doesn't understand the bundle and a default resource inside the
bundle to use when the recipient doesn't have more specific
instructions.  This field MAY be an empty string, although protocols
using bundles MAY themselves forbid that empty value.
Paragraph (version B):
The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII
"1" followed by 3 0s) for this version of bundles.  If the recipient
doesn't support the version in this field, it MUST ignore the bundle.
Paragraph (version B):
The "primary" section records a single URL identifying the primary
URL of the bundle.  The URL MUST refer to a resource with
representations contained in the bundle itself.