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

Re: Packaging on the Web specification

From: Jan Algermissen <jan.algermissen@nordsc.com>
Date: Sat, 10 May 2014 22:52:41 +0200
Cc: www-tag@w3.org
Message-Id: <37B6163A-C0BC-4AD8-A530-964879BF2FA6@nordsc.com>
To: Jeni Tennison <jeni@jenitennison.com>
Hi Jeni,

thanks for the quick reply!

On 10 May 2014, at 22:30, Jeni Tennison <jeni@jenitennison.com> wrote:

> Hi Jan,
> 
> Note that the editorís draft isnít a standard and application/package hasnít been registered. The spec hasnít even been published as a Working Draft. So implementing around it now would probably be premature in any case!

Yes - however, we are using the media type only, as a somewhat more specific one than multipart/mixed.
> 
> As designed, you can use the Ďpackageí relation with any media type you like, including a multipart type with an explicit boundary parameter. That remains a reasonable thing to do, especially if you are dealing with servers where you are confident that the boundary parameter is easily set in the Content-Type header, and clients that you know will understand it. Those may be completely reasonable assumptions in your application.
> 
> The proposed application/package is a new format that has a similar syntax to a multipart type. It doesnít require the rewriting of every multipart parser. Thereís no redefinition of existing multipart types. Certainly new application/package parsers would have to be written, but thatís usually the case for new formats.

Understood. And I completely understand the reason to drop the mandatory boundary param.

> 
> I donít think the lookahead in application/package is onerous, but I could be wrong. The goal with that particular format is to provide a mechanism for indicating what boundary is being used within the file itself, because in the general case providing that information externally to the file requires configuring HTTP servers in ways that are difficult for many people. Given the lack of a boundary parameter to use, do you have an alternative suggestion for working out the boundary?

No - except for using an HTTP Header like ĎPackage-Part-Boundary:í.

My suggestion was to *add* multipart/package to the spec again so there is an option to use the existing multipart parsers without modification.

multipart/package would have the same semantic as application/package and could be used when the boundary param can actually be added.

Jan

> 
> Cheers,
> 
> Jeni
> 
> ------------------------------------------------------
> From: Jan Algermissen jan.algermissen@nordsc.com
> Reply: Jan Algermissen jan.algermissen@nordsc.com
> Date: 10 May 2014 at 20:48:40
> To: Jeni Tennison jeni@jenitennison.com
> Cc: www-tag@w3.org www-tag@w3.org
> Subject:  Re: Packaging on the Web specification
> 
>> Hi Jeni,
>> 
>> while developing a parser for the packaging format, we stumbled over the renaming of  
>> multipart/package to application/package.
>> 
>> You give the explanation in the note in
>> 
>> http://w3ctag.github.io/packaging-on-the-web/#streamable-package-format  
>> 
>> In the note you write:
>> 
>> "It is also unnecessary as the boundary can be ascertained from the content of the file."  
>> 
>> The problem with this is that every existing multipart parser out there would have to  
>> be rewritten to do the lock-ahead. It seems pretty likely that this hinders adoption.  
>> 
>> Example: Immediate reaction in our project has been: ďNah, letís do our own multipart/package  
>> - I am not willing to rewrite the parserĒ.
>> 
>> Maybe you should consider adding multipart/package (with the required boundary parameter)  
>> back in.
>> 
>> Wouldnít hurt I think.
>> 
>> Jan
>> 
>> 
>> 
>> 
>> 
>> On 06 Apr 2014, at 23:25, Jeni Tennison wrote:
>> 
>>> Hi,
>>> 
>>> Iíve worked up a proper spec for Packaging on the Web, speccing both a format (application/package)  
>> and a link relation (rel=package) and providing some detailed scenarios and examples.  
>>> 
>>> Itís at: http://w3ctag.github.io/packaging-on-the-web/
>>> 
>>> Feedback greatly appreciated. In particular, Yehuda, you said youíd review?
>>> 
>>> Thanks,
>>> 
>>> Jeni
>>> --
>>> Jeni Tennison
>>> http://www.jenitennison.com/
>>> 
>> 
>> 
>> 
>> 
> 
> --  
> Jeni Tennison
> http://www.jenitennison.com/
Received on Saturday, 10 May 2014 20:53:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:25 UTC