Re: Packaging on the Web specification

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