Subject: pack200-gzip Content Coding

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Apr 2010 15:25:20 +0200

Hi,

I was looking at the content coding IANA registry 
(<http://www.iana.org/assignments/http-parameters>) and decided to see 
what pack200-gzip:

> pack200-gzip   Network Transfer Format for Java Archives           [JSR200]

is about.

 From what I understand this is a format similar to ZIP/Jar, in which 
you have a directory structure with named entries. How exactly is this 
supposed to work as HTTP Content Coding then?

Has anybody seen this in the wild? Is anybody aware of implementations?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Apr 2010 13:17:57 +1000

Hmm, IETF doesn't appear to have a liaison with the JCP. 

I did find this:
  http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html

... where it's pretty clear this is an abuse of Accept-Encoding. I'd hazard a guess that it's deployed somewhat; can some of the more Java-minded people on the list ask around, please?

To me, this seems like a good argument for a slightly higher bar in this registry... and I'm sorely tempted to try to remove this entry, or at least deprecate it, if it's already deployed.

On 08/04/2010, at 11:25 PM, Julian Reschke wrote:

> Hi,
> 
> I was looking at the content coding IANA registry (<http://www.iana.org/assignments/http-parameters>) and decided to see what pack200-gzip:
> 
> From what I understand this is a format similar to ZIP/Jar, in which you have a directory structure with named entries. How exactly is this supposed to work as HTTP Content Coding then?
> 

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Apr 2010 09:55:05 +0200

> Hmm, IETF doesn't appear to have a liaison with the JCP.

cc'ing David Nuescheler who might know.

> ... where it's pretty clear this is an abuse of Accept-Encoding. I'd hazard a guess that it's deployed somewhat; can some of the more Java-minded people on the list ask around, please?

In the meantime I saw this as well.

It appears to be used by Java Webstart, but really should have been a 
media type as far as I can tell.

> To me, this seems like a good argument for a slightly higher bar in this registry... and I'm sorely tempted to try to remove this entry, or at least deprecate it, if it's already deployed.

We already changed the requirements (or actually stated them for the 
first time) to "specification and expert review" - I think that would 
have prevented this.

Best regards, Julian

---

From: David Nuescheler <[email-masked]>
Date: Fri, 09 Apr 2010 10:37:24 +0000

Hi guys,

thanks for including me on this conversation.

To be honest this is the first time that really read into the details
of the Java Web Start
implementation. Looks very ugly indeed. I agree that a media type
would have been
the right solution.  Too bad that nobody involved in the respective
JSR in the JCP
seems to have noticed :(

My gauge at the deployment of JWS is that it is not very heavily deployed.

Since we had the luxury and benefit of having Julian and others to effectively
work as the HTTP-Police (or Liaison) on our JSRs, I am more than happy to
return the favor and ask around in the JCP who would be the right person to
talk to...

I will keep you posted...

regards,
david

On Fri, Apr 9, 2010 at 9:55 AM, Julian Reschke <[email-masked]> wrote:
>> ... where it's pretty clear this is an abuse of Accept-Encoding. I'd
>> hazard a guess that it's deployed somewhat; can some of the more Java-minded
>> people on the list ask around, please?
>
> It appears to be used by Java Webstart, but really should have been a media
> type as far as I can tell.
>
>> To me, this seems like a good argument for a slightly higher bar in this
>> registry... and I'm sorely tempted to try to remove this entry, or at least
>> deprecate it, if it's already deployed.
>
> We already changed the requirements (or actually stated them for the first
> time) to "specification and expert review" - I think that would have
> prevented this.
>
> Best regards, Julian
>
>

-- 
David Nuescheler
Chief Technology Officer
mailto: [email-masked]

web:  http://www.day.com/ http://dev.day.com
twitter: @daysoftware

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 9 Apr 2010 09:40:31 -0500

> ... where it's pretty clear this is an abuse of Accept-Encoding. I'd
hazard a guess
> that it's deployed somewhat; can some of the more Java-minded people on
the
> list ask around, please?

> To me, this seems like a good argument for a slightly higher bar in this
registry...
> and I'm sorely tempted to try to remove this entry, or at least deprecate
it, if it's
> already deployed.

Of course it is deployed and being used regularly. Anybody that uses
WebStart should probably be using it, in fact. The encoding will only be
applied to content of application/java-archive. It won't be applied to other
content-types--in fact, for most content-types, it cannot be applied. So,
there is no chance for things to go wrong.

The only important requirement for a content-encoding is that there must be
some function that maps any correctly-encoded entity into an unencoded
entity. It isn't necessary to require that every content-encoding be able to
transform any entity into an encoded entity; in particular, it isn't useful
to require content-encodings to work for any/all content-types.

The binary encodings of XML are a good example. If you were to make
binary-encoded XML a content type instead of a content-encoding, then you
would need new content-types for binary-encoded Atom, binary-encoded XHTML,
binary-encoded SOAP, etc. 

Regards,
Brian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 10 Apr 2010 12:25:21 +0200

On 09.04.2010 16:40, Brian Smith wrote:
> ...
> ...

Understood. I misread the documentation; for some reason I read it to 
define something *like* a JAR-like archiving format, although it's 
really a way to post-process those.

My now hopefully correct understanding is that you pack200 the JAR file, 
then gzip the result, so the wrapping is like that

   gzip(pack200(JAR))

So pack200 is a compression that will work for JAR files (also ZIP?).

What I'm still not sure about is why they defined pack200-gzip, instead 
of just pack200 -- is there a concern that Content-Codings can't be 
nested? (This is the reason why content codings should get expert review 
and discussion on a public mailing list).

The other concern is that content codings are harder to deploy then new 
media types (IMHO), and thus it's not entirely clear why having a 
content coding that works with exactly one format is a good idea (as 
compared to just define a proper media type).

> binary-encoded SOAP, etc.

That's indeed a good example, and, as a matter of fact, many have argued 
that new media types would have been better. But in this case, it was 
arguably *easier* to just define a new content coding (as compared to 
many new types).

Best regards, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Sat, 10 Apr 2010 08:10:55 -0500

Julian Reschke wrote:
> What I'm still not sure about is why they defined pack200-gzip, instead of
just
> pack200 -- is there a concern that Content-Codings can't be nested? (This
is the
> reason why content codings should get expert review and discussion on a
public
> mailing list).
media
> types (IMHO), and thus it's not entirely clear why having a content coding
that
> works with exactly one format is a good idea (as compared to just define a
> proper media type).

I agree with you. But, I think the pack200-gzip registration is rather
benign. Deprecating/removing pack200-gzip's registration does more harm than
good.

Regards,
Brian