W3C home > Mailing lists > Public > www-tag@w3.org > February 2014

Re: Packaging on the Web

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sun, 2 Feb 2014 20:37:32 +0000
To: Noah Mendelsohn <nrm@arcanedomain.com>, Alex Russell <slightlyoff@google.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <etPan.52eeac8c.725a06fb.1795@jenit.local>

I think you misinterpreted me. I was suggesting a design in which the boundary was variable from one package to another (and thus could be chosen to avoid its appearance within the content) but that it appeared as the very first thing in the file, which would mean it could be detected rather than having to be defined within a Content-Type header.

For example, if the package started with:


then a recipient could guess that the boundary was `some-random-boundary`, but if the package started with:


then a recipient could guess that the boundary was `another-random-boundary`.

Jeni Tennison

From: Noah Mendelsohn nrm@arcanedomain.com
Reply: Noah Mendelsohn nrm@arcanedomain.com
Date: 2 February 2014 at 18:16:18
To: Jeni Tennison jeni@jenitennison.com, Alex Russell slightlyoff@google.com
Subject:  Re: Packaging on the Web

> On 2/2/2014 12:36 PM, Jeni Tennison wrote:
> > A new type that had the same syntax as a multipart type but had  
> a sniffable boundary (ie started with --boundary) might be better  
> than using a multipart/* content type.
> Doesn't this raise the obvious question about escaping content  
> that happens
> to have the fixed marker? I don't love the lookahead requirement  
> implied in
> encoding arbitrary content for multipart-mime, but at least  
> it works with
> most any content, and in many case one knows in advance from the  
> type of
> the content which markers will be OK.
> This is a sufficiently obvious concern that I suspect you've  
> got a good
> (and perhaps equally obvious) answer ready. I.e. I know I'm probably  
> just
> missing something about the use cases.
> Noah
Received on Sunday, 2 February 2014 20:38:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:01 UTC