Name: rlT66838 Date: 02/07/2000
The new Jar File Specification allows a Content-Type specification per entry
(http://java.sun.com/products/jdk/1.3/docs/guide/jar/jar.html#Per-Entry
Attributes) but the brief description of the syntax could be interpreted
contrary to RFC2045 section 5, which defines the syntax of a Content-Type.
(ftp://ftp.isi.edu/in-notes/rfc2045.txt)
The most important problem is that the jar spec omits any mention of parameters,
which can be required information for some media types, as stated in RFC2045.
Even where not required, parameters can be important, as the charset parameter
for text types, considering that Java seeks to address internationalization.
Other problems are that the true Content-Type syntax inherits the RFC822 rules
for comments, quoting, and white space, and an implementation that ignores
those rules can fail to parse legitimate content types.
To fix: the Jar File Specification should be revised so that the Content-Type
syntax is defined by a reference to the defining RFC, to avoid the development
of conflicting interpretations of Content-Type syntax. The impact of the
specification correction should be minimal, as vendors' class libraries likely
include compliant RFC822 parsing code somewhere anyway. The best time to
amend the specification, of course, will be before too many conflicting
implementations have been derived from it.
(Review ID: 100506)
======================================================================
The new Jar File Specification allows a Content-Type specification per entry
(http://java.sun.com/products/jdk/1.3/docs/guide/jar/jar.html#Per-Entry
Attributes) but the brief description of the syntax could be interpreted
contrary to RFC2045 section 5, which defines the syntax of a Content-Type.
(ftp://ftp.isi.edu/in-notes/rfc2045.txt)
The most important problem is that the jar spec omits any mention of parameters,
which can be required information for some media types, as stated in RFC2045.
Even where not required, parameters can be important, as the charset parameter
for text types, considering that Java seeks to address internationalization.
Other problems are that the true Content-Type syntax inherits the RFC822 rules
for comments, quoting, and white space, and an implementation that ignores
those rules can fail to parse legitimate content types.
To fix: the Jar File Specification should be revised so that the Content-Type
syntax is defined by a reference to the defining RFC, to avoid the development
of conflicting interpretations of Content-Type syntax. The impact of the
specification correction should be minimal, as vendors' class libraries likely
include compliant RFC822 parsing code somewhere anyway. The best time to
amend the specification, of course, will be before too many conflicting
implementations have been derived from it.
(Review ID: 100506)
======================================================================