Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 327: Dynamic Contents Delivery Service API for JavaTM ME

This JSR has been Dormant
Reason: The Executive Committee voted to list this JSR as dormant in September 2012.

Updates to the Original JSR

The following information has been updated from the original proposal:

2.15 Please provide your transparency plan here.

The public can read which Members are on the Expert Group.
The Expert Group business is regularly reported on a publicly readable alias: http://wiki.jcp.org/boards/index.php?b=jsr-327-public
The schedule for the JSR is publicly available, it's current, and I update it regularly.
The public can read/write to a discussion forum or wiki for my JSR: http://wiki.jcp.org/boards/index.php?b=jsr-327-public
The public can write to an alias with feedback and comments on my JSR: http://wiki.jcp.org/boards/index.php?b=jsr-327-public
There is an issue-tracker for my JSR that the public can read: http://wiki.jcp.org/boards/index.php?b=jsr-327-public
I have spoken at conferences and events about my JSR recently. I am using open-source processes for the development of the RI and/or TCK.
- I am using open-source processes for the development of the RI and/or TCK.
- The Community Update page for my JSR has links to and information about all public communication mechanisms and sites for the development of the JSR The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR.

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

For the specification, we will use the standard final specification license

For the Final RI:
JSR327-License-for-RI.doc
For the Technology in source code form we will charge a one-time access fee, and an annual maintenance fee. Maintenance covers bug fixes, updates and new releases necessary due to specification changes, and when made generally available by the specification lead. The Technology in binary code form will be provided free of charge.

For the final TCK:
JSR327-License-for-TCK.
The TCK and the Technology may be licensed separately. For the TCK we will charge a single one-time fee of max US$50,000 and an annual maintenance fee, max US$20,000/year for a term of three years. The TCK will include both the binary environment and the source code for the test suite. The maintenance fee covers limited basic support, first level TCK appeals process, bug fixes when available and updates, which are due to changes in the Specification. Major new releases (esp. from new follower JSR) might be subject to an additional single one-time fee.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: SK Telecom

Name of Contact Person: Dave Kim

E-Mail Address: dave_kim@sktelecom.com

Telephone Number: +82-10-3772-8896

Fax Number: +82-2-6100-7907


Specification Lead: Dave Kim

E-Mail Address: dave_kim@sktelecom.com

Telephone Number: +82-10-3772-8896

Fax Number: +82-2-6100-7907


Initial Expert Group Membership:

AT&T
Orange
SUN
LG Electronics
Aromasoft

Supporting this JSR:

AT&T
Orange
SUN
LG Electronics



Section 2: Request

2.1 Please describe the proposed Specification:

Java ME platform offers network enabled services on the user?s device. Although push based content delivery has been in existence in one form or another with varying scopes, content delivery method is mainly based on pull mechanism, where this too is individually implemented using custom methods. Therefore, Java platform needs to provide standard way for application to interact with content delivery mechanism ? OMA DCD based or proprietary DCD mechanisms. The proposed JSR is an optional package for Java ME enabled device to provide:
(1) Push based content delivery with facilitation for periodic delivery of personalized or customized contents
(2) Uniform delivery mechanism for various network enabled Java applications regardless of data types and format.
(3) Single point-to-point channel and/or broadcast communication for network enabled applications with currently available data transfer protocols such as HTTP/HTTPS/SMS.
The proposed JSR will provide generic interface to DCD client existing in user?s device.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java platform for embedded devices

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The minimum is the Java ME CLDC 1.1. This optional package should be usable with any Profiles associated with CLDC, such as MIDP and IMP. The package should also run on Java ME CDC, and usable with any associated Profiles.

2.4 Should this JSR be voted on by both Executive Committees?

No.

2.5 What need of the Java community will be addressed by the proposed specification?

Java applications to have standardized interface to DCD client will augment the application portability and OTA download ability of the Java ME platform. Also, with introduction of MIDP 3.0, the improvements in presence and exposure of Java applications will be complimented.

2.6 Why isn't this need met by existing specifications?

The existing Java ME specifications do not provide specific support for OMA DCD or other DCD specifications.

2.7 Please give a short description of the underlying technology or technologies:

The Dynamic Content Delivery (DCD) enables periodic delivery of personalised or customized content either on a one-to-one (point-to-point) or one-to-many (broadcast) basis. One of such prominent DCD specifications is OMA DCD1.0. OMA DCD addresses various technical aspects of this mechanism by providing a generic client framework, content delivery and subscriptions, DCD envelop mechanism. The proposed JSR is to use the push mechanism to send all the required data content of the applications or services that have been subscribed by the users. The interfaces provided by the proposed JSR will include:

  1. Service subscription and management
    - Managing specific services from DCD server: registering, deregistering, services listing
    - User account authentication
  2. Exchange of content and storage access
    - Access attributes of content metadata
    - Access contents from DCD client or in local storage
    - Direct access to contents in the server
    - Handling events associated with content distribution channels and push
  3. Personalization and customization
    - Service channel selection and scheduling methods
    - Content storage management
    - Content distribution method associated with roaming and/or location of device

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

?javax.microedition.dcd?

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

None.

2.10 Are there any security issues that cannot be addressed by the current security model?

No.

2.11 Are there any internationalization or localization issues?

Support for a sufficient set of character encodings might be required. One of main reason is that there are some cases which the user need to use many different mobile applications from many different content providers which have different language character set.

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

None.

2.13 Please describe the anticipated schedule for the development of this specification.

The targeted schedule for the JSR is as follows:
Expert Group Formation: September 2008
Early Draft Review: February 2009
Public Review: June 2009
Proposed Final Draft: September 2009
Final Approval Ballot: November 2009

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

The working interactions will be primarily email communications, with occasional teleconferences/video conferences whenever required. Face-to-face meetings to solve issues which require a quick input and solution will be held, and all involved entities will be notified as appropriate. For EG gathering covenience, co-locating with OMA meeting is considered.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The transparency plan is:
a) JSR community page is used to provide the community with regular updates of the draft specifications and information about the current topics and issues of the Expert Group.
b) A mail alias is maintained for the JCP members who are outside of the Expert Group but requested the mail notification of the progress of the EG activities. Periodic milestone draft specifications and status are published to this list. The Expert Group may also use the list to request feedback on key issues facing the group.
c) Specification Lead will be available to reply and/or answer any inquiry related to this specification.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Standalone RI and TCK will be delivered as part of this JSR.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

These are initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by SK Telecom at its sole discretion. - The specification will be publicly available if interest party uses this JSR specification for research, evaluation, and development with royalty free and fully paid-up licenses.
- Independent implementations will be allowed.
- RI and TCK will be licensed separately.
- For the TCK, we will charge a single one-time fee capped at $50,000 and an annual maintenance fee capped at $20,000 for a term of four years. The TCK will include both binary environment and source code for test suite. The maintenance fee covers limited basic support: first level TCK appeals process, bug fixes when available, and updates which are due to changes in the Specification. Major new releases (esp. follower JSR) may be subject to an additional single one-time fee.
- For the RI in source code form, we will charge a one-time access fee, and an annual maintenance fee. The maintenance covers bug fixes, updates and new releases necessary due to spec changes.





Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Open Mobile Alliance Specifications for Dynamic Content Delivery (DCD) version 1.0 (http://www.openmobilealliance.org/Technical/cd.aspx)

3.2 Explanation of how these items might be used as a starting point for the work.

The OMA standards for DCD will be used to bring up the concept of this JSR. The OMA Specifications will be referred to for designing this JSR.