Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

This is the proposed change log for a Maintenance Review of JSR-056 version 6.0.

The proposed new version number will be 6.0.10

Change 1 - bump the specification version number to 6.0.10

In The title page (index.html) replace (in 2 places):

Version 6.0

with:

Version 6.0.10

Change 2 - add this revision history to section 0.7:

Add section 0.7.4 as follows:

0.7.4 Changes since release 6.0

This is a minor update of the version 6.0 specification. The change are described below:

Modify section 5.5 to allow untrusted content to include untrusted (as well as trusted) extensions from any host. (no longer restrict to the download host).
Modify section 3.7 to allow implementations to implement a subset of the descriptor types.
Modify section 3.7.2 to allow implementation to override jnlp applet parameters, and use relative codebases.
Modify section 5.5 yo allow implementation to optionally allow exitVM permission depending on model.
Modify Appendix C, the DTD,to fix existing typos and inconsistancys.

This revision introduces the version number (6.0.10) for the JNLP file and the JNLP API. Version 6.0.10 is a proper superset of 1.0, and of version 6.0. A JNLP Client implementing this specification must be able to run a JNLP file which requires 1.0, 1.5, 6.0, or 6.10; i.e., the spec attribute in the jnlp element is set to any of 1.0, 1.5, 6.0, or 6.0.10.

A complete list of changes for v6.0.10 can be found at:

{include URL to where this change log is posted on jcp.org}

Change 3 - Allowing untrusted content to include untrusted (as well as trusted) extensions from any host.

In Section 5.5, replace the following text:

Extensions: The JNLP file can request extensions and JREs from any host. An application cannot make a socket connection back to any of the hosts where JREs or extensions are downloaded from (unless it happens to be the same host as for the JAR files). Extensions requested from hosts other than the one that the JAR files were downloaded from must be signed and trusted as per section 5.4.

with:

Extensions: The JNLP file can request extensions and JREs from any host. Permissions are granted to downloaded code based on its origin as well as its signing and trust. Unsigned and untrusted code, whether in the application or an extension, may only make a socket connection back to the host from which it originated, according to the Java Security Architecture.

Change 4 - Allowing implementations to implement a subset of Descriptor types.

Replace section 3.7 with:

3.7 Application Descriptors

Each jnlp file must contain one of the 4 descriptor types: "application-desc", "applet-desc", "component-desc", or "installer-desc" which are described below. Descriptors of type "application-desc" or "applet-desc" are collectively referred to as Application Descriptors. Descriptors of type "component-desc" or "installer-desc" are collectively referred to as Extension Descriptors.

A JNLP client may optionally implement any subset of Descriptor types, except that at least one Application Descriptor type must be implemented. For example, a helper application might implement all 4 types, while an implementation of a Java Plug-in may choose not to implement "application-desc", implementing only the other three.

also, in section 1.5 replace: "Applications launched with JNLP do not run inside a browser window, but instead are separate applications ..." with: "Applications launched with JNLP need not run inside a browser window, but instead can be separate applications ..."

Change 5 - Allowing implementation to override jnlp applet parameters, and use relative codebases.

in section 3.7.2:

replace:

"The documentbase is provided explicitly since an applet launched with a JNLP Client is not embedded in a Web page."

with:

"The documentbase can be provided explicitly since an applet launched with a JNLP Client may not be embedded in a Web page."

and add at end of 3.7.2, (before the last line):

The JNLP Client may override the applet parameters, or complete a relative codebase, by using information available in its environment. For example, a JNLP Client that is implemented as a browser plugin can complete a relative codebase using the address of the page the applet is on, or override applet parameters with applet parameters specified on the page.

Change 6 - Allowing permission to optionally allow exitVM permission depending on model.

In section 5.5, replace the following:

Security Manager: The application must run with a SecurityManager installer. The following table lists the exact set of permissions thast must be granted to the applications resources:

with:

Security Manager: The application must run with a SecurityManager installed. The following table lists the set of permissions that must be granted to the applications resources. Other permissions can only be granted if deemed secure by the JNLP Client. The permissions that must be granted are:

also, remove the table items for exitVM, and stopThread, and add the following at the end of section 5.5:

Environment: A JNLP Client may allow untrusted code other permissions appropriate to the environment. For example, a JNLP Client that implements multiple applications/applets in one JVM session will not allow exitVM permission, while one that enforces one separate JVM instance per application/applet could.

Change 7 - Fixing typos in the dtd in Appendix C.

in C.1:

replace:

<!DOCTYPE jnlp PUBLIC "-//Sun Microsystems, Inc//DTD JNLP Descriptor 6.0//EN">

with:

<!DOCTYPE jnlp PUBLIC "-//Sun Microsystems, Inc//DTD JNLP Descriptor 6.10//EN" "http://java.sun.com/dtd/JNLP-6.10.dtd">

in C.2:

replace:

<!ELEMENT information (title?, vendor?, homepage?, description*, icon*,offline-allowed?, shortcut?, association?, related-content*)>

with:

<!ELEMENT information (title, vendor, homepage?, description*, icon*, offline-allowed?, shortcut?, association*, related-content*)>

replace:

<!ELEMENT update>

with:

<!ELEMENT update EMPTY>