One document matched: draft-klyne-qualdoc-goals-02.txt
Differences from draft-klyne-qualdoc-goals-01.txt
Network working group Graham Klyne (editor)
Internet draft Content Technologies
Category: Work-in-progress Richard Shockey
Shockey Consulting LLC
22 October 1999
Expires: April 2000
Additional Goals for Quality Document Transfer
<draft-klyne-qualdoc-goals-02.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract
This document sets out some goals beyond those in "Terminology and
Goals for Internet Fax" [4] for a service to perform fax and high
quality document transmission across the Internet.
Internet fax [1,2] defines a way to send fax data over the Internet
using e-mail. But there is a clear desire for an application that
more closely emulates the operational characteristics of
traditional fax [3].
Klyne & Shockey Work-in-progress [Page 1]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
Table of contents
1. Introduction ............................................2
1.1 Organization of this document 3
1.2 Document conventions 3
1.3 Discussion of this document 3
2. Timeliness characteristics ..............................4
3. Goals for High Quality Document Distribution ............5
3.1 Timely delivery 6
3.2 Proof of delivery/receipt 6
3.3 Date and time information 7
3.4 Quality of output 7
3.5 Sender and receiver identity exchange 7
3.6 Cover page 8
3.7 Interworking with other services 8
4. Other considerations ....................................8
4.1 Third party operation 9
5. Internationalization considerations .....................9
6. Security considerations .................................9
7. Full copyright statement ................................10
8. Acknowledgements ........................................10
9. References ..............................................10
10. Authors' addresses .....................................12
Appendix A: Revision history ...............................13
1. Introduction
The transmission and reception of renderable documents (i.e. in a
form that can control their final rendering) is an essential global
communications service.
Several protocols and services have been developed over the years
to facilitate document transmission, including the GSTN Fax
service, ITU-T T.30 [3].
Within the IETF several protocols have been developed that can be
used for document transmission, including Internet fax [1,2] (using
e-mail protocols) and the Internet Print Protocol [5] (using
elements from HTTP). But there are indications that users expect a
service that more closely emulates the operational characteristics
of traditional fax [3].
This document sets out some goals for such a service.
Klyne & Shockey Work-in-progress [Page 2]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
1.1 Organization of this document
"Terminology and Goals for Internet Fax" [4] is used as a baseline
for these goals; this memo further expands on some issues that
characterize the current practice of facsimile transmission. These
features are intended to facilitate the use of quality document
transfer in compliance with the legal as well as general custom and
practice surrounding document transmission by facsimile.
Section 2 discusses the operational modes for Internet fax, and how
they might relate to user perceptions of timeliness of message
delivery.
Section 3 describes the goals for quality document transfer. It
starts with a brief listing of all the goals, then proceeds to
explain in more detail those that are not described elsewhere.
Section 4 discusses some additional considerations beyond obvious
application goals.
1.2 Document conventions
This memo uses the annotations described in "Terminology and Goals
for Internet Fax" [4] to indicate levels of desirability for a
quality document transfer protocol:
{1} there is general agreement that this is a critical
characteristic of any definition of a quality document
transfer protocol.
{2} most believe that this is an important characteristic of a
quality document transfer protocol.
{3} there is general belief that this is a useful feature of a
quality document transfer protocol, but that other factors
might override; a definition that does not provide this
element is acceptable.
NOTE: Comments like this provide additional nonessential
information about the rationale behind this document, and
may help those who wish to understand the ideas in
greater depth.
1.3 Discussion of this document
Please send comments regarding this document to:
ifx@pwg.org
Klyne & Shockey Work-in-progress [Page 3]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
To subscribe to this list, send a message with the body 'subscribe
ifx' to 'Majordomo@pwg.org'.
To see what has gone on before you subscribed, please see the
mailing list archive at:
http://www.pwg.org/hypermail/ifx
2. Timeliness characteristics
RFC 2542 [4], section 2.5, discusses three operational modes for
Internet fax. These describe different ways of performing message
transfer that typically exhibit different behaviours:
o "Store and forward" is typically associated with delivery times
that may vary between minutes and hours, or even days (e.g.
ordinary Internet mail.)
o "Session" relates to a kind of "while-you-wait" service, where
the length of time one waits may depend on the number of other
users of the same network resources (e.g. accessing a web page).
The intent of "session" mode described in RFC 2542 is to provide
a timely delivery without being constrained by the kind of rigid
protocol timing constraints that are normal when using a circuit
based protocol like T.30.)
o "Real time" means that delivery is completed within some defined
maximum time, or the process is deemed to have failed.
Traditional Group 3 facsimile is a real time service in this
sense. True real time behaviour can be difficult to achieve
reliably in the global Internet.
RFC 2542 defines "Real-time Internet Fax" to mean a service that
allows two standard Group 3 fax terminals using T.30 protocols to
communicate via the Internet. This specifically requires that
the various T.30 signals and responses are completed within quite
short periods of time.
For the purposes of this memo, these ideas are connoted by the
characteristic of timely delivery:
o "Timely delivery" means that a document is delivered, and any
confirmation is returned, reliably and within a predictable
period of time that is short enough to be useful for the purposes
of routine communications.
Klyne & Shockey Work-in-progress [Page 4]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
3. Goals for High Quality Document Distribution
[[[It's not clear to me whether we want to separate
specification requirements from "operational goals" and
"functional goals", as in RFC2542. I think we should see
what material we generate for this.]]]
[[[What we probably do need to do is separate these into
goals that must be adressed by a protocol specification,
and goals that should be addressed by an implementation.
Non-protocol goals could be migrated to section 4.]]]
This section recalls and expands upon the goals described in RFC
2542 [4], sections 4 and 5.
The goals are:
o {1} timely delivery (section 3.1 below, and RFC 2542 section 4.4)
o {1} proof of delivery/receipt (section 3.2 below, and RFC 2542
section 4.3)
o {1} date and time information (Section 3.3 below, and RFC 2542
section 4.10)
o {1} data format support (RFC 2542 section 5.1)
o {1} quality of output (Section 3.4 below)
o {1} capabilities exchange (RFC 2542 sections 4.5 and 5,5)
o {1} addressing support (RFC 2542, section 5.3)
o {2} legal identity exchange (Section 3.5 below)
o {2} legal issues (RFC 2542 section 4.10)
o {2} cover pages (Section 3.6 below)
o {1} security (RFC 2542 section 4.7)
o {2} interworking with other services (Section 3.7 below, and RFC
2542 section 4.2)
o {2} High Quality Document Transfer should be reasonable easy to
implement (RFC 2542, section 4.6)
o {1} a Quality Document Transfer protocol must operate reliably in
the global Internet. (See RFC 2542, section 4.8.)
Klyne & Shockey Work-in-progress [Page 5]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
o {3} it is desirable that a Quality Document Transfer protocol
makes use of existing infrastructure. (See RFC 2542, sections
4.2 and 5.2)
o {3} features shared with other messaging applications. (See RFC
2542, sections 2.4.3, 2.4.4)
o {3} it is desirable that a Quality Document Transfer protocol
support and facilitate universal messaging systems (RFC 2542,
section 2.4.5 [4])
3.1 Timely delivery
(See RFC 2542, section 4.4. The timeliness goal for a Quality
Document Transfer protocol is stonger.)
A Quality Document Transfer protocol must provide delivery of a
document immediately, or very soon after it is transmitted. That
is, within a period of time that a human user might reasonably wait
for delivery to be completed (e.g. less than a minute).
3.2 Proof of delivery/receipt
(See RFC 2542, section 4.3. The reporting goals are elaborated
here; these are mostly implementaton requirements but may have
some bearing on the protocol design.)
Detailed progress reports and transaction logs have become standard
end user requirements for a facsimile service in order to document
the receipt and confirmation of facsimile delivery. Current e-mail
based Internet fax protocols do not fully satisfy the confirmation
requirements for all current users of traditional facsimile.
Reports from a Quality Document Transfer terminal:
o Must note status (SUCCESS, or FAILURE and information about the
cause of failure that might be needed to achieve a successful
transmission)
o Must note date and time of all attempts (log files recorded at
each end by client and server locally)
o May note the duration of the transaction
o May note the number of document pages transferred
o Should indicate the identity of sender and recipient.
Klyne & Shockey Work-in-progress [Page 6]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
3.3 Date and time information
(See RFC 2542, section 4.10. This section expands on the indicated
legal requirement for date and time of transmission to be
indicated.)
Closely associated with the need for transaction receipt and
notification is the legal requirement (see "Legal issues") that at
least the first page of a facsimile contain the time and date of
transmission and that information be included in any facsimile
service record.
Facsimile terminal devices all have internal clock devices for
recording the time/date of transactions. Actual time information
is not exchanged "on the wire". Each device notes when it sends
and receives documents and logs those transactions appropriately.
All Internet fax transactions note time/date information in the
e-mail header information.
Examples of transaction information that may be useful to record
include:
- time of transmission by sender
- time of reception by receiver
- time that rendering (e.g. printing) is completed
3.4 Quality of output
It is a fundamental goal of High Quality Document Transfer that not
only is the information content of a document transferred, but also
that high presentation quality can be achieved.
Received documents should be capable of presentation that allows
them to be used directly in the same ways that a locally prepared
document might be used. (Contrast with traditional facsimile,
which typicaly does not provide an image one would choose to use
directly in an internal report.)
3.5 Sender and receiver identity exchange
(See RFC 2542, section 4.10. This section expands on the indicated
requirement for the identity of the sender to be indicated.)
Some jurisdictions impose a requirement for a fax machine to
disclose its identity under certain circumstances. This disclosure
is achieved for traditional facsimile through local configuration
of the fax terminal, and the exchange of T.30 CSID frames between
terminal devices.
Klyne & Shockey Work-in-progress [Page 7]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
Internet fax uses e-mail header information to identify the sender
to the recipient.
A Quality Document Transfer protocol should define a mechanism for
achieving a full exchange of identity between a sender and
receiver.
3.6 Cover page
Closely associated with the legal issues are the formats and
requirements for cover pages.
A Quality Document Transfer protocol should provide a mechanism to
include cover page information that conforms to the legal or
general custom and practice applied to facsimile services, when
such information is not already part of the document being sent.
To satisfy legal requirements for Facsimile transmission cover
pages:
o Must contain identification of Sender:
o Should contain identification of Recipient:
o Must contain time/Date of Transmission:
o May contain number of pages in Transmission:
o May contain an area for short comments:
Workstation software, when operating in a facsimile service mode,
should offer cover page generation options and may offer other
features, as deemed appropriate.
If possible, cover page information should be distinguishable from
message payload data (e.g. see the cover page proposal for Internet
fax [21]).
3.7 Interworking with other services
(See RFC 2542, section 4.2 and section 2.)
It is likely that a High Quality Document Transfer system will be
required to gateway to another document distribution service; this
may require conversion of the available document data to/from a
format used by the other service. Choice of baseline data formats
and capabilities will ideally be compatible with other applications
with which systems may be required to interwork.
4. Other considerations
This section discusses some considerations for High Quality
Document Distribution that do not create readily identifiable
application goals.
Klyne & Shockey Work-in-progress [Page 8]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
4.1 Third party operation
In some environments, it may be desirable to hand off delivery of a
document to some third party and report back (a) the fact that the
hand-off has occurred, and (b) subsequent indication from the third
party that delivery has indeed been effected.
An example of this kind of scenario would be a service that
received documents electronically, printed them, then obtains a
signature when delivering the physical document.
5. Internationalization considerations
Quality document transfer must be regarded as a global service, and
any specification must have consideration for:
o {1} transferring documents whose contents are expressed in a
variety of national symbol sets.
o {2} transferring documents whose contents are expressed in a
variety of national languages (in some cases, the language of the
content may be important to its rendering; e.g. text-to-speech
processing).
o {3} document transfer destination adressess that may be expressed
in a variety of national symbol sets (e.g. the names of a person
to whom a document is addressed).
NOTE: There are a number of documents covering
internationalization issues: RFC 2130 [6], RFC 2277 [7]
and others [8].
6. Security considerations
Security goals and considerations are addressed by RFC 2542.
Klyne & Shockey Work-in-progress [Page 9]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
7. Full copyright statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. Acknowledgements
The authors would like to thank the following people for providing
comments on this document: Larry Masinter.
[[[TBD]]]
9. References
[1] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail"
K. Toyoda
H. Ohno
J. Murai, WIDE Project
D. Wing, Cisco Systems
March 1998.
[2] RFC 2532, "Extended Facsimile Using Internet Mail"
Larry Masinter, Xerox Corporation
Dan Wing, Cisco Systems
September 1998.
Klyne & Shockey Work-in-progress [Page 10]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
[3] "Procedures for document facsimile transmission in the general
switched telephone network"
ITU-T Recommendation T.30 (1996)
International Telecommunications Union
July 1996
[4] RFC 2542, "Terminology and Goals for Internet Fax"
Larry Masinter, Xerox Corporation
September 1998
[5] IPP
[6] RFC 2130, "The Report of the IAB Character Set Workshop"
C. Weider, Microsoft
C. Preston, Preston & Lynch
K. Simonsen, DKUUG
H. Alvestrand, UNINETT
R. Atkinson, Cisco Systems
M. Crispin, University of Washington
P. Svanberg, KTH
April 1997.
[7] RFC 2277, "IETF Policy on Character Sets and Languages"
H. Alvestrand, UNINETT
January 1998.
[8] <<<Martin Duerst's draft on internationalization of DNS names>>>
[9] T.4
[10] T.6
[11] TIFF-FX
[12] E.164
[13] SMTP
[14] RFC822
[15] MDN/DSN reporting extensions
[16] RFC 2533
[17] RFC 2531
[18] T.30 mapping document
[19] RFC 1891 (DSN)
Klyne & Shockey Work-in-progress [Page 11]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
[20] RFC 2298 (MDN)
[21] Cover page proposal
[22] RFC 867 (Daytime)
[23] RFC 868 (Time)
[24] RFC 1305 (NTP)
[25] RFC 2030 (SNTP)
10. Authors' addresses
Graham Klyne (editor)
Content Technologies Ltd.
1220 Parkview,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 118 930 1300
Facsimile: +44 118 930 1301
E-mail: GK@ACM.ORG
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd
Suite 100
St. Louis, MO 63119
Telephone: +1 314 918 9020
Facsimile: +1 314 918 9015
E-mail/IFAX: rshockey@ix.netcom.com
Klyne & Shockey Work-in-progress [Page 12]
Internet Draft Additional Goals for Quality Document Transfer
22 October 1999
Appendix A: Revision history
[[[Please remove this section on publication]]]
00a 23-Jul-1999 Initial draft, based on an earlier document by
Richard Shockey.
00b 08-Sep-1999 Incorporate Richard's review comments.
01a 04-Oct-1999 Align goals more closely with RFC 2542; remove
some text that duplicates RFC 2542.
01b 18-Oct-1999 Re-work introductory text slightly.
02a 22-Oct-1999 Extensive editing following early review comments,
particularly to improve the alignment of ideas and
text with RFC 2542.
02b 22-Oct-1999 Further cut back the goals section; add new
section for "Other considerations".
TODO:
o Finalize references
o Separate "operational" and "functional" goals? (section 4 intro)
o Separate confirmation of receipt/proof of delivery?
Klyne & Shockey Work-in-progress [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 04:21:06 |