Internet DRAFT - draft-guo-idoca-with-the-html-file-format
draft-guo-idoca-with-the-html-file-format
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
