 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 332: Email Client API for JavaTM ME
This JSR has been Dormant
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Samsung Name of Contact Person: Gandhi Kishor Addanki E-Mail Address: kishor.ag Telephone Number: +91 99863 61636 Fax Number: +91 80 41819000 Specification Lead: Gandhi Kishor Addanki, Lakshmi Narayana Thummala E-Mail Address: kishor.ag Telephone Number: +91 99863 61636, +91 98455 24316 Fax Number: +91 80 41819000 Initial Expert Group Membership: Aplix Corporation Supporting this JSR: Aplix Corporation Section 2: Request
2.1 Please describe the proposed Specification:Email Client API JSR will be an optional package for Java ME. This JSR provides the APIs for Email Client which deals with sending and receiving emails totally or partially, handling email events, configuring various user settings and filtering rules for sending/receiving the emails. This JSR also provides APIs for security like secure Email session, Message encryption/decryption etc.., The specification deals with the following:
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)This JSR is targeted for embedded devices. The minimum required configuration is Connected Limited Device Configuration v1.0 or Connected Device Configuration v1.0, but not limited to only these. 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.This API targets Java ME. 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?This specification exposes high level Java ME API for application developer to access email services. In addition to providing standard email services, it also deals with providing extended email services like Forward without download, Reply without download, estimated email download time, Auto Reply, etc. 2.6 Why isn't this need met by existing specifications?JSR120 (Wireless Messaging API) is for short text message services between mobiles. JSR205 (Wireless Messaging API 2.0) is for multimedia enabled message services between mobiles. JSR266 (Unified Message Box API) provides access to already existing message boxes on a device. JSR266 shall use Email JSR as an Adaptor for simple send/receive email. JSR919 (JavaMail) is for Java SE and provides standard email services only. It uses JavaBeans Activation Framework (JAF) to interact with Message data. However, Email Client API (EMC) aims at providing email services like email notification, and extended services like forward without download, reply without download etc.., and securely sending the mail. It also allows configuring user settings and filtering rules for emails. Therefore new JSR needs to be filed for the Email Client API (EMC). 2.7 Please give a short description of the underlying technology or technologies:OMA MEM specification standards are used as the baseline for this API. EMC provides mobile user with access to emails. EMC is based on client-server architecture. OMA MEM specification standards are one of the available standards for implementing EMC on the client and the server end and would be used as the baseline reference for developing this API. But the proposed Email Client API JSR would be abstract in nature and hence should work on top of any underlying client-server based standard email software. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.microedtion.email 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 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?No 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.November 2009: EG formed 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.It is anticipated that a combination of email discussion, feedback on regular drafts, conference calls and face-to-face meetings will work well. 2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate.1. The public can read who is on the Expert Group. 2. The Expert Group business is regularly reported on a publicly readable alias. 3. The schedule for the JSR is publicly available, it's current, and I update it regularly. 4. The public can read/write to a discussion forum or wiki for my JSR. 5. The public can write to an alias with feedback and comments on my JSR. 6. The Community Update page for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR 2.16 Please describe how the RI and TCK will be 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 produced as a 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 the full text of the licenses that will apply to your Final Release Specification, Reference Implementation and Technology Compatibility Kit, or provide links to the same.we will license to all interested parties. TCK and RI will be licensed separately. For TCK we will charge a single one time fee of max $50000 USD and an annual maintenance fee, max $20000 USD/pa. TCK will include the binary environment and source code of the test suite. Maintenance fee covers limited basic support, first level TCK appeals process, bug fixes and updates, which are due to changes in the specification, and when made available by the specification lead. Major new releases (esp. follower JSR) might be subject to additional single one time fee. RI in source code form is provided free of cost. 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.The Open Mobile Alliance MEM standards are referred to bring up the basic idea of the JSR. OMA MEM Requirement Document at http://member.openmobilealliance.org/ftp/public_documents/mwg/Permanent_documents/ 3.2 Explanation of how these items might be used as a starting point for the work.The application interfaces provided by native Email Client software will be used as starting point of work. |
