Internet-Draft Zh. Guo Applications Area Working Group Biaoma IT Intended status: Standards Track March 22, 2013 Expires: September 23, 2013 The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format draft-guo-idoca-with-the-html-file-format-00 Abstract At present, the collaboration of documents in a single cloud-office Website works wonderfully. However, the one among different cloud- office websites is a little clumsy. This document analyzes the status quo of the collaboration of documents among those existing different cloud-office websites and provides a solution how to realize IDCOA (the interconnection and interoperability of different cloud-office applications) with the html file format. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. The list of current Internet-Draft is at http://datatracker.ietf.org/draft/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 23, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD license text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD license. 1. Introduction In the market of telecommunications, the interconnection of voice calling and messaging applications has been realized among different operators or different information platforms and it was the interconnection among the three major telecommunications operators in USA in 2005 that led the vigorous development of SMS (short messaging service) among them. According to OSI/RM (Open System Interconnection Reference Model) and TCP/IP reference model, the more lower or basic the layer of the applications is, the more the demand of the interconnection among them is. Reed's Law in the field of the Internet shows that the value of the telecommunications network is proportional to the exponential function of the number of users. The interconnection of different IM (instant messaging) applications in the market of value added services of telecommunications is only partially realized because IM is only used for informal communication. The interconnection among different office applications was realized in the field of the formal business communication. The traditional editing tools of office documents are office applications, and the means of the interconnection (transmission) are email, IM, sharing in social networking website or in LAN (local area network), and U disk. It is thought that the interoperability of different office applications includes two aspects. One is that a document can be surely opened. The other is that it can be surely reedited. The traditional file formats of office documents are mainly xml-based ODF (Open Document Format), OOXML (Office Open Extensible Markup Language) and PDF. In order to deal with the users' needs, the authority of the interoperability of traditional office documents is ISO/IEC JTC1/SC34. Because of the rapid development of web technology, a large number of traditional applications were moved onto the Internet in recent ten years, which hastened the births of many cloud-office websites. With Html5 and WebSocket being protocols, those cloud-office applications have successfully implemented the functions of editing html-based documents such as word, spreadsheets, PowerPoint and pictures, uploading and downloading documents between a cloud-office website and local computer, and converting file formats. Besides, they have also integrated the sending function of email, IM, and SNS (social networking) into their cloud-office websites. (However the receiving function of these traditional communications has yet been integrated into them.) Fig.1 shows the transmission of documents between the cloud-office website 1 and the local office. Cloud-office 1 Cloud-office 2 +---------------+ +----------------+ | | Interconnection | | | <---|-------------------|---> | | | Interoperabillity | | +----/|\--------+ +----------------+ | Uploading and Downloading | Local office +----\|/------------------------------------+ | | | On-premises office softweare | | Email, IM, and SNS | +-------------------------------------------+ fig.1 the transmission of documents between the cloud-office website 1 and the local computer As far as the transmission of the shared information is concerned, those cloud-office applications work very well on those documents sharing among different users within a single cloud-office website. This is a way of authority control that saves the storage space the most. Fig.2 shows the relation between two users A and B of a single cloud-office website. Cloud-office +----------------+ | | | A <------> B | | | +----------------+ Fig. 2 The relation between two users A and B of a single cloud- office website. Thanks to the document-calling API provided by part of those cloud- office provided, a single user with different accounts on different websites, respectively, can implement a one-way transmission when he need call some documents from one website to the other. In this way, two websites both use the common transport protocol of https and the html file format. Fig. 3 shows how the document-calling API works. Cloud-office 1 Cloud-office 2 +--------------+ +--------------+ | | Html |1's API | | A ------|---------|--------> A | | | Https | | +--------------+ +--------------+ Fig.3 How the document-calling API works As for the document transmission between two different users from two different cloud-office website, respectively, there are now two ways to implement. One is that a user of a website sends an online document as an attachment to another user of a different website by email, then the recipient has to open his mailbox, selects reading online, and then selects saving it into his own folder on his cloud- office website, which completes the document transmission between two different users from two different cloud-office website, respectively. In this way, both websites also adopt SMTP and the html file format. Fig. 4 shows the transmission of a document worth saving. Cloud-office 1 A's email B's email Cloud-office 2 +---------+ +-------------+ +-------------+ +-----------+ | A's |Upload| |Html| |Save| B's | |Documents|------|->Attachments|----|->Attachments|----|->Documents| | | | |SMTP| | | | +---------+ +-------------+ +-------------+ +-----------+ Fig. 4 The transmission of documents worth saving by email with attachments The other is that, after the recipient receives an email in which body a temporary user name and a password are added to the URL of an online office document, he is able to log on his own email, click on the link, temporarily log on the sender's cloud-office website, and then read this document. This way is the most close to the one of document-sharing within a single website. In this way, however, there is now no way to identify whether the click comes from the designated mailbox, let alone the so-called identity authentication, which bring a result that many people can read this document once the email is forwarded. For some cloud-office website, a user can read a relevant document only if he registers in or logs on with a permanent account, which will result in the loss of customers of the other website. Therefore, no cloud-office website owner likes this kind of document sharing. There is, however, no such concern with the way of adding a temporary user name and a password to the mentioned URL. Fig. 5 shows the transmission of a document by email with a URL of the document, a temporary user name, and a password in the body. Browser +--------------------------------------------+ A's cloud-office | A's email B's | email +----------------|--+ +-------+ +---|---+ | \|/ | URL+a password | | | | | | A----------->A'-|----------------------|->Body-|------|->Body | | |+a temporary user name| | SMPT | | | | | | | | +-------------------+ +-------+ +-------+ Fig. 5 The tansmission of a document by email with a URL of the document, a temporary user name, and a password in the body In all, there definitely exist needs of the information communication and the document transmission among different users of different cloud-office websites, respectively. The IDCOA are defined as that the users of different cloud-office websites have the same experience of the document collaboration as the ones of a single cloud-office website. The experience includes transmitting, reading, reediting, and commenting documents. However, all of those existing methods are not two-way, direct, or immediate, so the IDCOA do not really come true, which make each cloud-office website become a separate island of information. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Textual Conventions This document is designed with basis on the following commonsense: 3.1 Browsing documents on webpage is safer than downloading them to the local computer. 3.2 There is no way to completely eliminate the spam but we can minimize its number and capacity. 3.3 Nearly twenty-year group wrestling between ODF and OOXML shows that it is impossible for their respective editors of different manufacturers to completely implement the interoperability of documents. We think that the interoperability of documents is affected by operating systems, browsers, markup languages, file formats and manufactures. Therefore, we SHOULD do our best to avoid using different editor to deal with the same document. 3.4 At present, documents have not been sent with html file format mainly because the other cloud-office application cannot identify what kind of document has been sent. (That is, is it a word document, an excel document, a PowerPoit document, or a picture?) 4. Solutions 4.1 Websocket is adopted to send the recipient the URL of a document with a temporary user name and a password added to it. Oauth2.0 is adopted to authenticate that the temporary user is the same as the recipient. The authorized recipient can click on the link, temporarily log on the sender's website, and then read and collaborate the designated document. Fig. 6 shows the process of this kind of document collaboration. Browser +--------------------------------------------------+ | | +-------|----+ +-----|-------+ | \|/ | URL, Temporary user name and password | | | | A---->A'<--|---------------------------------------|---->B | | | WebSocket, Oauth2.0 | | +------------+ +-------------+ Fig. 6 The process of the collabboration of a document. 4.2 The recipient have an option that the html document designated by the sender is transmitted by WebSocket and saved to the recipient's own cloud-office website. This operation makes the document keep on file. For the life cycle of a document, making a document on file is very helpful with searching and reprocessing the document. However, it takes up more storage space on the recipient's website. Fig. 7 shows the process of saving a document. +-------------+ +-------------+ | | Html | | | A ------|--------------------|-----> B | | | WebSocket | | +-------------+ +-------------+ Fig. 7 The process of saving a document. 4.3 For the document file format that cannot be opened online, the whole document is sent by adopting https or Websocket. The recipient can choose to download the document to the local computer or use converter to make an online conversion. Fig. 8 shows the transmission of this kind of documents. +------------+ +------------+ | | ODF, OOXML, PDF | | | A <----|---------------------|-----> B | | | WebSocket | | +------------+ +------------+ Fig. 8 The transmission of documents that cannot be opened online 5. Security Considerations This document provides some solutions to IDCOA. In these solutions, some security issues must be considered. IDCOA MUST deal with "the three S's": stalking, spoofing, and spam. In particular, the document sender's identification MUST be authenticated. One sender MUST be prohibited forging the others' feature information such as the sender, the mail routing, etc. Even if the sender uses the anonymous forwarding, the open relay or the open proxy, he cannot erase the document sender's feature. 6. IANA Considerations Some MIME types should be registered, such as html-based document files, spreadsheet files, and PowerPoint files. 7. Conclusion This document has provided some solutions to IDCOA. The purpose of these solutions is to provide a common mean to implement IDCOA. 8. Acknowledgements This document has been improved by rearrangements and comments from Kun Yang and Yanli Lu. The author gratefully acknowledge their assistance. 9. References 9.1. Normative References [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BFC 14, RFC 2119, March 1997. 9.2. Informative References 10. Author's Addresses Zhun Guo Shanghai Biaoma IT Shanghai 200062 China Phone: +86 400 101 1853 Email: mike5guo@gmail.com