 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 327: Dynamic Contents Delivery Service API for JavaTM ME
JCP version in use: 2.7 Java Specification Participation Agreement version in use: 2.0 Description: This JSR will enable Java application to interact with dynamic content delivery (DCD) client implementation in user's device. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Dormant
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.
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:
For the final TCK: 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 Telephone Number: +82-10-3772-8896 Fax Number: +82-2-6100-7907 Specification Lead: Dave Kim E-Mail Address: dave_kim Telephone Number: +82-10-3772-8896 Fax Number: +82-2-6100-7907 Initial Expert Group Membership:
AT&T Supporting this JSR: AT&T 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: 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:
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: 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: 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. 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
